We Mapped 115 Microservices for Our Coding Agents — Kamalakannan Nandagopal, Postman
Kamalakannan Nandagopal from Postman explains why coding agents struggle beyond a single repo and how an API context graph, grounded in code and production telemetry, gives agents system-wide awareness. The talk covers evals built from real PRs, wins on API discovery, redesign and impact assessment, a stale-graph failure, and a 21-page architecture review generated by the agent.
Kamalakannan Nandagopal, staff engineer at Postman, starts from a simple observation: coding agents are very good inside a single repo, but production systems are distributed. Postman’s cloud features run on a microservices architecture of 115 services with thousands of REST endpoints. (The transcript says 150+, but the figure in the description is more likely the accurate one.) His talk is about how API context can take coding agents beyond code generation.
How coding agents evolved
- The first stage was line and function level autocomplete, the Copilot era.
- Next came full codebase refactors and one-shot implementations and fixes, the Composer and Claude Code era.
- Now there are fully autonomous workflows that start a task, make changes, verify them, open pull requests, and even review them.
Agents excel at greenfield projects and at fixes within one project. Production, however, is distributed across multiple microservices, multiple environments, and multiple versions of each service, with front end, CLI, and API applications all talking to a back end spread across hundreds of repos.
Why the usual context sources fall short
- Documentation is the obvious first place to look, but developers dislike writing and maintaining it. Research he cites suggests that LLM-only documentation degrades over time, so some form of human curation is still needed.
- Skills and MCPs are a good alternative, but they are only as good as the context they are given.
- Agent memory is a promising place where tribal knowledge is being captured, but it is still scoped to individual users. No standard pattern has emerged for sharing memory across teams or an entire engineering organization.
Borrowing from the go-to-market team
While engineering was struggling with this, Postman’s go-to-market team had built business agents on customer data pulled from many sources. They turned unstructured data into structured data and built a RAG plus graph RAG pipeline that served as a centralized context layer for all those agents.
The speaker’s key insight was that in a distributed system, APIs are the context layer. Each microservice owns one responsibility defined by its domain model, and its APIs express that responsibility. Calls between services reveal the workflows and user journeys that span multiple systems. As he puts it, agents are only as good as the context they are given.
Building the API context graph
The team built a graph of Postman’s engineering architecture in several layers:
- Cataloging every microservice running in production.
- Enumerating every endpoint each REST service exposes.
- Capturing how each endpoint is implemented, down to the exact line of code.
- Mapping how services call each other and how endpoints connect to one another.
- Tracing data down through the stack, including databases and caches.
- Mapping how front ends, CLIs, and APIs interact with the back end.
The data is indexed with LLMs into a centralized context graph. The governing principle is that every data point must be grounded in a hard truth, either a line of code in the codebase or an exact trace from production telemetry.
The populated graph shows familiar patterns: a tightly intertwined central cluster of core services, one or two bloated services at the outer edges, and the central services that are typically tier zero or tier one.
How the graph was evaluated
The evals were built from real GitHub PRs in Postman’s organization. For each PR, the team recorded what the developer intended and what the actual outcome was. For key projects, they also captured design decisions from design discussions, using the decisions that were ultimately made as ground truth.
Three setups were compared:
- Postman’s AI agent connected to the API context graph.
- Claude Code using straightforward GitHub code search.
- Claude Code with the same context graph exposed as a skill.
Each eval was scored from 0 to 5 and token usage was measured. In the results plot, the best outcome is top left (high score, few tokens). Top right means a good score but expensive. Anything below the dashed line did not meet the bar.
Results by use case
- API discovery: the example was finding the right API to get a user’s profile name. This is pure search, and the graph-backed agents scored well above code search, which struggled. The gap between Postman and Claude was small enough that the speaker did not dig into it.
- API redesign: this is the most interesting scenario. A developer ships a feature with a free-form JSON property and a TODO to define a schema later. Two weeks on, that property carries 15 attributes and is passed by anywhere from five to ten services. Finding every consumer and the exact input shapes is hard, because production logs lack detail and privacy rules may restrict access, and understanding why each consumer chose its shape is harder still. The Postman agent almost fully solved it. The graph knew every consumer, and because each API was grounded in its implementation code, the agent could read the surrounding context to understand why each change was made. Claude with the skill did better than plain code search but gave up after a number of turns and waited for confirmation.
- Impact assessment: the question is what a change to an API will affect downstream, or how V2 is used before designing V3. Here the graph really shines. The Postman agent produced higher-quality output using roughly half to a third of the tokens of pure code search.
A failure: the stale graph
Not everything went smoothly. In one impact assessment eval, the Postman agent scored badly and consumed a large number of tokens. The investigation found that new consumers of the endpoint had appeared between the time the eval was written and the time it was run. The lesson is that building the graph is not enough. It must be kept current, because any sync delay creates gaps in results. Those gaps erode developer trust and reduce adoption. Detecting removed APIs and dependencies matters just as much as detecting new ones, since stale removals cause confusion too.
Why this matters: 75 percent of PRs touch APIs
Looking back at PRs across the top 10 repos, the team found that roughly 75 percent had some effect on APIs. Either they changed an API’s external surface or they integrated a new API, and both can cascade downstream. The graph enabled before-and-after comparisons, and it also made it possible to ask questions the team could not previously answer.
The 21-page architecture review
The team then asked the Postman agent for a complete end-to-end engineering analysis of the ecosystem. It produced a 21-page report identifying weaknesses and vulnerabilities:
- Dependency cycles, which are a risk during incidents.
- Risky long-running migrations, which signal technical debt.
- Single points of failure.
- Blind spots in telemetry, where implemented behavior does not show up in monitoring.
- Concrete action items for the CEO, the CTO, and staff engineers.
This was the team’s ’light bulb moment'.
What comes next
The team plans two main extensions. The first is a semantic layer describing what the business does, connected to the context layer that coding agents consume. The second is adding reasoning about why data models, domains, and APIs exist, and why one API should be preferred over another. Both should improve downstream coding decisions.
Takeaways
- The API context graph serves as the context layer for coding agents in distributed systems. It offers a system-level view that a single repo or microservice cannot provide.
- It shortens the time needed to find the right approach to a problem, with better quality or greater efficiency.
- Efficiency matters because it makes it practical to run evals far more often, at the PR level or even on a developer’s own machine. Catching problems earlier in the lifecycle is the real goal.
The capabilities are available within the Postman platform as early access. The speaker is available after the talk for questions, and Postman has a booth, S32, across the hall.