Postman betreibt Agent Mode für 40 Millionen Entwickler auf Amazon Bedrock
Ein KI-Agent, der in der Demo funktioniert, ist etwas anderes als einer im Betrieb für 40 Millionen Entwickler. Postman und AWS erklären, wie sie Tool-Sprawl kontrollieren, schema-basierte Reads bereitstellen und den Kontext als eigentlichen Engpass behandeln.
Einen KI-Agenten für eine Demo zu bauen und einen für 40 Millionen Entwickler zu betreiben, sind unterschiedliche ingenieurstechnische Probleme. Postman hat sich zum Ziel gesetzt, Agent Mode zu entwickeln, eine KI-native Arbeitsweise über API-Tests, Dokumentation, Discovery und Implementierung hinweg. Das Team erwartete, dass Modellqualität und Prompt-Design die schwierigsten Probleme sein würden. Die tieferen Herausforderungen ergaben sich aus der Integration eines Agenten in ein ausgereiftes Produkt mit jahrelangen interface-getriebenen Annahmen, einer großen Oberfläche und spezialisierten Konzepten.
In diesem Beitrag beschreiben Postman und AWS die Architekturmuster, die beim Versuch entstanden, ein ausgereiftes Produkt für einen KI-Agenten lesbar zu machen. Zu diesen Mustern gehören die Kontrolle von Tool-Sprawl, die Bereitstellung schema-basierter Lesezugriffe und die Betrachtung von Kontext statt Fähigkeiten als den primären Engpass.
Wir erklären außerdem, wie Agent Mode Amazon Bedrock für Modellflexibilität, geografisch abgegrenzte Cross-Region-Inferenz, modellabhängige Zero-Data-Retention und mehrstufiges Prompt-Caching nutzt. Zusammen können diese Erkenntnisse Teams helfen, Produktionsagenten über Prototypen hinauszubringen.
Agent Mode ist Postmans Portal, um auf KI-native Weise mit dem Produkt zu arbeiten, über Tests, Dokumentation, Discovery und Implementierung hinweg. Postman hat sich über 11 Jahre entwickelt, und Entwickler und Nutzer lernten, Informationen über die Benutzeroberfläche zu finden, indem sie Seitenleisten aufklappten, Tabs prüften und Requests öffneten. Die Neugestaltung dieses Bewusstseins für einen Agenten brachte strukturelle Annahmen in den APIs, der User Experience und der Verteilung des Produktwissens ans Licht. Ein Agent denkt über Daten nach, statt durch einen Bildschirm zu navigieren. Abbildung 1 zeigt, wie Agent Mode direkt gegen die Anwendung arbeitet.
Abbildung 1: Agent Mode arbeitet direkt gegen die Postman-Anwendung. In diesem Beispiel öffnet er einen Pull Request und schlägt nächste Schritte vor, ohne dass der Nutzer durch die Benutzeroberfläche navigieren muss
Agent Mode läuft auf Amazon Bedrock, das verwalteten Zugriff auf Foundation Models hinter dem Agenten bereitstellt. Die Unterstützung von Postmans globaler Entwickler-Community erzeugt eine variable, latenzempfindliche Nachfrage mit spitzem Traffic-Aufkommen. Mit Amazon Bedrock kann Postman diese Produktions-Workload skalieren, ohne eine eigene Model-Serving-Infrastruktur zu betreiben, und behält dabei Flexibilität bei der Modellauswahl sowie Kontrolle über Durchsatz, geografische Verarbeitung und Kosten. Abbildung 2 bietet eine Übersicht auf hoher Ebene der Produktionsarchitektur, bevor die folgenden Abschnitte ihre Komponenten untersuchen.
Abbildung 2: Postman Agent Mode kombiniert clientseitige Tools, Agent-Orchestrierung, eigens erstellten Kontext und Amazon Bedrock Model Inference. Tools sind für jede Aufgabe abgegrenzt, und die Zustimmung des Nutzers bleibt Teil von Aktionen, die den Anwendungszustand ändern
Menschliche Aufsicht ist Teil des Produktionsdesigns. Agent Mode erfordert die Zustimmung des Nutzers, bevor Aktionen den Anwendungszustand ändern. Postman begrenzt außerdem die verfügbaren Tools auf die jeweilige Aufgabe, wählt eigens erstellten Kontext aus und wendet modellabhängige Datenhaltungs-Einstellungen an.
Diese Kontrollen verringern unbeabsichtigte Aktionen und unnötige Datenfreigabe, während Produktions-Tests und Monitoring weiterhin notwendig bleiben. Als eine Control im Sinne von Responsible AI verwendet Postman Amazon Bedrock Guardrails, um personenbezogene Daten (Personally Identifiable Information) zu schwärzen, bevor sie das zugrunde liegende Large Language Model (LLM) erreichen. Enterprise-Administratoren können dies in den Guardrail-Einstellungen von Agent Mode aktivieren.
In Agent Mode definieren Tools, wie der Agent innerhalb von Postman handelt. Anfänglich tendierte das Team zu hochgradig atomaren Tools: kleine, präzise Aktionen wie das Öffnen eines Requests, das Aktualisieren eines einzelnen Feldes oder das Abrufen eines bestimmten Metadatenwerts. Dieser Ansatz unterstützte Korrektheit und Kontrolle in frühen Iterationen, zeigte aber auch mehrere Probleme auf.
Viele reale Workflows erfordern lange Sequenzen von Tool-Aufrufen. Selbst wenn jeder Schritt schnell war, wirkte das Gesamterlebnis langsam, weil jede Aktion zum Modell zurückkehren musste, bevor die nächste beginnen konnte. Nutzer sahen zu, wie der Agent Schritte durchlief, die sie gedanklich als eine einzige Operation zusammengefasst hatten.
In Postmans Tests stiegen Fehler bei der Tool-Auswahl, sobald der sichtbare Toolset etwa 40 Tools überschritt. Der Agent konnte nicht existierende Tools aufrufen, trotz gültiger Schemas falsche Argumente übergeben oder Tools auswählen, die semantisch plausibel erschienen, im Kontext aber falsch waren. Größere oder neuere Modelle verringerten dieses Verhalten, beseitigten es aber nicht.
Ab einer bestimmten Toolset-Größe kann das Bereitstellen weiterer Tools die Effektivität des Agenten verringern. Die aktuelle Architektur wählt Tools nach Bedarf und Kontext aus und isoliert einzelne Ausführungsthreads. Das Modell sieht nur die Tools, die für die aktuelle Aufgabe relevant sind. Abbildung 3 veranschaulicht diesen dynamischen Auswahlprozess.
Abbildung 3: Der Root-Agent fragt eine Vektordatenbank mit Tool-Embeddings ab und verengt mehr als 170 Tools auf etwa 15, die für die Anfrage relevant sind. Anschließend übergibt er diese Tools an einen kontextisolierten Sub-Agenten, sodass das Modell nur die für die Aufgabe benötigten Tools sieht
Ein subtileres Problem war, dass viele Client-APIs implizit an den Interface-Zustand gekoppelt waren. Tools, die Requests änderten, benötigten bestimmte geöffnete Elemente, während andere Tools als Nebeneffekt neue Tabs öffneten. Der Agent musste einen Request-Tab öffnen, um ihn zu lesen, und interface-Interaktionen nachahmen statt über Daten zu denken. Postman entkoppelt Tools aktiv von Tabs, und seine Native Git Funktion macht umfangreichen Gebrauch von diesem Ansatz. Beispielsweise kann Agent Mode nun Requests im Hintergrund ohne geöffneten Tab senden, wobei die Zustimmung des Nutzers weiterhin erforderlich ist.
Erkenntnis für Builder: Betrachten Sie Ihren Tool-Katalog als Teil des Kontextbudgets. Begrenzen Sie die dem Modell pro Aufgabe bereitgestellten Tools dynamisch und entkoppeln Sie die Frage, was der Agent tun kann, von dem, was die Benutzeroberfläche zufällig geöffnet hat.
Für Produkte wie den API Catalog hat Postman mehrere schmale Sichten zu einem einzigen Query-Tool zusammengefasst. Diese Produkte stellen strukturierte Daten wie Service-Uptime, Testergebnisse und Endpoint-Antwortzeiten über viele Dienste hinweg bereit.
Ausgehend von den Schemas der zugrunde liegenden ClickHouse-Tabellen kann der Agent komplexe Abfragen mit Joins und WHERE-Klauseln generieren. Dies reduziert die Anzahl der unterschiedlichen Tools, die zur Beantwortung einer Analysefrage benötigt werden, erheblich:
SELECT toString(service_id) AS service_id, countMerge(total_events_state) AS total_requests, countMerge(error_events_state) AS total_errors, round(countMerge(error_events_state) * 100.0 / countMerge(total_events_state), 4) AS error_rate_pct, avgMerge(avg_latency_state) AS avg_latency_ms, quantileMerge(0.95)(p95_latency_state) AS p95_latency_ms FROM http_events_summary_1d WHERE service_id IN ('...Liste der Service-IDs') AND bucket_1d >= today() - 7 GROUP BY service_id HAVING p95_latency_ms < 100 AND total_requests > 0 ORDER BY error_rate_pct DESC; Bei diesem Ansatz verlagert sich die Aufgabe des Engineering-Teams vom Bau eines Tools pro Frage hin zu einer einmaligen, guten Modellierung der Daten. Der Agent kann daraufhin eine viel größere Vielfalt an Abfragen generieren, als das Team jemals als einzelne Tools hätte abbilden können.
Erkenntnis für Builder: Wo gut strukturierte Daten vorliegen, geben Sie dem Agenten schema-bewussten Lesezugriff auf eine Query-Engine statt einer Vielzahl von Einzelzweck-Lesetools. Sie tauschen Tool-Anzahl gegen Datenmodellierung, was eine bessere Skalierungskurve erzeugt.
Postman ging zunächst davon aus, dass fehlende Tools die größte Hürde sein würden. In der Praxis verursachten fehlender oder unvollständiger Kontext mehr Fehler als fehlende Fähigkeiten.
Kontext ist das Verständnis des Agenten darüber, wo sich der Nutzer in Postman befindet, welche Entitäten aktiv sind und welcher Zustand bereits etabliert wurde. Wenn dieser Kontext falsch oder abwesend war, wurden selbst korrekte Tools wirkungslos. Abbildung 4 unterscheidet die beiden Formen von Kontext, die dem Agenten bereitgestellt werden.
Abbildung 4: Zwei Arten von Kontext versorgen den Agenten. Breiter, oberflächlicher Hintergrundkontext wird automatisch gesammelt und für den Prompt verkleinert. Tiefer, fokussierter ausgewählter Kontext wird vom Nutzer gewählt und über einen dedizierten Handler für jeden Entitätstyp geleitet. Jeder Handler destilliert die Entität in die Informationen, die der Agent benötigt
Die Herausforderung war strukturell. Über 11 Jahre hinweg lernten Entwickler und Nutzer, Informationen über die Benutzeroberfläche zu finden. Die Neugestaltung dieses Bewusstseins für einen Agenten erforderte mehrere Iterationen, um zu bestimmen, was für jeden Workflow wichtig war und was Rauschen war. Die Serialisierung des bestehenden Interface-Datenmodells erzeugte keinen nützlichen Kontext, da diese Objekte für Rendering und Datenübertragung geformt waren, nicht für Reasoning. Postman baute daher dedizierte Context Handler, die jede Entität in das destillierten, was der Agent wissen musste.
Als immer mehr Objekte Handler erhielten, wurde Truncation das nächste Problem. Viele Felder enthalten offene, nutzergenerierte Daten, darunter Request-Beschreibungen, OpenAPI-Spezifikationen und Request-Payloads. Diese Daten können das Kontextfenster überladen. Eine sorgfältige Verwaltung des Kontextbudgets ist im großen Maßstab entscheidend und unterstützt den dateisystembasierten Ansatz, den das Team untersucht, bei dem jeder Handler keine eigene Truncation- und Expansion-Logik benötigt.
Wichtigster Hinweis für Entwickler: Gebt dem Modell nicht euer Rendering-Datenmodell. Baut zweckgerichtete Context-Handler und behandelt das Context Window als knappen, aktiv verwalteten Budgetposten. Rauschen verdrängt das Signal lange bevor das Modell sein Limit erreicht.
Im Verlauf der Entwicklung von Agent Mode wurde klar, dass das System drei unterschiedliche Komponenten zusammenführen musste, von denen jede ein anderes Problem löst.
All dies in statischen Prompts zu kodieren war nicht machbar, und der Großteil davon ist für eine bestimmte Anfrage irrelevant. Für das anfängliche Seeding nutzte das Team Postmans Learning Center, um kompakte, featurespezifische Artikel zu erstellen. Zur Laufzeit wählt Agent Mode Wissensartikel basierend auf der eingehenden Anfrage und dem verfügbaren Kontext aus. Wenn ein Nutzer beispielsweise einen Mock-Server auswählt, injiziert Agent Mode automatisch den zugehörigen Artikel. So bleibt der Agent standardmäßig schlank und bietet bei Bedarf Tiefe. Die Wissensdatenbank entwickelt sich mit der Anwendung weiter, sodass Teams die Agent-Mode-Dokumentation gemeinsam mit neuen Features ausliefern können.
Die drei zuvor beschriebenen Komponenten laufen auf dieselbe Laufzeitaktion hinaus: einen Inferenzaufruf an ein Foundation Model (FM). In Postmans Größenordnung ist der Verkehr bursts ausgelöst und entwicklergetrieben. Routing, Caching und geografische Verarbeitungssteuerung helfen Postman, Verkehrsspitzen zu bewältigen, Inferenzkosten zu managen und workloadspezifische Verarbeitungsanforderungen zu erfüllen. Amazon Bedrock bietet hierfür vier entscheidende Fähigkeiten.
Agent Mode ist nicht an ein einzelnes Modell gebunden. Über die Modell-Inferenz-APIs von Amazon Bedrock kann Postman auf die unterstützten Anthropic-Claude-Modelle zugreifen und jede Workload an ein geeignetes Modell routen. Ein schnelleres Modell kann hochvolumige, latenzempfindliche Interaktionen bedienen, während ein größeres Modell komplexe Reasoning-Aufgaben übernimmt, bei denen Qualität wichtiger ist als Kosten.
Der Wechsel zwischen unterstützten Claude-Modellen ist in erster Linie eine Konfigurationsänderung und keine neue Integration. Diese Flexibilität unterstützt direkt die zuvor beschriebenen Herausforderungen durch Tool-Vielfalt und Kontext. In Postmans Tests reduzierten neuere und größere Modelle Tool-Halluzinationen, und Postman kann unterstützte Modelle übernehmen, ohne die Integration neu zu bauen.
Siehe die nach AWS-Region unterstützten Modelle in Amazon Bedrock.
Der Entwicklerverkehr ist stark schwankend, und die Bereitstellung von Kapazität für Spitzenlasten in einer einzelnen AWS-Region kann teuer sein. Agent Mode nutzt das Cross-Region-Inference von Amazon Bedrock, um Anfragen automatisch zwischen den von einem Inference Profile definierten Ziel-Regionen zu verteilen. Zur Laufzeit übergibt die Anwendung die ausgewählte Inference-Profile-ID oder den Amazon Resource Name (ARN) als modelId bei Converse oder InvokeModel. Das Profil, die einschlägigen IAM- und Service-Control-Policies von AWS Identity and Access Management sowie die Quotas müssen jede Ziel-Region erlauben, die Bedrock auswählen könnte.
Postman kann das Inference Profile pro Workload auswählen: ein globales Profil für maximal verfügbaren Durchsatz oder ein geografisches Profil, wenn die Verarbeitung innerhalb der definierten Geografie des Profils bleiben muss. Diese Wahl ist explizit in der modelId enthalten, die für jede Bedrock-Inferenzanfrage verwendet wird.
# Schematische Converse-Anfrage response = bedrock_runtime.converse( modelId="<geografische-inference-profile-id-oder-arn>", messages=messages, system=system_blocks, ) Datenresidenz und Enterprise-Kontrollen Für Enterprise-Kunden kann die erlaubte Verarbeitungsgeografie ebenso wichtig sein wie der Durchsatz. Geografische Inference Profiles beschränken das Bedrock-Routing auf die vom Profil unterstützten Ziel-Regionen innerhalb der ausgewählten Geografie. Das bedeutet nicht, dass die Inferenz innerhalb der eigenen AWS-Umgebung von Postman läuft.
Amazon Bedrock verarbeitet Anfragen in den für das Profil zugelassenen AWS-Regionen, wobei Daten bei Übertragung und in Ruhe verschlüsselt sind. AWS gibt an, dass Bedrock Prompts und Completions nicht zum Training von AWS-Modellen verwendet und nicht an Dritte weitergibt. Postman hat Zero Data Retention konfiguriert, wobei data_retention_mode für die unterstützten Agent-Mode-Modelle auf none gesetzt ist.
Verfügbarkeit und Verhalten sind modellabhängig, daher muss jedes Produktionsmodell gegen die aktuelle Dokumentation zu Datenschutz und Aufbewahrung von Amazon Bedrock geprüft werden.
Ein Produktionsagent übermittelt in jedem Durchlauf umfangreichen stabilen Kontext erneut, darunter Systeminstruktionen, generisches Agentenverhalten, einen Kernwerkzeugsatz, ausgewähltes Wissen und den Konversationskontext. Die erneute Verarbeitung des unveränderten Präfixes bei jeder Anfrage erzeugt vermeidbare Latenz und Kosten.
Agent Mode nutzt das Prompt Caching von Amazon Bedrock, um stabile Prompt-Präfixe wiederzuverwenden. Der nahezu unveränderliche Kern, bestehend aus dem System-Prompt, den Agenteninstruktionen und den Kern-Tool-Definitionen, verwendet einen Cache-Checkpoint mit einer Stunde Gültigkeit. Variablerer Kontext verwendet einen Checkpoint mit fünf Minuten, der bei einem Cache-Hit aufgefrischt wird.
Bedrock verlangt, dass der langlebigere Checkpoint vor dem kürzerlebigen Checkpoint erscheint. Die kürzere Stufe eignet sich für interaktive Sitzungen, da ungenutzter Kontext abläuft, während die Ein-Stunden-Stufe ihren höheren Cache-Schreibpreis über viele Lesezugriffe amortisieren kann. Die Cache-Vorteile und unterstützten TTLs hängen vom gewählten Modell ab.
Teams können das Verhalten über die Nutzungsfelder cacheReadInputTokens und cacheWriteInputTokens überprüfen und die Time to First Token für ihre eigenen Workloads messen.
# Schematische Cache-Checkpoints in Converse-Content-Blöcken {"cachePoint": {"type": "default", "ttl": "1h"}} # stabiler Kern {"cachePoint": {"type": "default", "ttl": "5m"}} # variable Schicht Wichtigster Hinweis für Entwickler: Betrachtet Inferenz als Routing- und Caching-Problem, nicht nur als Modellauswahlentscheidung. Wählt das Claude-Modell pro Workload, bestimmt das passende Cross-Region-Inference-Profil und cached das stabile Prompt-Präfix mit TTLs, die der Änderungsfrequenz jeder Schicht entsprechen.
Aus Postmans Weg destilliert, für Entwickler, die auf Amazon Bedrock arbeiten:
Der Bau von Agent Mode zwang Postman, die Lücke zwischen den Fähigkeiten großer Sprachmodelle und der Struktur ausgereifter Produkte zu adressieren: Interface-Annahmen, gekoppelte Clients, unübersichtliche Tool-Kataloge und Wissen, das über Dokumentation und Teams verteilt ist. Dynamische Tool-Auswahl, schema-basierte Reads und gezieltes Context Engineering erwiesen sich als wiederholbare Muster in der Größenordnung von Postmans Entwicklercommunity. Amazon Bedrock bietet den verwalteten Modellzugriff, die Cross-Region-Inference, modellabhängige Retention-Kontrollen und das Prompt Caching, die die Produktionsarchitektur tragen.
Ob ihr euren ersten Agenten baut oder einen bestehenden skaliert: Diese Muster können Teams helfen, häufige Herausforderungen bei Agenten-Integration und Skalierung zu vermeiden.
Weitere Informationen findet ihr in der Amazon-Bedrock-Dokumentation, einschließlich Leitfäden zur Cross-Region-Inference, zum Prompt Caching sowie zu Datenschutz und Aufbewahrung. Für weiterführende Umsetzungsleitfäden lest Effectively use prompt caching on Amazon Bedrock und Amazon Bedrock announces global cross-Region inference for increased throughput im AWS Machine Learning Blog. Um das Produkt zu erkunden, seht euch die Postman-Agent-Mode-Dokumentation an.
Postmans Produktionsimplementierung ist proprietär und nicht als öffentliches Beispiel-Repository verfügbar.
Srinivas ist Senior Engineer im Postman-KI-Team und entwickelt Enterprise-Agenten an der Schnittstelle von verteilten Systemen und KI-Infrastruktur. Sein Fokus liegt auf der Kernarchitektur von Agenten, die Agenten auch bei großem Maßstab zuverlässig und akkurat hält.
Shubham ist Solutions Architect bei AWS mit Sitz in Bengaluru, Indien, und unterstützt unabhängige Softwareanbieter (ISVs). Er arbeitet mit Engineering- und Führungsteams daran, ihre Produkte auf AWS zu gestalten, zu bauen und zu betreiben, von der ersten Architektur bis zur Produktion, mit besonderem Fokus auf generative KI und Resilienz bei Skalierung. Außerhalb der Arbeit ist Shubham ein begeisterter Wanderer, der dieselbe Vorbereitung und Ausdauer vom Weg auch in den Bau langlebiger Systeme einbringt.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Building an AI agent for a demo and operating one for 40 million developers are different engineering problems. Postman set out to build Agent Mode, an AI-native way to work across API testing, documentation, discovery, and implementation. The team expected model quality and prompt design to be the hardest problems. The deeper challenges came from integrating an agent into a mature product with years of interface-driven assumptions, a wide surface area, and specialized concepts.
In this post, Postman and AWS describe the architectural patterns that emerged while making a mature product legible to an AI agent. These patterns include controlling tool sprawl, exposing schema-based reads, and treating context rather than capability as the primary bottleneck.
We also explain how Agent Mode uses Amazon Bedrock for model flexibility, geographically scoped cross-Region inference, model-dependent zero data retention, and multi-tier prompt caching. Together, these lessons can help teams move production agents beyond prototypes.
Agent Mode is Postman’s portal for working with the product in an AI-native way across testing, documentation, discovery, and implementation. Postman has evolved over 11 years, and developers and users learned to locate information through the interface by expanding sidebars, checking tabs, and opening requests. Re-engineering that awareness for an agent surfaced structural assumptions in the product’s APIs, user experience, and distribution of product knowledge. An agent reasons over data rather than navigating a screen. Figure 1 illustrates how Agent Mode works directly against the application.
Figure 1: Agent Mode works directly against the Postman application. In this example, it opens a pull request and proposes next steps without requiring the user to navigate through the interface
Agent Mode runs on Amazon Bedrock, which provides managed access to foundation models behind the agent. Supporting Postman’s global developer community creates variable, latency-sensitive demand with sharp traffic bursts. With Amazon Bedrock, Postman can scale this production workload without operating its own model-serving infrastructure while retaining flexibility in model selection and control over throughput, geographic processing, and cost. Figure 2 provides a high-level view of the production architecture before the following sections examine its components.
Figure 2: Postman Agent Mode combines client-side tools, agent orchestration, purpose-built context, and Amazon Bedrock model inference. Tools are scoped for each task, and user approval remains part of actions that modify application state
Human oversight is part of the production design. Agent Mode requires user approval before actions that modify application state. Postman also scopes available tools to the task, selects purpose-built context, and applies model-dependent data-retention settings. These controls reduce unintended actions and unnecessary data exposure, while production testing and monitoring remain necessary. As a responsible AI control, Postman uses Amazon Bedrock Guardrails to redact personally identifiable information before it reaches the underlying large language model (LLM). Enterprise admins can turn this on in Agent Mode’s guardrail settings.
In Agent Mode, tools define how the agent acts inside Postman. Early on, the team leaned toward highly atomic tools: small, precise actions such as opening a request, updating one field, or fetching a specific piece of metadata. That approach supported correctness and control in early iterations, but it also revealed several problems.
Many real-world workflows require long sequences of tool calls. Even when each step was fast, the overall experience felt slow, because every action had to return to the model before the next one could begin. Users watched the agent step through actions they had mentally grouped as a single operation.
In Postman’s testing, tool-selection errors increased once the visible toolset exceeded approximately 40 tools. The agent could call nonexistent tools, pass incorrect arguments despite valid schemas, or select tools that seemed semantically reasonable but were wrong in context. Larger or newer models reduced this behavior but didn’t remove it.
Past a certain toolset size, exposing more tools can reduce agent effectiveness. The current architecture selects tools based on need and context and isolates individual execution threads. The model sees only the tools relevant to the current task. Figure 3 illustrates this dynamic selection process.
Figure 3: The 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 those tools to a context-isolated sub-agent, so the model sees only the tools needed for the task
A subtler problem was that many client APIs were implicitly coupled to interface state. Tools that modified requests needed certain elements to be open, while other tools opened new tabs as side effects. The agent had to open a request tab to read it, mimicking interface interactions instead of reasoning about data. Postman is actively decoupling tools from tabs, and its Native Git feature makes extensive use of this approach. For example, Agent Mode can now send requests in the background without an open tab, although user approval is still required.
Builder takeaway: Treat your tool catalog as part of the context budget. Dynamically scope the tools exposed to the model per task, and decouple “what the agent can do” from “what the UI happens to have open.”
For products such as the API Catalog, Postman consolidated multiple narrow views into a single query tool. These products expose structured data such as service uptime, test results, and endpoint response times across many services.
Given the schemas of the underlying ClickHouse tables, the agent can generate complex queries with joins and WHERE clauses. This substantially reduces the number of distinct tools needed to answer an analysis question:
SELECT toString(service_id) AS service_id, countMerge(total_events_state) AS total_requests, countMerge(error_events_state) AS total_errors, round(countMerge(error_events_state) * 100.0 / countMerge(total_events_state), 4) AS error_rate_pct, avgMerge(avg_latency_state) AS avg_latency_ms, quantileMerge(0.95)(p95_latency_state) AS p95_latency_ms FROM http_events_summary_1d WHERE service_id IN ('...list of service IDs') AND bucket_1d >= today() - 7 GROUP BY service_id HAVING p95_latency_ms < 100 AND total_requests > 0 ORDER BY error_rate_pct DESC; With this approach, the engineering job shifts from building a tool per question to modeling the data well once. The agent can then generate a far wider variety of queries than the team could ever have enumerated as individual tools.
Builder takeaway: Where you have well-structured data, give the agent schema-aware read access to a query engine instead of a proliferation of single-purpose read tools. You trade tool count for data modeling, which produces a better scaling curve.
Postman initially assumed missing tools would be the biggest blocker. In practice, missing or incomplete context caused more failures than missing capabilities.
Context is the agent’s understanding of where the user is in Postman, which entities are active, and what state has already been established. When that context was wrong or absent, even correct tools became ineffective. Figure 4 distinguishes the two forms of context supplied to the agent.
Figure 4: Two kinds of context feed the agent. Broad, shallow background context is gathered automatically and minified for the prompt. Deep, focused selected context is chosen by the user and routed through a dedicated handler for each entity type. Each handler distills the entity into the information the agent needs
The challenge was structural. Over 11 years, developers and users learned to find information through the interface. Re-engineering that awareness for an agent required multiple iterations to determine what mattered for each workflow and what was noise. Serializing the existing interface data model did not produce useful context because those objects were shaped for rendering and data transfer, not reasoning. Postman therefore built dedicated context handlers that distilled each entity into what the agent needed to know.
As more objects gained handlers, truncation became the next problem. Many fields contain open-ended user-generated data, including request descriptions, OpenAPI specifications, and request payloads. This data can crowd the context window. Managing the context budget carefully is essential at scale and supports the filesystem-backed approach the team is exploring, where each handler does not need custom truncation and expansion logic.
Builder takeaway: Don’t feed the model your rendering data model. Build purpose-shaped context handlers and treat the context window as a scarce, actively managed budget. Noise crowds out signal long before the model reaches its limit.
As Agent Mode evolved, it became clear the system had to aggregate three distinct components, each solving a different problem.
Encoding all of this in static prompts was not feasible, and most of it is irrelevant to a given query. For initial seeding, the team used Postman’s Learning Center to generate concise feature-specific articles. At runtime, Agent Mode selects knowledge articles based on the incoming query and available context. For example, when a user selects a mock server, Agent Mode injects the related article automatically. This keeps the agent lightweight by default while providing depth when needed. The knowledge base evolves with the application, so teams can ship Agent Mode documentation with new features.
The three components previously described resolve to the same runtime action: an inference call to a foundation model (FM). At Postman’s scale, traffic is bursty and developer-driven. Routing, caching, and geographic processing controls help Postman accommodate traffic bursts, manage inference cost, and address workload-specific processing requirements. Amazon Bedrock provides four capabilities that matter most here.
Agent Mode isn’t tied to one model. Through Amazon Bedrock model inference APIs, Postman can access supported Anthropic Claude models and route each workload to an appropriate model. A faster model can serve high-volume, latency-sensitive interactions, while a larger model can handle complex reasoning where quality matters more than cost. Moving between supported Claude models is primarily a configuration change rather than a new integration. This flexibility directly supports the tool-sprawl and context challenges described earlier. In Postman’s testing, newer and larger models reduced tool hallucinations, and Postman can adopt supported models without rebuilding the integration. See supported models by AWS Region in Amazon Bedrock.
Developer traffic is spiky, and provisioning for peak demand in one AWS Region can be costly. Agent Mode uses Amazon Bedrock cross-Region inference to automatically route requests among the destination Regions defined by an inference profile. At runtime, the application passes the selected inference profile ID or Amazon Resource Name (ARN) as the modelId in Converse or InvokeModel. The profile, applicable AWS Identity and Access Management (IAM) and service control policies, and quotas must permit every destination Region that Bedrock might select.
Postman can select the inference profile per workload: a global profile for maximum available throughput or a geographic profile when processing must remain within the profile’s defined geography. This choice is explicit in the modelId used for each Bedrock inference request.
# Schematic Converse request response = bedrock_runtime.converse( modelId="<geographic-inference-profile-id-or-arn>", messages=messages, system=system_blocks, ) Data residency and enterprise controls For enterprise customers, permitted processing geography can be as important as throughput. Geographic inference profiles constrain Bedrock routing to the profile’s supported destination Regions within the selected geography. This does not mean that inference runs inside Postman’s own AWS environment.
Amazon Bedrock processes requests in the eligible AWS Regions for that profile, with data encrypted in transit and at rest. AWS states that Bedrock doesn’t use prompts and completions to train AWS models or distribute them to third parties. Postman has configured zero data retention with data_retention_mode set to none for supported Agent Mode models.
Availability and behavior are model-dependent, so each production model must be checked against the current Amazon Bedrock data-protection and retention documentation.
A production agent resends substantial stable context on each turn, including system instructions, generic agent behavior, a core tool set, selected knowledge, and conversation context. Reprocessing the unchanged prefix on every request adds avoidable latency and cost.
Agent Mode uses Amazon Bedrock prompt caching to reuse stable prompt prefixes. The near-immutable core, including the system prompt, agent instructions, and core tool definitions, uses a one-hour cache checkpoint. More variable context uses a five-minute checkpoint that refreshes on a cache hit. Bedrock requires the longer-lived checkpoint to appear before the shorter-lived checkpoint. The shorter tier suits interactive sessions because idle context expires, while the one-hour tier can amortize its higher cache-write price across many reads. Cache benefits and supported TTLs depend on the selected model. Teams can verify behavior through the cacheReadInputTokens and cacheWriteInputTokens usage fields and measure time to first token for their own workloads.
# Schematic cache checkpoints in Converse content blocks {"cachePoint": {"type": "default", "ttl": "1h"}} # stable core {"cachePoint": {"type": "default", "ttl": "5m"}} # variable layer Builder takeaway: Treat inference as a routing-and-caching problem, not only a model-selection decision. Select the Claude model per workload, choose the appropriate cross-Region inference profile, and cache the stable prompt prefix with TTLs that match how frequently each layer changes.
Distilled from Postman’s journey, for builders working on Amazon Bedrock:
Building Agent Mode required Postman to confront the gap between large language model capabilities and the structure of mature products: interface assumptions, coupled clients, sprawling tool catalogs, and knowledge distributed across documentation and teams. Dynamic tool selection, schema-based reads, and deliberate context engineering emerged as repeatable patterns at the scale of Postman’s developer community. Amazon Bedrock provides the managed model access, cross-Region inference, model-dependent retention controls, and prompt caching that support the production architecture.
Whether you’re building your first agent or scaling an existing one, these patterns can help teams avoid common agent-integration and scaling challenges.
To learn more, see the Amazon Bedrock documentation, including guidance for cross-Region inference, prompt caching, and data protection and retention. For related implementation guidance, read Effectively use prompt caching on Amazon Bedrock and Amazon Bedrock announces global cross-Region inference for increased throughput on the AWS Machine Learning Blog. To explore the product, see the Postman Agent Mode documentation.
Postman’s production implementation is proprietary and isn’t available as a public sample repository.
Srinivas is a Senior Engineer on Postman’s AI team, building enterprise agents at the intersection of distributed systems and AI infrastructure. His focus is core agent architecture that keeps agents reliable and accurate at scale.
Shubham is a Solutions Architect at AWS based in Bengaluru, India, supporting independent software vendors (ISVs). He works with engineering and leadership teams to design, build, and run their products on AWS, from first architecture to production, with a deep focus on generative AI and resilience at scale. Outside of work, Shubham is an avid hiker who brings the same preparation and persistence from the trail to building systems that last.