Skip to content
Innovation & Growth Talking point

AI-built knowledge for coding agents should trace every fact to code or telemetry

Postman's engineer says each fact in its API map must point to real code or live traces.

W
WebPulse Newsroom
AI-assisted · 2 min read
Share on X LinkedIn
AI-built knowledge for coding agents should trace every fact to code or telemetry
In brief
  • Postman built a map of its services for coding agents. Every entry had to point to a line of code or a real production trace.
  • The speaker said stale context costs developer trust. Our reading is that a required source makes an AI-built knowledge layer easier to check.

Kamalakannan Nandagopal, a staff engineer at Postman, argued that an AI-built map of a company's software should hold only facts it can trace to real code or live production data. He made the case on the AI Engineer show. Postman built such a map across its 115 microservices so coding agents could work beyond a single repository.

What was said

Nandagopal said coding agents do well on new projects and on fixes inside one project. Production systems are harder. They split across many services, environments and hundreds of repositories.

Documentation is the usual first fix, but he noted that developers dislike maintaining it. He also cited research that documentation written and kept up only by LLMs tends to degrade exponentially over time. Some human curation is needed, he said.

So Postman built an API context graph. It catalogs every service and endpoint, records the exact line of code behind each one, and maps how services call each other. It runs down to databases and caches. An LLM indexed the data, but one rule held. In his words, "every single data point that landed on the context graph always had to be grounded down in a hard truth." That truth was either a line of code or an exact trace from production telemetry, meaning records of real requests.

Freshness mattered too. He said "any delays in syncing your context graph with the ground truth creates gap in the result." A gap, he added, costs developer trust and then usage.

Why it matters

Our reading: an AI-written knowledge layer is risky because agents read it and then act on it. A wrong note can shape the next piece of work. Nandagopal did not put it this way, but his rule addresses it. If each fact needs a source, a reviewer or a script can check it.

For teams building agent tooling, the lesson is to decide what counts as evidence before filling the layer. For buyers, a simple question follows. What does each claim in an agent's memory point to? A tool that cannot answer is asking for trust it has not earned.

The other side

The excerpts stop before the results. We cannot report how much the graph improved Postman's evaluations, or whether grounding was the cause.

Grounding also has limits. A line of code proves a fact existed. It does not prove the fact is the right one to give an agent, or that nothing is missing. An LLM still indexed the data, and Nandagopal himself said human curation helps.

Upkeep is a cost as well. His own warning about sync delays shows the graph must keep pace with the code. He also said no standard yet exists for sharing agent memory across a team.

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

Share this insight