I wrote the doc. That was the part I was proud of.
It was a positioning doc, a good one, with the logic and the exceptions and the two accounts where we'd broken the rule on purpose. I wrote it on a Tuesday, felt the small satisfaction of having finally written the thing down, and closed the laptop. For about three weeks it was the best answer we had to "how do we compare to them."
Then I opened it again and the last-edit date was three weeks old, and the world had moved. A competitor had changed their pricing. We'd added a rebuttal in a call that never made it back into the doc. The document was still sitting there, clean and confident and wrong, because nothing had touched it since the afternoon I felt good about writing it.
The frustration wasn't that I hadn't documented. I had, a good version, with the logic and the exceptions. The frustration was that writing it down once was never going to be enough, and nobody had told me that. The thing the doc described kept moving.
Write the doc. Then build the thing that keeps it true after you stop looking at it, because the doc alone never will.
The starting doc is step zero, and it decays
Start with the doc — a written canonical source of truth, the ICP, the pricing logic, the positioning claims you repeat in every deal. That's the necessary first move, and skipping it is the more common mistake; most operators never write anything down at all. The context lives in their head and dies when they get busy, and if that's you, write the five things you re-explain to the AI most often — that list is your starting layer.
What one of those docs actually looks like, the owner field, the answer on top, the claims you can trace, is its own build; How to Build a Context Layer From What You Already Have walks the anatomy. Build that doc first. Everything below assumes it exists.
But a written doc left alone rots, and it rots for a reason that has nothing to do with your discipline. The doc is static and the world isn't. Your pricing changes, your best objection rebuttal gets discovered on a Thursday call, a competitor ships something new. The doc knows none of it, because a doc has no way to know anything and just holds whatever you last typed into it.
For a long time I treated that as a willpower problem. Set a cadence, block time, be more rigorous. I followed all of it and the docs still went stale, because the fix I was reaching for, "try harder to keep it updated," is a separate job, and a separate job always loses to the real one on a Friday afternoon.
Mechanism one: the work already produces the updates
Stop asking "when will I update the doc?" Start asking "what is the work already producing that I'm throwing away?"
In a GTM org the answer is almost everything. Look at an ordinary week and count the artifacts you generate and then discard: a discovery call happens, and Gong or Fireflies already recorded it, and the transcript sits unread forever. You send an agent to read three competitors' pricing pages before a deal, and it hands back a synthesis you skim once and lose in a chat window. You enrich an account, pulling firmographics and recent news and the buying committee, and that output evaporates the moment the call ends, so the work already happened but you keep none of it.
The move is to route those artifacts into the layer as a byproduct instead of writing docs from memory later. The call gets recorded regardless, so have an agent watch it and emit a structured synthesis: the pains named, the objections logged, the competitor mentions pulled out. The competitor read got done regardless, so keep the write-up as a durable asset, and the enrichment ran regardless, so save it as reusable context for the next person who touches the account. None of that is a new task, and it's the same work with the output kept instead of dropped.
Two mechanisms carry most of this in my own setup, and both have the same shape: I do the work, and the artifact falls out of it. The first is a hook that logs every file touch, the path and the action, to a running changelog, and it doubles as an audit trail of what the agents did versus what I asked, so I've caught agents silently skipping files that way. The second is a recurrence detector: when the system notices I've run the same manual workflow around three times, it drafts a small capturing skill and surfaces it for my review. In both, the record is a side effect of doing the job, not a second job stacked on top of it.
Set this half broad and cheap. You don't yet know which artifact will end up mattering, so let the raw layer be a pile of rough material: call transcripts, enrichment dumps, agent syntheses that may never get read directly. When an agent does the capturing, the cost of over-capturing is close to zero, because the cost of hand-writing every artifact from memory is what killed my last three attempts at keeping a knowledge base current. (A static pile of old decks is a different job, a one-time extraction with its own recipe, which I walked through in 47 Presentations, One Knowledge Base; the mechanism here is the ongoing stream, the artifacts today's work throws off.)
Capture keeps the layer fed. It doesn't keep the layer right, because a fresh pile of artifacts can be freshly wrong.
Mechanism two: the corrections flow back into the source
You wrote the doc so your agents would run against it. An agent drafts an objection rebuttal off your positioning doc, an outbound email off your ICP doc, a battlecard off your competitive synthesis. And sometimes what it produces is off, because the doc it pulled from was slightly wrong, or stale, or missing the exception you never wrote down. You catch it because you read the output before it goes out, but most people stop there: they fix the one email and move on.
That's the leak. You fixed the output and left the source wrong, so the next draft off that doc makes the same mistake, and you catch it again, and you fix it again, forever. The correction never reaches the thing that caused it.
The mechanism is to route the correction back into the source doc, not just the output. Agent produces something off, you catch it, and instead of only fixing the email you fix the line in the doc that led the agent astray. Now the agent doesn't repeat the mistake, because the thing it reads from is truer than it was an hour ago. The loop runs: agent drafts, human catches, source gets corrected, next draft is better, and the corrections accumulate.
An agent drafts a build-versus-buy rebuttal and leans on a pricing claim that was true last quarter. You read it, notice the number is stale, and you have two options: fix the sentence in the draft, or fix the number in the pricing doc. Only the second one compounds. Fix the draft and you'll re-catch the same stale number next week when a different agent pulls the same doc, but fix the doc and the whole layer just got one claim more current, for every agent and every teammate who reads it after you.
This is why a layer you can actually read matters so much, and it's the through-line to the anchor piece: you can only route a correction back to the source if you can open the source, find the wrong claim, and trace where it came from. A black box you feed a model and hope about has no correction path. You'd catch the bad output and have nowhere to put the fix. The whole feedback loop depends on the doc being something a human can read, check, and edit.
Do not confuse this with letting the agent edit the source itself. The agent surfaces the problem; you make the change. The human stays in the loop on what the canonical doc says, because the agent that got it wrong is not the agent you want silently rewriting the truth. The correction is a human act, and the agent's job is to keep giving you output honest enough that you can see when it's off.
Mechanism three: agents that watch for rot
Capture and correction both run while you're using the layer, but rot runs while you're not looking at it. Docs go stale in the background, between the moments you happen to open them, because the pricing page a doc depends on changes and the doc doesn't know. Two synthesis docs drift into contradicting each other, and nobody notices until an agent cites the wrong one in front of a customer. A claim you marked as a hypothesis six months ago is still sitting there, treated as fact by every agent that reads it, because no one went back to promote or kill it, and this is the rot that willpower can't catch because you can't watch a growing library of docs by hand.
Agents can. Point an agent at the layer and give it the maintenance job the humans keep dropping: flag docs whose upstream sources moved, surface contradictions between docs that are supposed to agree, and propose a specific update ("your pricing doc says $X, the live page now says $Y, here's a suggested edit"), then hold it for your approval. The agent does the watching, which is tireless and cheap, and you make the call, which is the part that has to stay human.
You own the truth. The agent never silently promotes, edits, or retires a canonical doc; it expands your peripheral vision, watching more docs than you ever could, and then it hands the judgment back to you. I run agents as an evaluation layer, not an editorial one, so I trust them to flag but not to decide, and the human signal stays dominant by design rather than by luck. The worked version of that split is in Scaling Curation With Agents.
The full failure catalog, the four distinct ways a layer rots and how to spot each one, is in The Four Ways Your AI's Content Goes Stale.
Who does what
The work feeds the layer, throwing off artifacts as a byproduct of calls and reads and enrichments you were doing anyway. The feedback loop corrects the layer, routing every caught mistake back into the source doc instead of just the output. The agents keep the layer fresh, watching for stale sources and contradictions in the background and proposing fixes.
None of them is a separate chore you have to remember. The capture rides work you're already doing, and the correction rides output you're already reading. The watching is handed to agents that don't get tired. The only expensive, human, unautomatable part is the judgment call at the center of each mechanism, and that judgment was always going to be yours, because deciding what's true about your market is the actual job, not a chore attached to it.
Start with what you already have
You are not starting from zero on any of the three.
Mechanism one is already running, half-built, because you already produce the artifacts: the calls, the reads, the enrichments. The only change is to stop discarding the output: point an agent at the recording, keep the competitor synthesis, save the enrichment. Mechanism two is a habit more than a build: the next time an agent hands you something off, fix the source doc, not just the draft, and watch how much less you re-catch the same mistake. Mechanism three: give an agent the standing job of flagging docs whose sources moved and holding proposed updates for your sign-off.
The work already produces the updates. The corrections already pass through your hands. The watching is the one job you were right to hand to a machine.
Related reading: How to Build a Context Layer From What You Already Have covers the anatomy of the canonical doc these mechanisms run against. The Four Ways Your AI's Content Goes Stale maps the decay vectors these mechanisms are designed to prevent.
Victor Sowers builds AI-native GTM systems at STEEPWORKS. 15 years scaling B2B SaaS, two exits, and 2.5 years of production AI-in-GTM.
