The reason a person doing the same task does not fail this way is that the person is the integration layer. They know the wiki page is stale and the real answer lives in a chat thread from March. That judgment never got written down, so the agent never had it.
I hit this in my own environment. As my tooling grew, chat workspaces, coding agents, an agent runtime, a notes vault, multiple repos, I had become the implicit integration layer for all of it. I recorded that as the founding entry in my architecture decision log, along with the risks it created: duplicated work, unclear ownership, stale context, lost decisions. The fix was not another agent.
What structuring context actually means
Four decisions did most of the work. Each one is boring on its own. Together they are the difference between agents I can trust and agents I have to babysit.
One authoritative home per kind of information. Durable decisions live in the decision log. Code and versioned technical docs live in Git. Agent execution records, task status, activity, cost, live in a separate execution-layer system of record. When I found the same reference table maintained in two documents, I deleted one and replaced it with a link. Now neither an agent nor a future version of me has to guess which copy is current.
That rule got tested when three analysis notes looked like they had bad citations. A review lane checked the vault history first and found, "The notes were right and were retroactively falsified by the clipper overwriting the file." The honest root cause belongs in the story too: the notes were falsified by a setting in my own capture tool. The practical fix was context architecture, not a better agent. Restore what the notes originally pointed at, then make the durable rule explicit: a clipped note's only stable identifier is the post id in its source URL. The filename never was one, and treating it as one is what broke the citations.
Rules bind to roles, not tools. My governance charters describe roles, strategist, implementer, reviewer, orchestrator, archive, runtime, and a single mapping table says which product currently fills each role. The AI tool market churns quarterly. When rules were written against vendor names, every tool change meant edits across multiple documents; now a swap is a one-row update. The context survives the tools.
Write rules that prevent conflicts instead of resolving them. Agents create new files only, one file per run record or report. Shared living documents have a single writer: me. Every piece of agent work carries a task ID and a cost record, and material output passes a review gate before it counts. Sync conflicts and invisible work are prevented structurally, not cleaned up afterward.
A materiality threshold. Full governance applies only to work that touches code, clients, money, or public content, or that produces artifacts expected to survive thirty days. Everything else stays informal. A structure you cannot sustain is worse than none, because you will trust it while it rots.
I also learned this the expensive way. Early on I built a roster of more than thirty specialized agents. Operating them showed that most added bloat, not value, and I consolidated to a working core of six. The agents were never the leverage. The structure underneath them was.
What to do first, before buying agents
If you are evaluating agents for your organization, the sequence matters more than the vendor.
First, inventory where knowledge actually lives, including the chat threads and inboxes nobody counts as systems. Second, name one authoritative source per kind of information and demote everything else to a pointer. Third, decide who and what may write where, and where human review happens. Fourth, set a materiality threshold so the structure covers what is consequential and ignores the rest.
Then run one small pilot against that structure and judge it on evidence. If the pilot still disappoints, at least you will know the problem is the automation, and not the filing system it inherited.