Postman’s Agent Mode runs on Amazon Bedrock, but the architecture described by Postman and AWS extends well beyond model inference. It combines application tools, an orchestration service, task-specific context and controls over what the agent can change. The central engineering question is how to give a model enough capability and information to work across API testing, documentation, discovery and implementation without overwhelming its tool selection or context window.
The published account points to three connected decisions: narrow the tools available for each task, prepare context through dedicated paths, and keep user approval in the execution flow. These are vendor-reported design choices, rather than independently measured evidence of reliability or throughput. AWS’s technical account describes the production system; CloudNinjas’ architecture overview explains its logical layers.
How the application connects to Bedrock
CloudNinjas describes four components: client-side tooling, orchestration, purpose-built context and Bedrock inference. Client-side tools expose application operations such as opening a request or updating a field. The orchestration service coordinates tool calls, selects the context payload and forwards prompts to Bedrock.
This division puts application operations and information preparation alongside the model service. Bedrock supplies access to foundation models; the surrounding Agent Mode architecture determines which application capabilities and workspace information are presented for a task. That separation helps explain why the case study spends substantial attention on tools and context, even though Bedrock is the inference platform. CloudNinjas
At the user level, NeoTeo describes assistance with generating API tests from plain-language prompts, investigating failing requests and drafting CI/CD workflow files. Suggested test changes can be reviewed and approved. Those examples connect the architecture to concrete work, although they do not establish a task-success rate. NeoTeo
Narrowing more than 170 tools to about 15
Postman reports that tool-selection errors increased in its testing once the visible toolset exceeded approximately 40 tools. That is an observation from Postman’s testing, not a universal limit for agents or models. The supplied evidence does not give an error rate or enough experimental detail to reproduce the finding. AWS
The described response is task-based retrieval. Rather than exposing the entire catalog of more than 170 tools, Agent Mode searches for relevant capabilities and narrows the set to about 15 for a task. The selected tools then go to a context-isolated sub-agent, according to NeoTeo’s account. NeoTeo
The architectural implication is that tool selection becomes its own step. A large application can retain a broad catalog while giving a task-executing agent a smaller set of choices. This also makes the retrieval step consequential: its selection determines which capabilities the sub-agent receives. The evidence describes that mechanism but does not quantify how often retrieval selects the right set or how much the narrower set improves completion rates.
For structured information in API Catalog, Postman describes another way to limit tool proliferation: schema-aware read access to ClickHouse tables, rather than a separate narrow tool for every question. This moves part of the interface toward querying structured data. It should not be read as evidence of unrestricted database access or of measured query accuracy; the supplied account establishes schema-based reads. NeoTeo
Preparing background and user-selected context
Postman’s account identifies missing or incomplete context as a major bottleneck. NeoTeo describes two paths for supplying it. Background context is gathered automatically from the workspace and reduced before entering the prompt. Focused context comes from user selections or mentions and passes through handlers tailored to the relevant Postman object. NeoTeo
The distinction gives the system both a broad workspace view and a way to process information the user deliberately highlights. Dedicated handlers matter because the material is not uniform: request descriptions, OpenAPI specifications and payloads can occupy substantial space in the model’s context window. Postman says reduction or truncation can therefore be necessary.
The trade-off follows from that design. Reducing context limits what reaches the model, so having access to a workspace does not establish that every relevant detail survives prompt preparation. The account explains why Postman built context handlers, but does not establish how completely they preserve information across different tasks. For architects, the useful lesson is to examine tool availability and context preparation together: a selected tool still needs the information required to use it.
Routing inference and controlling prompt reuse
According to AWS, Agent Mode can access supported Anthropic Claude models through Amazon Bedrock model inference APIs and route workloads to an appropriate model. It also uses cross-Region inference, which routes requests among destination Regions defined by an inference profile. NeoTeo distinguishes geographic profiles, which route within a defined geography, from global profiles, which can route among supported Regions worldwide. AWS, NeoTeo
That distinction matters when assessing the deployment: cross-Region inference alone does not specify the geographic boundary. The selected profile defines the destinations described in the account.
Retention and caching also carry model qualifications. NeoTeo reports that Postman sets data_retention_mode to none for supported Agent Mode models. Its described caching configuration uses a one-hour checkpoint for stable prompt content and a five-minute checkpoint for more variable context, with the longer-lived checkpoint preceding the shorter-lived one. These details should be read with their model-dependent support limits. They do not establish a blanket retention or caching guarantee across every model. NeoTeo
CloudNinjas describes prompt caching as a way to reduce latency for repeated queries. The supplied evidence does not quantify the resulting latency or cost savings for Agent Mode. CloudNinjas
Redaction and approval serve different purposes
AWS says Postman uses Amazon Bedrock Guardrails to redact personally identifiable information before it reaches the underlying large language model. Enterprise administrators can enable that redaction in Agent Mode’s guardrail settings. The availability of the setting should therefore be distinguished from an assumption that it is enabled for every deployment. AWS
Separately, Agent Mode requires user approval before actions that modify application state. AWS also describes sending requests in the background without an open tab, while retaining user approval. Background execution consequently does not imply that the approval requirement disappears.
These controls address different parts of the workflow: redaction concerns information passed to the model, while approval concerns changes made through the application. The evidence describes both mechanisms without supplying measured redaction effectiveness or an independent safety evaluation. AWS
What the scale claim establishes
The AWS headline frames Agent Mode around 40 million developers, and some secondary coverage describes production deployment in similar terms. NeoTeo explicitly clarifies that the figure refers to Postman’s developer community, rather than Agent Mode users. It should not be used as an active-user count, concurrency figure or throughput benchmark for the agent. AWS, NeoTeo
Postman also says its production implementation is proprietary and unavailable as a public sample repository, according to NeoTeo. The account is therefore most useful as an architectural walkthrough: it documents how Postman scopes tools, prepares context, routes inference and retains human control. It leaves implementation reproducibility and measured performance as open questions for anyone assessing how these patterns would work in another application. NeoTeo
