More context will not fix the accountability problem
An agent can read everything and still follow the wrong decision.
It feels like everybody has figured out that their agents need more than just vibes to produce reasonably decent results. Now we just need to give the agent more context, and our development will be 10x! Sunshine, rainbows, 20M seed rounds, etc. Context overload is usually well-intentioned, and often looks like:
The agent wrote the wrong thing, so somebody hands it a PRD.
The agent missed an edge case, so the docs get expanded. And expanded.
The agent used a pattern the team abandoned last year, so the codebase gets indexed regularly.
The agent didn’t understand what the business was trying to do, so now it reads Slack, combing for clues like Encyclopedia Brown.
Often, the prescription works.. kind of. Adding new paths for retrieval improves the agent’s output, and anyone who has watched an agent operate without it knows just how much things improve. But what that retrieval can’t do is tell the agent which of the things it found is still true. That gap is where the (current) actual problem lives.
Even early-stage companies have a ton of documentation. Maybe not the most helpful or current documentation, but there are pieces of information that could potentially help someone solve a problem. Probably. By the time a feature ships, it’s entirely possible that there are 20 associated documents (I’m using document liberally here) without anyone thinking it unusual. The great news is that your agent can and will read every single word of all 20 docs, even if your people-engineers won’t.
Unfortunately, it’s very rare that those documents will include things like decisions the team made (or decided to punt), whether scope was changed in a meeting nobody wrote up, whether the author had standing/authority/seniority/loudest voice to make the call, or whether the customer changed their requirements two weeks after it was last updated. That kind of information usually lives in someone’s head.
These kinds of retrieval systems are built to answer one question and one question only: what information might be relevant here? The question an engineering or product team lives and dies by is very different. That question is technically two: what are we doing right now, and who decided it? Relevance and currency are separate properties, and having one doesn’t tell you a damn thing about the other.
N+1 documents, one agent
For funsies, let’s say that your agent pulls two specs. The first describes a self-serve onboarding flow, meticulously planned for novice users with a slick UI. The second argues that sales can’t close the enterprise customer in the pipeline until an admin-provisioned flow ships first. Both are well litigated, both have an 11-comments-deep thread underneath with senior people in it, and both were accurate on the day they were written.
But your agent still has to pick one. Coin toss? Alphabetical? Most recent?
At its core, your agent (a vector database) has no basis for picking. A bigger context window means it reads both specs more carefully before it guesses, because your agent isn’t a human who understands nuance and tradeoffs and preferences. What does settle the question is really provenance: who decided, when, under what authority, and whether anyone has since replaced that decision with a different one.
People have this problem too, we just cover for it
Let’s picture a senior engineer siting in a meeting where direction changed (while she is daydreaming of leaving tech to build custom furniture). She carries that update in her head for six months and somehow becomes the place people go when they want to know what’s real. She becomes the single source of truth. Nobody bothers to write it down, because.. well, she’s right there and asking her is faster than searching through Confluence, Jira tickets, Slack threads, Figma mockups, and the secret Miro whiteboards PMs don’t want you to see.
Then one day she leaves tech entirely to pursue her passion of sanding walnut for 6 hours a day and making coffee tables. Or she gets pulled onto something urgent or goes on vacation or gets the plague and stops answering in the channel. Six months of decisions that only ever existed as institutional memory walk out with her, and the company discovers it had a memory problem wearing a process problem’s clothes. Oops.
but we’re gonna fix it!
At Helen’s Foundry we’ve elevated those decisions as components in a running system rather than potentially stale files in a folder. A decision carries its own state. Anyone reading it can see which work it governs and what discussion produced it. When something replaces it, that replacement is visible from the original, so nobody has to reconstruct the chain through Notion archaeology. It’s literally just a link in the context chain.
The concept of supersession is the part that matters more than it sounds like it should. (Also, it just sounds cool.) Most tooling handles a reversal by letting the old document rot in place. The replacement gets written somewhere else entirely while the original stays searchable and confident and wrong. Eight months later both of them come back in the same retrieval call, and whoever is reading has no way to rank them.
The goal here isn’t more documentation. Frankly, nobody wants that, and asking for it has failed at every company that has ever tried. Besides, the material already exists! It’s sitting in tickets and in specs that were finished enough to ship and then never touched again. The work we have to do now is making those artifacts stop contradicting each other, and giving whoever reads them next a way to tell which one won.
The engineer who joined last month has the same problem as the agent. Both will find the March spec, find it coherent, and start building against something the company quietly stopped believing in April. More context just gets both of them there faster.