An agent handed me a finished piece of positioning last month, and it was wrong. Not broken-wrong, confident-wrong. It read clean, it was freshly stamped, nothing errored, and it stated our position on a product line as though it were settled brand truth.

Except that position had been an experiment. We'd tried it on a net-new product, decided against making it canonical, and moved on, and the experiment had leaked into the layer the agent reads as gospel. The machine was repeating the experiment back to me in the voice of the brand, and I almost shipped it.

Your AI agents are only as good as the content they run against. Point a good agent at stale content and it produces confident, well-formatted, wrong output, because it has no way to know the content is stale. It trusts what it reads.

That is the whole point of building a context layer in the first place, that the agent stops re-asking and starts trusting, and it is also the exposure. A stale doc doesn't announce itself. It reads exactly like a fresh one.

This piece is about the four specific ways that content goes stale, how to spot each one in your own layer, and how to build canonical sources of truth, the documents your agents run against, so they stay current instead of feeding your agents last quarter's answer with a straight face.

Stale content is worse than no content

Here is the part most people have backwards. An empty slot is safe. When the layer has no answer, the agent asks you, or it says it doesn't know, and that's a failure you can see and fix in the moment.

When the layer has a stale answer, the agent acts instead of asking. It drafts, it briefs, it scores, and it does all of it against a truth that expired weeks ago, at speed, without flagging a thing. Same missing information, opposite risk. The failure you can't see is the one that already went out the door.

And a layer left alone does not sit still. It rots, and that isn't an edge case, it's the default state of any system people keep contributing to. I learned this the slow way years before any of this was AI, cleaning CRM data for a living.

Over time data quality will start to deteriorate in any system where you have users contributing a sizeable amount of data, no matter how well enforced your rules are. There is no operations system that is truly set-it-and-forget-it, and a context layer is the same organism with more inputs moving faster.

Leave it alone and it drifts toward what most company knowledge bases already are, graveyards, digital junk drawers where information goes to die. The AI era just raised the stakes on that old problem, because now a machine reads the graveyard and acts on what it finds.

So the useful question isn't whether your content will go stale. It will. The question is whether you can name the ways it goes stale well enough to go find them in your own layer this week.

The four ways content goes stale

There are four, and the thing they share is what makes them dangerous: in all four the document stays authoritative while the content underneath goes wrong. Three of the four are invisible to any link-check or health-score audit, because structurally there's nothing wrong with the file. "My audit is green" is false comfort for exactly this reason.

One: a reversed decision that never got un-written. You made a call, wrote it into a canonical doc, and the agent started acting on it. Then you reversed the call, in a meeting, in a Slack thread, in your own head, and you never went back to change the doc. Say you cut a segment from your ICP on a Monday. The "current ICP" doc still lists it Tuesday, because the reversal lives in your head and the meeting notes, not in the canonical doc. The agent reads the doc, scores accounts against the segment you just dropped, and drafts outbound to a buyer you've decided to walk away from. The tell: the doc still matches what you used to believe. You made the call in a meeting, and the meeting ended, and nothing in the doc changed.

Two: two truths both survive. This is the one that handed me that positioning output. You wrote down the new call, but nobody killed the old one, so both stay live and both read authoritative. In my case the two truths were the experimental positioning for a net-new product line and the canonical brand positioning, and the experiment was never walled off from the canonical layer. Nobody had demoted the loser, because from the layer's point of view there was no loser, both docs were live and both looked settled. So the agent did what agents do with contradictory sources, it gave back a frankensteined answer, pulling the experiment through as if it were brand truth. Way one is a missing write, you never recorded the reversal. Way two is a missing delete, you recorded both and never demoted either. The tell: two docs make contradictory claims about the same thing, and both are freshly stamped, so no timestamp tells them apart.

Three: drift. The synthesis was accurate the day you wrote it. Then the detail underneath kept moving, new calls, new deals, new decisions, and the summary silently fell behind while still reading authoritative. Your "current ICP" doc pulled the pattern out of fourteen calls in Q1 and was true.

Two quarters and forty calls later the pattern has shifted, and the doc hasn't. The agent still trusts the summary, never checks the forty calls it drifted from, and briefs your new AE on a buyer profile that stopped being accurate a quarter ago. Nobody changed their mind here, and nothing contradicts. The tell is different from the first two: the doc still matches what you decided, it just no longer matches what's true now.

Four: bloat. This one is different in kind. Nothing in it is a lie. Your capture loop is working, everything flows in, and nothing gets promoted or pruned, so the layer fills with raw, half-relevant material until the agent is reading eleven files and burning 35k tokens to answer what one good synthesis should have answered in a single hop. The true doc is in there. It's just buried, and the agent can't tell the signal from the eleven near-misses around it. This is staleness by accumulation rather than by a single wrong doc, and it's the one people cause by capturing more and calling it progress. (Capture mechanics are the subject of the sibling piece; here bloat shows up only as the symptom a canonical doc fixes.)

