The hardest unsolved problem in agent infrastructure is not compute, sandboxing, or model routing. It is context management. And the part nobody is honest about is that most of the context an agent needs is not technical — it is organizational.
For engineering agents, context means repository structure, type definitions, test suites, runtime configs, the schema of the analytics tables, the deprecated endpoint that nobody has gotten around to removing. That is hard but tractable. You can crawl a repo. You can index a schema. You can wire a language server. The work is real, but the boundaries are clear.
For non-engineering agents, context is harder and weirder. It means: which Slack channel actually surfaces the real decisions, who has signoff authority on a discount, which CRM fields are reliably maintained and which are write-once-and-forgotten, what counts as a "finished" ticket inside this team versus that team. None of this lives in a markdown file. Most of it lives in people's heads. The organization itself is the context, and the organization cannot describe how it actually works.
This is why the platform that wins is the one that meets the customer where they are. Do not require them to migrate their wiki into your system. Do not require them to restructure their org chart so the agent can understand who reports to whom. Plug into SharePoint, plug into Slack, plug into the CRM as it is. Capture context where it already lives. The moment you require centralization, you have lost — both because the customer will not do it, and because the act of centralization destroys the local knowledge that made the context valuable in the first place.
I've made this point about skills as software: the technical context layer needs versioning, tests, deterministic checks. The organizational context layer needs something stranger — a way to capture tacit knowledge without demanding it be made explicit upfront. Both are continuous iteration problems. Neither is one-and-done. The harness commoditizes. The context never does.
Sources
Related Essays
The Submodule Problem Is the Whole Problem in Miniature
Submodules are a specific pain point, but they illustrate a universal truth. Enterprise codebases are not simple, and agents that cannot handle them cannot handle enterprise software.
Agent Memory Is Unsolved. Workflow-Scoped Learning Is Not
General-purpose agent memory is still a research problem. The opportunity is workflow-scoped learning that compounds — pick the constraint, and the memory problem stops being intractable.
The Codebase Is the Territory. The Agent Needs a Map
Every quarter a new model writes marginally better benchmark code. And every quarter enterprise teams stall on the same context problems. The hard part is the engineering around the AI.
Key takeaways
- Context for engineering agents is technical: repository structure, type definitions, test suites, runtime configs.
- Context for non-engineering agents is organizational: who decides what, which Slack channel matters, what counts as "done" in this team.
- The platform that wins is the one that captures both kinds of context without forcing the customer to centralize their data.
FAQ
What does organizational context look like?
It is the unwritten rules — who approves a discount, which fields in the CRM are actually maintained, what counts as a finished ticket, which Slack channel surfaces the real decisions. Most of this lives in people's heads. None of it lives in a markdown file.
Why is context the hardest unsolved problem?
Compute, sandboxing, and model routing are all tractable engineering problems. Context requires the organization to describe how it actually works — and most organizations cannot. The bottleneck is not the platform; it is the mirror.