Kamalakannan Nandagopal is a software engineer whose work at Postman spans desktop application internals, API collection execution, and the context coding agents need to understand distributed systems. His work connects the machinery developers use to build and test APIs with a practical challenge for autonomous software development: an agent editing one repository needs to understand the services and consumers that depend on it.
From API user to platform engineer
Nandagopal began as a front-end engineer at Zoho, where he first used Postman. He joined Postman around 2017 and moved from using the tool to building its underlying machinery. His early engineering work included the non-UI portions of Postman's Electron applications, build infrastructure, and an overhaul of the native application's data access and storage layer.
He also contributed to postman-runtime, the open-source engine for executing API collections. These projects placed his work beneath the visible interface: application internals, collection execution, and the build and test infrastructure supporting the desktop product.
That work also extended to native Git integration. Nandagopal connects his team's Git integration work with making API collections easier for humans and agents to author and review. Postman's accompanying format announcement describes YAML and component files for collections. Together, these changes connect the desktop application to version-controlled authoring, giving collection changes a form that developers and coding agents can work with and review.
Giving agents a map beyond their repository
Postman's distributed system contained 115 microservices and thousands of endpoints. Nandagopal's approach to agent context addresses why that scale creates a problem: documentation becomes stale, skills and MCP connections depend on the information supplied through them, and an individual agent's memory does not automatically become shared organizational knowledge.
Borrowing an insight from Postman's go-to-market team, the engineering team treated APIs as the context layer connecting the system. They built an API context graph that maps services, endpoints, implementations, and calls down to databases, grounding its data in source code or production telemetry. This gives an agent a way to investigate relationships that its local checkout cannot reveal.
The work supports three related kinds of investigation:
API discovery: Find relevant endpoints and services across the system rather than relying on what happens to be documented in one repository.
API redesign: Understand an API's implementation and relationships before proposing changes, so the agent can reason about the surrounding system as well as the code it edits.
Impact assessment: Identify callers and dependencies that may be affected by a change, including relationships visible through production telemetry.
Nandagopal and the team evaluated this approach using real pull requests and design decisions. They reported improvements in discovery, redesign, and impact assessment, alongside a failure caused by stale graph data. That failure gives his argument an operational requirement: building the map is only useful if it continues to reflect the system agents are changing. Postman's Context Graph API makes these relationships available for dependency investigation.
Measuring whether API workflows finish the job
Nandagopal also co-authored APIFlow-Bench with Zelin Wan, Arash Nourian, Xiaoxiao Li, and Nihar Nandan. The benchmark evaluates dependent REST-API workflows, where an agent's later actions can rely on state created by earlier calls.
Its central distinction is between successful state changes and correct final delivery. An agent may produce the intended backend state yet return an incorrect or unusable answer to the user. Evaluating both outcomes makes the workflow accountable to the complete task, rather than treating plausible API calls as sufficient evidence of success. The benchmark's grading mechanism traces a canary through the actual API data flow and checks typed answers field by field. On its clean 20-subtask slice, 77% of failing runs failed only at delivery after reaching the correct state—a result that locates much of the observed failure in the handoff to the user, rather than in the backend changes.
The team's public implementation includes the evaluation harness, synthetic task bank, and scoring machinery. The context graph and benchmark address complementary parts of agent reliability: understanding the system before acting, and checking whether those actions produce the result the user needs.
Postman’s API context graph connects endpoints, callers, implementations and production traces so coding agents can reason across repositories. Kamalakannan Nandagopal explains where that context improves discovery and redesign, why stale dependencies break it, and how cheaper analysis could move architecture checks into everyday development.
API context connects callers, endpoints, implementation code and data dependencies across repositories, giving agents a way to reason about distributed workflows.
Consumer-aware redesign requires both request shapes and their purpose. The graph's links into implementation context helped recover both in the free-form JSON example.
Freshness is part of correctness: new consumers caused an impact-assessment failure, and removed APIs or dependencies must also disappear from the graph.
Lower token costs could make architectural analysis frequent enough to run during PR review and local development, where problems can be caught earlier.
▶ Watch ↗