Watch on YouTubeCoding agents work well within one repository, but distributed systems require context about services, endpoints, consumers, dependencies, and data flows across many repositories.
Postman's API context graph grounds architecture information in source-code lines and production telemetry, which improves API discovery, API redesign analysis, and impact assessment.
A stale graph quickly damages developer trust, so keeping the graph synchronized with code and telemetry is as important as building it.
Kamalakannan Nandagopal explains how Postman extended coding agents beyond work inside a single repository. Postman's cloud platform has more than 150 microservices and thousands of REST endpoints, spread across many repositories and environments. The team built an API context graph that maps services, endpoints, implementations, calls, consumers, databases, caches, and application entry points. Each data point is tied to a line of code or production telemetry. In evaluations based on real pull requests and design decisions, the graph helped agents find the right API, understand the different request shapes used by consumers, and assess downstream impact. It also enabled a 21-page architecture review. The system failed when new consumers appeared after an evaluation was written, showing that stale context causes bad answers and loss of trust. Nandagopal argues that API context is a practical foundation for coding agents in distributed systems, with business semantics and explanations of design intent as the next additions.
Nandagopal says agents perform well on greenfield projects and fixes inside one project. Production systems are different: they span multiple microservices, environments, versions, applications, and hundreds of repositories. A front end, CLI, and API may all call shared back-end infrastructure. An agent that sees only one repository cannot reliably understand the full workflow or the effects of a change elsewhere.
Documentation is a natural starting point, but it takes time to write and maintain. Nandagopal cites research that documentation written and maintained only by language models degrades exponentially over time, so human curation is still needed. Skills and MCPs depend on the context supplied to them. Agent memory captures tribal knowledge, but it remains tied to an individual user because standard ways to share that memory across an engineering organization have not emerged.
Postman's go-to-market teams had built a centralized context layer from structured data gathered across multiple sources. The engineering team applied the same idea to distributed systems. Nandagopal argues that APIs define what each microservice owns, while calls between APIs reveal workflows that span services. This makes API information a useful context layer for agents working across a distributed architecture.
Postman cataloged every production microservice and its REST endpoints, then recorded the exact code line implementing each endpoint. The graph also maps service-to-service and endpoint-to-endpoint calls, data flows through databases and caches, and interactions from front ends and CLIs into the back end. The team indexes this information with an LLM, but requires every data point to be grounded in source code or an exact production-telemetry trace.
The team converted real pull requests and design discussions into evaluations. Each evaluation captured what a developer intended, what actually happened, and which decision was accepted as the ground truth. They compared a Postman agent connected to the graph with Claude Code using ordinary GitHub code search, and with Claude Code given the graph as a skill. Scores ran from zero to five, alongside token counts, so quality and efficiency could be judged together.
For API discovery, the graph performed well when an agent had to choose the right endpoint among many APIs that might provide similar functionality. The harder redesign case involved a free-form JSON property that began with one attribute and later carried 15 attributes across several services. The graph showed each consumer's exact input shape and the implementation context behind it. Pure code search struggled, while the Postman agent could reason about why consumers used the API differently.
The team also asked which systems might be affected by changing an API or replacing a V2 endpoint with a V3 design. The Postman agent produced higher-quality results while using about half or one-third as many tokens as pure code search in the example shown. The graph gave it a view of consumers and downstream dependencies that a single repository could not provide.
One impact-assessment evaluation failed because new consumers appeared between the time the evaluation was written and the time it ran. The graph scored poorly and consumed many tokens. Nandagopal says the graph must stay synchronized with ground truth, including newly added and removed APIs and dependencies. A gap in the graph produces a gap in the answer, and that quickly leads developers to stop using the system.
Once the graph was available, the team asked the Postman agent for an end-to-end architecture review. It produced a 21-page report covering dependency cycles, risky long-running migrations, single points of failure, and gaps where implementation did not appear in telemetry. The report also proposed actions for the CEO, CTO, and staff engineers. Nandagopal presents this as a new class of questions that agents could not answer from a single repository.
"But one key principle that we had in mind always was every single data point that landed on the context graph always had to be grounded down in a hard truth."05:24