# How Postman designed Agent Mode for API work

- Source: MechNext — https://mechnext.eu/en/article/36-how-postman-designed-agent-mode-for-api-work
- Published: 2026-10-11
- Updated: 2026-10-11
- Category: Industry News
- Language: en (Markdown in other languages: ?lang=de, ?lang=sk, ?lang=pl, ?lang=zh, ?lang=ru)

> An AWS article describes how Agent Mode combines API workflows with tool selection, context handling, and approval for changes. Postman says the service runs on Amazon Bedrock.

On October 9, 2026, the AWS Machine Learning Blog published an article about how Postman runs Agent Mode on Amazon Bedrock. The article says Postman built Agent Mode as an AI-native way to work across API testing, documentation, discovery, and implementation. Its account focuses on how the agent fits into API work and how its design addresses situations where the agent may have many tools and several kinds of context to consider.

Postman says Agent Mode runs on Amazon Bedrock and uses it for managed access to foundation models. These are architectural details reported in the AWS article, and the descriptions of Postman's design and testing should be understood as the company's account presented there. That framing matters when reading the article's numbers: it explains the patterns Postman describes, but does not provide independent confirmation of the reported results.

### Tool selection as part of the design

One challenge the article discusses is the size of the toolset available to the agent. In Postman's testing, tool-selection errors increased when the visible set exceeded approximately 40 tools. The article describes a process that narrows more than 170 tools to approximately 15 relevant to a request, then passes those tools to a context-isolated sub-agent.

The practical idea is that the agent does not have to work from the full catalog for every request. The system first narrows the options, then gives a smaller, task-relevant set to the sub-agent. The article links the number of visible tools with selection accuracy in Postman's reported testing. The figures are approximate and describe the company's reported results; they should not be read as a universal threshold for every agent system.

Postman also describes changing how the API Catalog is exposed. It consolidated multiple narrow catalog views into a single query tool. The agent can generate queries using the schemas of underlying ClickHouse tables. According to the article, this gives the agent a way to work with catalog data through queries, while the tool exposes the data according to those table schemas.

### Context shaped for an agent

Another change is the use of dedicated context handlers. Postman says its existing interface data model was shaped for rendering and data transfer rather than agent reasoning. The dedicated handlers therefore prepare context in a form intended for Agent Mode. This distinction helps explain why an agent may need a separate context path even when a product already has an interface and an established data model.

An interface and an agent can work with the same product areas while having different needs for how information is organized. In Postman's description, context handling is therefore part of the Agent Mode design, rather than simply another name for the product's existing data transfer. The article presents this as a response to the different purposes served by interface rendering and agent reasoning.

### Approval and background requests

The article says Agent Mode requires user approval before actions that modify application state. It can also send requests in the background without an open tab, while still requiring approval. These details describe separate aspects of operation: a request can run without an open tab, but an action that changes application state remains subject to user approval under the rules described in the article.

For request routing, Postman says it uses Amazon Bedrock cross-Region inference. Requests are routed among destination Regions defined by an inference profile. The article presents this regional routing as part of Agent Mode's operation. The destination set is defined by the profile; the description does not say that every request can be routed to any region.

Postman also says it configured zero data retention for supported Agent Mode models, with `data_retention_mode` set to `none`. Availability and behavior depend on the model. The claim therefore applies to models that support the setting and should not be extended to every model used by Agent Mode.

### Reusing prompt context

According to the article, Agent Mode uses Amazon Bedrock prompt caching with a one-hour checkpoint for near-immutable core prompt content and a five-minute checkpoint for more variable context. This description distinguishes between the more stable part of a prompt and information that changes more often. These are the intervals Postman reports for its setup, not a claim that the same intervals suit every application.

Together, the details portray Agent Mode as a system in which Postman says it addresses tool selection, context preparation, approval for changes, and access to models. The AWS article gives readers an account of how Postman explains its design for API work: the agent receives a narrowed set of relevant tools, context is prepared for reasoning, background requests retain approval requirements, and Bedrock provides model access and regional routing. These details remain the company's account as reported in the article.