{ "video": { "id": "k2ClBT4aqAg", "title": "We Mapped 115 Microservices for Our Coding Agents — Kamalakannan Nandagopal, Postman", "duration": 1046, "upload_date": null, "channel": "AI Engineer", "source": "AI Engineer", "event_format": "" }, "analysis": { "video_id": "k2ClBT4aqAg", "title": "We Mapped 115 Microservices for Our Coding Agents — Kamalakannan Nandagopal, Postman", "one_liner": "In a microservices architecture, APIs are the context layer for coding agents: Postman built an API context graph in which every data point is grounded in a line of code or a production trace, and it improved agent quality and token efficiency on real-PR evals, but only while the graph stayed in sync with reality.", "summary": "Kamal, a staff engineer at Postman, argues that coding agents do well on greenfield work and single-repo fixes but struggle in production distributed systems, where code is spread across hundreds of repos and more than 150 microservices. Docs, skills, MCPs and per-user agent memory don't solve this. Taking a cue from Postman's go-to-market teams, who built a RAG plus graph RAG context layer for their agents, Postman cataloged every production service, endpoint, implementation line, service-to-service call and data path, then indexed it all with an LLM into an API context graph. Evals built from real PRs and design decisions compared the Postman agent, Claude Code using GitHub code search, and Claude Code using the graph as a skill. They showed big wins for API redesign and impact assessment. They also showed one failure caused by a stale graph, and the graph made possible a 21-page architecture review.", "key_points": [ "Postman runs more than 150 microservices and thousands of REST API endpoints, spread across hundreds of repos, with front-end, CLI and API apps all calling the back end.", "Why the usual fixes fall short: developers hate maintaining docs, and research says purely LLM-written docs degrade exponentially over time, so human curation is needed. Skills and MCPs are only as good as the context they get. Agent memory is limited to one user, and there's no standard pattern yet for sharing it across a team.", "The graph catalogs every production service and endpoint down to the exact line of code that implements it. It maps service-to-service and endpoint-to-endpoint calls, data flows through databases and caches, and how front ends, CLIs and APIs use the back end. Every data point must be grounded in a 'hard truth': a line of code or an exact production telemetry trace.", "Evals came from real PRs in Postman's GitHub repos and from past design decisions, with the decision actually taken used as ground truth. Each run was scored 0–5 and its tokens counted. Three setups were compared: the Postman agent with the graph, Claude Code with plain GitHub code search, and Claude Code with the graph as a skill.", "API discovery (e.g. which API returns a user's profile name): both graph setups scored well and code search did poorly, with only a small gap between the Postman agent and Claude.", "API redesign (a free-form JSON property with a 'add a schema in 2 weeks' TODO that grew to 15 attributes across many consumers): the Postman agent found every consumer's exact input shape because the graph knows every consumer and links to the code around each one. Claude with the skill did a bit better than code search but gave up after enough turns and waited for the user.", "Impact assessment (e.g. study V2 usage before designing V3): the Postman agent gave better quality using about half to a third of the tokens of code search. One failure, finding downstream services affected by a PR, came from new consumers added between writing the eval and running it. A stale graph lowers accuracy, costs trust and then usage, and detecting removed APIs matters as much as detecting new ones.", "About 75% of PRs in the top 10 repos affected APIs. Asked for an end-to-end architecture review, the agent wrote a 21-page report covering dependency cycles, risky long-running migrations, single points of failure and blind spots in telemetry, with action items for the CEO, the CTO and staff engineers." ], "takeaways": [ "Treat API definitions and inter-service calls as the context layer for agents in a distributed system, rather than relying only on docs or per-user agent memory.", "Ground every fact in the context graph in a line of code or a production trace, not in content an LLM wrote.", "Keep the graph continuously in sync, including removed APIs and dependencies, because a stale graph quickly costs developer trust and usage.", "Build evals from your own historical PRs and design decisions, with the real outcome as ground truth, and track both score and token cost.", "Spend the efficiency gains on running these analyses more often, at PR level or on the developer's machine, so problems are caught earlier." ], "topics": [ "coding agents", "context engineering", "microservices", "knowledge graphs", "evals", "api design", "impact analysis", "graph rag" ], "tools": [ "Postman", "Postman AI agent", "Claude Code", "GitHub", "GitHub code search", "GitHub Copilot", "Cursor Composer", "MCP" ], "quotes": [ { "text": "in a distributed systems and microservices architecture, APIs are the context layer for you.", "at": "04:04", "url": "https://www.youtube.com/watch?v=k2ClBT4aqAg&t=244s" }, { "text": "every single data point that landed on the context graph always had to be grounded down in a hard truth", "at": "05:36", "url": "https://www.youtube.com/watch?v=k2ClBT4aqAg&t=336s" }, { "text": "if there's a gap in the result, it immediately leads to a loss of trust by the developer, and that translates into lack of usage.", "at": "13:17", "url": "https://www.youtube.com/watch?v=k2ClBT4aqAg&t=797s" }, { "text": "we noticed that almost 75% of the PRs had some effect on the APIs.", "at": "13:41", "url": "https://www.youtube.com/watch?v=k2ClBT4aqAg&t=821s" } ], "words": 3922 }, "summary_url": "/#k2ClBT4aqAg", "transcript": { "html": "/transcripts/k2ClBT4aqAg.html", "txt": "/transcripts/k2ClBT4aqAg.txt", "vtt": "/transcripts/k2ClBT4aqAg.vtt" } }