Postman found tool-selection errors rising past about 40 tools visible to its agent

Postman started with atomic tools for a defensible reason. Small actions, such as opening a request or fetching one piece of metadata, gave the team correctness and control in early iterations ^[10]. Fine-grained tools also multiply, and the post ties selection errors to how many tools the model can see at once ^[12].

I would treat Postman's figure of roughly 40 as a property of its own catalogue. One failure the post describes is the agent choosing tools that "seemed semantically reasonable but were wrong in context" ^[13]. How often that happens depends on how much the tools overlap in name and purpose. Forty distinct tools and forty near-duplicates are different selection problems. The threshold carries over to another product only if that product's tools overlap about as much and its agent runs on comparable models.

The replacement architecture picks tools by need and context and isolates individual execution threads, so the model sees only what the current task requires ^[15]. The post files this under treating context as the primary bottleneck. That is one of three patterns it names, alongside controlling tool sprawl and exposing schema-based reads ^[3].

The coupling to interface state has a history. Postman has evolved over 11 years, and its users learned to find information by expanding sidebars, checking tabs and opening requests ^[5]. The post puts the agent's position plainly: "An agent reasons over data rather than navigating a screen." ^[6] An API that expects an open tab therefore makes the agent operate the interface before it can change anything ^[16]. I would expect schema-based reads ^[3] to be Postman's answer to this. The available text ends before that section, and it does not name the models tested or report error rates.

The post is candid about where its controls stop. Postman scopes tools to the task and selects purpose-built context, and says these controls reduce unintended actions and data exposure while production testing and monitoring remain necessary ^[17]. Redaction of personally identifiable information through Amazon Bedrock Guardrails runs before text reaches the model, and enterprise admins turn it on in Agent Mode's guardrail settings ^[9].

AWS co-wrote the post ^[3], and its Bedrock section is about operations. Postman describes variable, latency-sensitive demand with sharp traffic bursts. It says Bedrock lets it scale that workload without operating its own model-serving infrastructure ^[7]. The features it names include geographically scoped cross-Region inference and multi-tier prompt caching ^[4].