Postman details how Agent Mode serves 40 million developers on Amazon Bedrock

Why Agent Mode was harder than a demo

Agent Mode is Postman's portal for working with the product across API testing, documentation, discovery and implementation. The source states that building an agent for a demo and operating one for 40 million developers are different engineering problems. The team had expected model quality and prompt design to be the main hurdles. Instead, the deeper challenges came from integrating an agent into a product with years of interface-driven assumptions, a wide surface area and specialized concepts.

Postman has evolved over 11 years, and users learned to find information by expanding sidebars, checking tabs and opening requests. An agent reasons over data rather than navigating a screen, so that awareness had to be re-engineered. In one example from the post, Agent Mode opens a pull request and proposes next steps without the user moving through the interface.

Agent Mode runs on Amazon Bedrock, which gives managed access to foundation models. Postman says demand from its global community is variable, latency-sensitive and prone to sharp traffic bursts. Bedrock lets it scale without operating its own model-serving infrastructure, while keeping flexibility in model selection and control over throughput, geographic processing and cost. The post also names geographically scoped cross-Region inference, model-dependent zero data retention and multi-tier prompt caching as part of the setup.

Human oversight is built in. Agent Mode asks for user approval before actions that modify application state, and tools are scoped to the task. Postman also uses Amazon Bedrock Guardrails to redact personally identifiable information before it reaches the underlying LLM. Enterprise admins can turn this on in the guardrail settings.

Taming tool sprawl and exposing schema-based reads

Early on, the team favored highly atomic tools, such as opening a request or updating a single field. This helped correctness and control, but long workflows needed many tool calls, and each one had to return to the model before the next could start. The experience felt slow, as users watched the agent step through what they saw as one operation.

In Postman's testing, tool-selection errors increased once the visible toolset passed approximately 40 tools. The agent could call nonexistent tools, pass incorrect arguments despite valid schemas, or pick tools that seemed reasonable but were wrong in context. Larger or newer models reduced this behavior but did not remove it.

The current architecture selects tools by need and context. A root agent queries a vector database of tool embeddings and narrows more than 170 tools to approximately 15 relevant to the request. It then hands them to a context-isolated sub-agent, so the model sees only what the task needs.

Another problem was that many client APIs were coupled to interface state. Some tools required certain elements to be open, and others opened tabs as side effects. Postman is decoupling tools from tabs, and its Native Git feature makes extensive use of this approach. Agent Mode can now send requests in the background without an open tab, though user approval is still required.

For products such as the API Catalog, Postman consolidated several narrow views into one query tool. Given the schemas of the underlying ClickHouse tables, the agent can write complex queries with joins and WHERE clauses over data like service uptime, test results and endpoint response times. According to the post, the engineering job shifts from building a tool per question to modeling the data well once.

Context, not capability, was the bottleneck

Postman first assumed missing tools would block the agent most often. In practice, missing or incomplete context caused more failures. Context here means the agent's understanding of where the user is in Postman, which entities are active and what state is already established. When it was wrong or absent, even correct tools were ineffective.

The agent receives two kinds of context. Broad, shallow background context is gathered automatically and minified for the prompt. Deep, focused context is selected by the user and routed through a dedicated handler for each entity type, which distills the entity into what the agent needs.

Simply serializing the existing interface data model did not work, because those objects were shaped for rendering and data transfer, not reasoning. As more objects gained handlers, truncation became the next issue. Fields such as request descriptions, OpenAPI specifications and request payloads hold open-ended user data that can crowd the context window. Postman is exploring a filesystem-backed approach so that each handler does not need custom truncation and expansion logic.

What it means for teams building agents

The post closes each section with advice for builders. Teams should treat the tool catalog as part of the context budget, scope tools dynamically per task, and separate what the agent can do from what the UI happens to have open. Where data is well structured, they should give the agent schema-aware read access to a query engine instead of many single-purpose read tools, trading tool count for data modeling. The source says this produces a better scaling curve.

Postman and AWS say these lessons can help teams move production agents beyond prototypes. They also note that controls such as approval steps and scoped tools reduce unintended actions and unnecessary data exposure, while production testing and monitoring remain necessary.