Watch a developer start an agent session on real enterprise work and you will see a ritual. Before the first useful prompt, they gather. They paste the deployment standard, link the runbook, and explain what the criticality tiers mean. Then they correct the agent's first confident guess about a naming convention the team retired two years ago. Tomorrow they will do it all again, because the agent will not remember.
We have quietly decided that this gathering is the developer's job. Every guide to working with AI repeats some version of the same advice: give the model good context. So developers hunt for it, one session at a time, across systems that were never designed to answer an agent's questions.
I think that framing is backwards, and I think fixing it is platform work.
In Your Platform Has a New User: The Agent, I argued that internal platforms now serve two personas: the developer and the developer's agent. Near the end, I wrote that context is becoming part of the platform. I called it one of the most important developer experience problems of the next few years. That idea got four paragraphs. It deserves an essay, so here is the longer version.
The gathering is the tax
Agents can remember more than they used to. What they cannot reliably accumulate on their own is organizational truth.
A new engineer pays the onboarding cost once, then amortizes it over years of context, hallway conversations, and scar tissue. An agent may retain instructions, memory, or project state. None of those automatically tell it which standard is authoritative, which exception still applies, or which decision was reversed six months ago. Whatever it needs to know about your organization still has to come from somewhere.
Now multiply that across hundreds of engineers. People rediscover the same standards, fork the same repo, re-paste the same runbooks, and retype the same corrections, day after day. Quality varies too. Your strongest engineers assemble excellent context and get excellent output. Everyone else gets whatever the search index returns first, which is often the wiki page from three years ago that still outranks the current standard.
Here is the part that should bother platform owners: the tax grows with adoption. The better your AI rollout goes, the more hand-assembly your organization performs. Success makes the problem bigger.
Teams are already voting on the solution with their repositories. Every CLAUDE.md, every AGENTS.md, every set of AI rules is a developer hand-building a context layer, one repo at a time. When many teams independently build the same scaffolding, a platform capability is sitting there waiting to be claimed. We have watched this movie before with build scripts, deploy tooling, and observability config. Context is next.
The platform-owner question
Here is the question I keep returning to: who makes the organization's knowledge usable by the agent? At most companies, the honest answer today is each developer, per session, which is another way of saying nobody.
Consider what an agent needs to do real work inside an enterprise. It needs service ownership and dependency information. It needs the approved architectural patterns and the deployment requirements that go with each application tier. It needs API definitions, security classifications, observability conventions, naming standards, environment details, coding conventions, runbooks, and enough operational history to know which integration test has always been flaky.
I listed where all of that lives in the last essay: Git, the developer portal, Confluence, tickets, Slack, and people's heads. The scatter is old news. What changes with agents is the price of the scatter, because an agent cannot walk over to your desk and ask.
The platform question is not how developers can gather all of this faster. The platform question is why they are gathering it at all.
Platform teams exist to take work that every delivery team would otherwise absorb and turn it into a shared capability. Context assembly now fits that description exactly. Readers of the book will recognize the instinct: this is the Context Spine argument, operating at organizational scale.
Trusted is the load-bearing word
Enterprises are drowning in context. The scarce resource is trusted context.
The tempting version of this is a crawler, a vector database, and a chat window. Point retrieval at everything the company has ever written and demo it on a Friday. I understand the appeal. It solves discovery, but discovery is not the same as authority.
Retrieval without an authority model is just ranking. A retrieval system can find the deprecated standard, the abandoned experiment, and the current requirement side by side. It can even rank them intelligently. What it cannot know on its own is which answer the organization has chosen to stand behind. Feed an agent contradictory guidance and it produces confident contradiction, faster than any human could.
So the platform job is curation, and trusted has to mean something specific. I would hold a context layer to six properties.
Canonical means the organization has picked one answer per question, on purpose. If five deployment patterns exist in the wild, the layer knows which three are supported and which two are archaeology. Versioned means standards carry history, so an agent knows which rules applied when a service shipped. Fresh means staleness gets measured like uptime instead of discovered during an incident.
Attributable means every answer traces to a source and an owner, so a wrong answer becomes a bug report with a recipient. Accessible means machine-readable and queryable through a real interface, so agents ask instead of scraping prose and hoping. Safe means context inherits the access controls of the systems it describes. Security classifications do not stop applying because retrieval got convenient.
Read the list again and notice its shape. Those are the properties we already demand from any production API, and that is the point. Context deserves the same engineering discipline we apply to the systems it describes.
Context gets an owner and an interface
Treating context as a platform capability changes three things.
First, context gets an interface. Agents query a service catalog, a standards endpoint, or a policy engine instead of scraping documents. Model Context Protocol servers are one plumbing option, and plain versioned APIs work fine too. The plumbing will change. The authority model behind it is the part only your organization can supply, and the part that lasts.
Second, context gets owners. Every canonical answer has a name attached, drift becomes that owner's bug, and deprecation becomes a real operation. Half of this job is demotion and deletion. The old pattern gets marked superseded, with a pointer to its replacement, instead of lingering at the top of search results for another three years.
That also lets context survive the people who originally knew it, which is one of the quiet jobs of any good platform. Architects change roles, subject-matter experts leave, and teams reorganize. The best platforms turn what those people knew into inherited capability. The right path stops depending on who happens to remember why a decision was made.
Third, context gets enforcement. I wrote in the last essay that standards are more valuable when they live in systems than when they live in documents. The same holds here. Ownership metadata required at deploy time is context with teeth, and so is a policy engine that rejects a noncompliant manifest and names the fix. A wiki page is a suggestion.
Cloud platforms standardized infrastructure. The next platform layer standardizes context.
The obvious objections
This is documentation with extra steps. I would flip that: documentation is a context layer with no steps. A document describes, while a context layer answers and enforces. Nobody gets paged when a wiki page goes stale, and no pipeline fails when a README contradicts the automation. The distance between a page about service ownership and a deploy gate that requires ownership metadata is the distance between advice and infrastructure.
Context windows keep growing. Soon the agent can read everything. A bigger window changes how much you can feed the model. It does nothing about whether what you feed it is true, current, or something the requester is allowed to see. Pour a million tokens of contradictory guidance into a larger window and you get the same contradiction at greater length. Abundance makes curation more valuable, the same way abundant generation makes constraints more valuable.
The vendors will solve this. Vendors will ship better protocols and better retrieval, and I will happily use both. What no vendor will ever ship is the knowledge that your organization supports exactly three deployment patterns, or what Tier F means at your company. Authority does not come in the box.
Where to start
Start embarrassingly small. Write down the ten questions your agents and your new engineers ask most often. The two lists will overlap more than is comfortable, which is its own lesson: agent readiness and developer experience keep turning out to be the same work.
For each question, name an owner and pick the single canonical source. Make that source queryable through whatever interface your agents already use, then demote the copies. Measure freshness the way you measure availability. When an agent pulls a wrong answer from your own context, file it as a platform defect, because that is what it is.
One concrete first move: generate the shared sections of your teams' agent instruction files from the platform itself. Teams increasingly hand-write organizational context into CLAUDE.md, AGENTS.md, and similar files, then rely on someone to keep it current. Ownership, tier, approved patterns, and deploy paths are often facts the platform already knows. Let the platform write that part of the file, let teams keep the local knowledge, and freshness stops depending on anyone's memory.
We spent the last decade building platforms so developers would stop hand-assembling infrastructure. The gathering ritual at the top of this essay is the same problem, one layer up.
Organizations that treat trusted context as a platform capability will onboard their agents once, through the platform. Everyone else will keep running onboarding by hand, one session at a time.
Originally published at vinny.dev, where I write one essay a week on engineering leadership and the agentic SDLC. This one is a companion to Your Platform Has a New User: The Agent.
