Every team building AI agents eventually hits the same wall. The demo works. The agent calls the right tool, gets a reasonable answer, and everyone in the room nods. Then someone tries to run it against real systems with real data, and it falls apart in ways that have nothing to do with the model.
It can’t find the right API among a dozen similarly named internal services. It calls an endpoint that changed six months ago because nobody updated the reference it was trained on. It has a credential with more access than the task needed, sitting in a config file where anyone, or anything, could read it. Nobody can tell you what it did last Tuesday or what it’s costing you this month.
None of that is a model problem. It’s an infrastructure problem, and it’s the same one every generation of production software has had to solve: how do you give a new class of consumer safe, reliable, observable access to your systems? We solved this for human developers over two decades of API tooling. Now agents are the ones making the calls, and the infrastructure underneath them has to catch up.
I’ve had some version of this conversation dozens of times with customers, and heard it echoed by hundreds of developers at our Agents & APIs meetups. Once you strip away the specifics of each team’s stack, the same pattern shows up underneath: four fundamentals, each solving a distinct failure mode that shows up once agents, not humans, are driving your API traffic.
Fundamental 1: A system of record agents can reason over #
Before an agent can call an API well, it has to know the API exists, know which version is canonical, and know who’s responsible for it. Most organizations don’t have a clean answer to that. They have a Confluence page from two years ago, a Slack thread where someone finally figured out which of the seventeen payment APIs is the real one, and tribal knowledge that leaves with whoever holds it.
Humans route around this kind of mess through experience and asking around. Agents can’t. If your API surface isn’t captured somewhere structured, an agent either can’t find what it needs or, worse, confidently uses the wrong thing.
This is what Postman calls context debt, and it’s why the platform’s foundation is a Context Graph: a continuously updated map of every API, service, contract, and dependency across an organization. It’s not documentation in the sense of a page someone wrote once. It’s a live index that can answer “which payment API is canonical, who owns it, and what breaks if I change it” the same way every time, whether the thing asking is a person or a model.
Postman exposes this context two ways. Postman Agent Mode works alongside developers inside the workspace in real time, drafting tests, filling out collections, and flagging contract issues as they’re written. The AI Engineer is the more autonomous piece: a sandboxed agent that explores undocumented APIs, runs design reviews, and checks pull requests for contract regressions, with write access gated behind human approval rather than granted outright. Postman’s own writeup on the AI Engineer is worth reading if you want the deeper mechanics.
The part that matters beyond Postman’s own workspace is the Postman MCP Server, which exposes the API Catalog and Context Graph through the Model Context Protocol. That means an agent running in Claude Code, Cursor, or any other MCP-compatible tool can pull real organizational context instead of guessing at it from training data. The source code is on GitHub if you want to see how it’s wired up. This is the layer everything else depends on: without a real system of record, the other three fundamentals have nothing accurate to work from.
Fundamental 2: APIs that are actually discoverable by machines #
Assume the context problem is solved and an agent has found the API it needs. Next problem: can it actually call it correctly on the first try?
Most API documentation is written for people. Prose descriptions, example payloads, schemas that are typed loosely enough for a human to fill in the gaps by inference. That works fine when a developer is reading a portal and applying judgment. It’s structurally opaque to a model, which ends up in a loop of inference and trial and error: guessing at auth headers, hallucinating parameters that don’t exist, retrying against a schema it never actually understood.
At human-scale request volume, that’s an annoyance. At agent scale, where a single workflow might make hundreds of calls in a session, it’s a reliability problem that compounds. This is the gap Fern is built to close, by re-indexing API surfaces into typed, machine-readable formats and strongly typed SDKs that a model can parse directly instead of inferring from prose.
The reasoning here tracks with what’s showing up in the broader ecosystem. MCP itself exists because tool definitions need to be structured and discoverable rather than described in free text for a model to use them reliably. The pattern holds at every layer: the more your API surface reads like data instead of prose, the fewer wrong guesses an agent makes before it succeeds.
Fundamental 3: Access control built for delegated, dynamic identities #
Traditional API gateways and credential management assume human-shaped traffic: a known client, a predictable access pattern, a credential scoped once at deploy time and rarely touched again. Agentic systems break all three assumptions at once. A single orchestrated workflow can fan out across dozens of internal services under a delegated identity, with a scope that got decided at prompt time, not deploy time. An agent that spawns sub-agents needs each of them to inherit a narrower slice of access, not a copy of its own.
The data backs up how badly this is already going. GitGuardian’s 2026 State of Secrets Sprawl report found AI-assisted commits leaking hardcoded secrets at more than double the rate of human-only commits. Industry coverage of agentic identity and access management is converging on the same conclusion: the gateway has to evolve from a traffic router into an identity enforcement point. It needs to verify delegation claims and apply policy before a request runs, not after.
Postman’s answer splits into two pieces that work together. Fabric Gateway is the control plane, deployed inside your own cloud, that routes and governs traffic across models, MCP servers, agents, and internal APIs, enforcing policy and circuit-breaking consistently so individual services don’t each have to build their own agent-aware auth logic. Postman Passport is the credential layer underneath it, and it takes a genuinely different approach to the secret-sprawl problem than most credential managers. Instead of distributing real API keys to whatever is asking for them, it issues credential references: tokens bound to a specific identity that are useless without a matching private key. The actual API keys stay inside your VPC and get resolved at a Secure Access Proxy, never touching the agent’s reasoning layer or showing up in a log. If a credential reference leaks, there’s no underlying secret for anyone to exploit.
That’s a meaningfully different security posture than rotating leaked keys after the fact. It’s proactive instead of reactive, which matters a lot more once the thing holding your credentials is a model that can be prompted, tricked, or makes a mistake at 3 a.m. with nobody watching.
Fundamental 4: Operations for a workforce that includes agents #
Say the first three fundamentals are handled. Your agents can find the right APIs, call them correctly, and only touch what they’re scoped to touch. You still don’t know how many agents are actually running, which ones are worth the compute they’re burning, or whether the one your sales team built six months ago quietly stopped working three weeks ago.
This is the gap most teams don’t notice until it’s expensive. Agents get built, shipped, and then forgotten, because nobody owns the equivalent of an on-call rotation for them. There’s no shared registry, so the same agent gets rebuilt by three different teams who didn’t know the others had already solved the problem.
Astro is Postman’s answer to that operational gap, and its framing is deliberately less about governance and more about “agents become teammates”: one place to deploy agents, track how they perform, see what they cost, and decide where to invest more. A shared agent registry and reusable blueprints mean a PR review agent built by one team doesn’t have to be rebuilt from scratch by the next. Built-in tracing means agents get tuned against how they actually behave in production instead of a benchmark score, and cost visibility broken down by agent, model, and team turns “should we scale this” into a data question instead of a guess.
Where Fabric Gateway answers “is this specific request authorized right now,” Astro answers “which agents are running, how are they doing, and are they actually making the team better.” Audit trails and guardrails live here too, but they’re in service of that broader operational question rather than being the whole point.
How the four fundamentals fit together #
| Fundamental | The failure mode without it | What it needs to provide |
|---|---|---|
| System of record | Agents can’t find or trust the right API | A live, queryable map of APIs, owners, and dependencies |
| Discoverability | Agents guess at parameters and hallucinate calls | Typed, machine-readable schemas and SDKs |
| Access control | Broad, static credentials leak or overreach | Scoped, short-lived, delegation-aware access |
| Operations | Agents run unmonitored, uncosted, and unowned | Registry, tracing, and cost visibility across teams |
These aren’t four separate tools you bolt on in whatever order is convenient. They compose in sequence. The system of record gives the discoverability layer something accurate to index. The access control layer decides what an agent can actually reach once it’s found and called the right API. And none of it means anything operationally unless you can see which agents are running, what they’re doing, and whether they’re worth what they cost.
Skip the first fundamental and the other three are built on sand: perfectly typed, perfectly scoped, perfectly observable calls to the wrong API. Skip the third and you’ve built a fast, well-documented way to leak credentials at scale. The order matters because each layer assumes the one below it is solid.
Where I’d start #
If you’re building agents today and none of this exists yet, don’t try to solve all four at once. Start with the system of record. It’s the least glamorous of the four and the easiest to skip, which is exactly why most teams skip it, and it’s also the one everything else silently depends on. An agent with perfect credential scoping and full observability that’s still calling the wrong API is still broken, just in a well-monitored way. After that, access control is the one I’d prioritize over discoverability or operations, mainly because the cost of getting it wrong is asymmetric. A confusing API surface makes agents slower and less reliable. A leaked credential can be a genuine incident.
Getting familiar with the Model Context Protocol is a reasonable place to start regardless of which platform you land on, since it’s an open standard rather than something proprietary to any one vendor. Whatever you use to fill in these four fundamentals, the underlying question is the same one Postman poses: it’s no longer really about whether your APIs are ready for AI. It’s whether your AI is ready for production.
Resources #
The Postman MCP Server documentationPostman MCP Server on GitHubModel Context Protocol specificationIntroducing the AI EngineerThe New Postman: AI-native and built for the agentic eraGitGuardian State of Secrets Sprawl 2026