The common complaint about AI coding agents is that their context windows are too small. Talia Kohan at Postman argues that’s the wrong diagnosis.
The actual problem is that the information an agent needs to do useful work isn’t organized anywhere. It’s scattered across other repos, other teammates, earlier service contracts, internal APIs nobody has cataloged, deprecated endpoints, a policy doc that hasn’t been touched in six months, and a Slack thread that answers half the question.
The Scattered Knowledge Problem
Even in a small startup running a dozen services, the context a coding agent needs to make a correct decision is fragmented across multiple systems. At enterprise scale with five hundred services, the problem compounds. No single tool currently maps all of it.
Kohan points to the various partial solutions teams reach for: an API registry, an ownership map, a dependency graph, an internal developer platform, or a “single pane of glass” project the platform team has been slowly threading through the roadmap for the last two quarters. Each solves a slice of the problem. None solves the whole thing.
Why This Matters for Operators
If you’re building internal tooling with AI agents, or evaluating whether to hand a coding agent access to your codebase, this framing is worth internalizing. The agent isn’t going to surface what it can’t reach. An API it doesn’t know exists, an auth flow documented only in a Slack thread, a rate limit buried in a vendor contract — these are the things that cause an agent to produce code that looks right and breaks in production.
The article, published on the Postman Blog, connects to the broader push around Model Context Protocol and OpenAPI specifications as structural approaches to making codebases more legible to agents. Postman’s angle here is clearly informed by their API tooling position, but the underlying observation holds regardless of which tool you use to act on it.