Notice where those four land relative to your tooling. A weekly audit catches broken links and orphaned files, the structural half, and that's worth doing. But it cannot catch a doc that is structurally perfect and factually reversed. The audit answers "is this file well-formed." It has no way to answer "is this claim still true," and it's that second question the rest of this comes down to.

Build a canonical source of truth your agents run against

The fix for all four is the same object: a canonical source of truth, the single settled doc the agent runs against for a given question, structured so a human can keep it current. There's a companion piece on the anatomy of that doc, how to build one from what you already have, the frontmatter, the answer-on-top structure, the provenance tags, so I won't re-teach it here. What matters for staleness is a smaller thing: the handful of features that make a canonical doc de-stale-able, and how each one maps to a way content rots.

An owner, named, on the hook. Not "the team," not "the agent," a person. The owner is who un-writes the reversal when you change your mind, so way one has somewhere to land. A doc with no owner is a doc nobody updates, and the reversal you made in the meeting never makes it into the file.

A last-reviewed date, separate from last-updated. Last-updated tells you when the doc last changed. Last-reviewed tells you when a human last looked at it and confirmed it still holds, which is the thing that catches drift. A doc last touched in Q1 and never re-reviewed is exactly the drifted synthesis from way three, and the two dates make that visible at a glance.

Provenance tags that can carry a status. When every claim in the doc says where it came from and how much to trust it, a claim that's gone dead can be marked, flagged [STALE] rather than silently believed. That's the seam where a human, or an agent proposing candidates, can say "this line no longer holds" without deleting the doc.

A curation loop that demotes the loser. When a new truth lands, or an experiment should never have gone canonical, someone actively kills or quarantines the old one, archives it out of the agent's read path or walls it off so it can't be pulled as canonical again. That's the fix for way two, and it's the reverse of the move everyone's comfortable with. Adding is easy. Taking something out of the layer is the part almost nobody does, and it's the part that keeps two truths from both surviving.

A context layer is the record the company runs on. When a reversed decision stays un-written, every agent that reads the doc keeps asserting a position the company already walked away from. Demote the doc: name the owner, set the review date, kill the loser.

Keeping it current

None of the four repairs itself. The canonical doc gives you a place to make the fix, but a human still owns the call, because deciding what's still true is the one thing you can't hand to the machine that reads the layer. What you can hand to the machine is the flagging. The agent watches the work and proposes candidates, this doc's sources moved, these two docs contradict, and you make the kill call.

I'll be honest about where my own tooling actually is, because the gap is the useful part. I run a knowledge graph over my repo, and today its staleness check computes absolute age, flagging docs older than a threshold. That's the hygiene signal, the same thing a weekly audit does, and on its own it's mostly noise, because plenty of old docs are still perfectly true.

The check that actually catches drift is one the graph doesn't compute for me yet, so I run it by hand: not "how old is this doc" but "is this doc older than the reality it describes." A synthesis is suspect the moment a source it depends on changed after the synthesis was last touched. The raw material is right there, the reverse links tell me which sources a doc depends on and the changelog tells me when each one last moved, but I'm the one who runs the comparison.

So the move you could run Monday, by hand, on your own files: which of your synthesis docs summarize sources that changed after the synthesis did? That list is your drift. Two-truths won't show up on that list, because both docs are freshly stamped and a timestamp waves them both through, so that one still needs a human eye on the docs that make claims about the same thing.

Age on its own is mostly noise, since plenty of old docs are still true. The check worth running is age relative to the source, and my tooling doesn't run it for me, so I'm the one who runs the comparison.

Set a review cadence against that. Not a full re-read of everything, a scheduled pass over the handful of canonical docs your agents run against most, checking the last-reviewed date and the drift list. That's the whole discipline. The graph surfaces candidates, you decide.

Start with one doc

Your agents run on your content, and your content is going stale right now in these four ways whether or not you're watching for them. So watch for them. Take one canonical doc that answers a question your org actually runs on, your ICP, your pricing logic, your top objection, and read it against the four.

Is there a call in it you've already reversed and never un-wrote? A second live doc that contradicts it? A summary that fell behind the calls underneath? Eleven half-relevant files where one clean synthesis should be?

Then fix that one. Give it an owner, a last-reviewed date, provenance you can trace, and set the cadence that keeps it current. Do it for the doc your agents lean on hardest, the one whose staleness would cost you the most, and do the next one next week. That's the pace at which anyone actually keeps a layer current.

Related reading: How to Build a Context Layer From What You Already Have covers the canonical doc structure that makes each of these fixes possible. Three Mechanisms That Keep a Context Layer Self-Healing is about what keeps the layer fed and corrected once it exists.

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.