What Postman's Agent Architecture Reveals About Context Scarcity

Postman's AWS case study on running Agent Mode for 40 million developers gets specific about what actually breaks at scale (tool sprawl, context budget, not model quality), LangChain shipped a model router that cut coding task costs 64% with no quality drop, and Noah Shinn's Instinct updates show a startup discovering its real usage pattern (20% of users want flight booking) and rebuilding around it instead of the novel use case they expected to win on. ### Postman - How Agent Mode Runs for 40 Million Developers on Amazon Bedrock **Source:** https://aws.amazon.com/blogs/machine-learning/how-postman-runs-agent-mode-for-40-million-developers-on-amazon-bedrock/ **Credibility:** High (joint technical case study, AWS + Postman engineering) **What happened:** Postman and AWS published the architectural patterns behind Agent Mode, Postman's AI agent feature serving its 40 million developer user base on Amazon Bedrock. The piece is explicit that the hard problem isn't getting an agent demo working, it's what happens when you have to run one in production at that scale: tool sprawl, schema-based reads instead of raw API dumps, and context as the actual bottleneck rather than model capability. **Key technical details:** - Architecture controls tool sprawl by exposing schema-based reads rather than letting the agent call raw, unconstrained APIs - Context window management is treated as the primary constraint, not model quality or latency - Built on Amazon Bedrock's agent infrastructure, implying a buy-not-build decision for the underlying orchestration layer - Framed as lessons learned from going from "demo that works" to "works for 40 million people" **Why it matters for PMs:** This is the gap almost every team underestimates when shipping an agent feature: it demos fine with 10 tools and a clean prompt, then falls apart at scale when you've connected 40 integrations and the context window is full of irrelevant schema. The "schema-based reads, not raw API dumps" pattern is a concrete design decision you can audit your own agent against today, not an abstract principle. **Critical questions:** - What's the actual failure mode when context runs out, does the agent degrade gracefully or silently drop capability? - How did they decide which tools get schema-based access versus full API access, and is that a per-tool judgment call or a systematic rule? - Postman chose Bedrock's managed agent infra over building their own orchestration. At what usage threshold does that calculus flip? **Action you could take today:** Pull up your own agent's tool list and ask whether each tool exposes a full raw API response or a constrained schema. If it's raw, that's your context bloat source.