- Postman's Kamalakannan Nandagopal said a context graph that lags the code gives wrong answers. Developers lose trust and then use the tool less.
- His team saw this in a test, when new consumers of an endpoint appeared before the map caught up. He said keeping the map current matters as much as building it.
A map of your software that coding agents rely on is only worth having if it stays current. That was the argument of Kamalakannan Nandagopal, a staff engineer at Postman, on the AI Engineer show. When the map falls behind the code, he said, developers get wrong answers, stop trusting the tool, and stop using it.
What was said
Postman runs 115 microservices. Nandagopal's team built an API context graph for its coding agents. It maps services, endpoints and the calls between them, down to databases. Each data point is tied to code or production telemetry, meaning data from the live system.
In one test the graph failed. The agent was asked to find every downstream service affected by a pull request that changed an endpoint. It performed badly and used a lot of tokens, the units AI models charge for. The team traced the cause to new consumers of that endpoint appearing between the time the test was written and the time it ran.
His conclusion was about upkeep. In his words, "any delays in syncing your context graph with the ground truth creates gap in the result." He then described the human cost: "if there is a gap in the result, it immediately leads to a loss of trust by the developer, and that translates into lack of usage."
He added that removals matter too. A deleted API or dependency left on the map can also cause confusion. And changes of this kind are routine: when the team reviewed pull requests in its top 10 repositories, almost 75% had some effect on APIs.
Why it matters
Our reading: the cost of an agent's context map does not end when it is built. If most code changes touch the thing being mapped, the map is always aging. Developers carry the first cost, because they act on a wrong answer or learn to ignore the tool. The team that built it carries the second, as its investment goes unused.
For anyone buying or building this kind of tooling, one question follows. How does the map find out that the code changed, and how fast? A demo on a clean snapshot says little about that.
The other side
Nandagopal did not say a stale map is worse than having none. That comparison is our framing of his trust argument, and the excerpts do not test it. He also did not call freshness the main cost of agent tooling. His point was that it matters as much as populating the map.
The failure he described came up in an evaluation, not in a reported production incident. The excerpts also do not say how quickly Postman now syncs its graph, or what that costs. He did report strong results when the graph was fresh, including impact analysis that used a fraction of the effort of code search. The open question is how much upkeep it takes to keep those results.
Written by the WebPulse Newsroom with AI assistance, and checked by our editorial review: every quotation was verified against the recording's transcript. How we use AI.
The conversation this talking point comes from
- AI Engineer: We Mapped 115 Microservices for Our Coding Agents — Kamalakannan Nandagopal, Postman (2026-10-08)
