Supersession
When a team changes its mind, the old decision should explain the system without controlling the next one.
A team decides in March that enterprise exports should be CSV-only. It is a clean decision at the time: simple format, low surface area, fewer permissions questions. The reasoning gets captured, linked to the export work, and everyone moves on.
In June, the same team changes its mind. Three customers need board-ready reports, the security review is done, and the product call is now scoped PDF export for admins only. That decision gets captured too.
An agent picks up a task in August: "Add export support to the reporting page." It finds the March decision and follows it perfectly. No PDF. CSV only. The implementation is coherent, tested, and wrong.
The failure was not missing context. The failure was stale context with confidence.
A decision is not permanent
Product decisions are usually written as if they are facts. "Exports are CSV-only." "Slack is the first notification channel." "Admins own billing." "Mobile is read-only for now."
But most of these are not eternal truths. They are commitments made under conditions: what customers needed then, what the team could support then, what the business was prioritizing then, what risks had not yet been resolved.
When those conditions change, the decision may change too. The old one does not become embarrassing or useless. It becomes history. It explains why the system looks the way it does, but it no longer governs what should happen next.
That distinction matters more for agents than it ever did for people. A person who was around for the June discussion may remember that March was overruled. An agent reading retrieved context has no such memory. It only has records. If the records do not say which one replaced which, the agent has to guess.
And if the old decision is clearer, closer to the code, or easier to retrieve, the agent may choose the wrong one for exactly the reason you trained it to: it found a decision and respected it.
Stale context is worse than missing context
Missing context makes an agent uncertain. Stale context makes it certain in the wrong direction.
That is the dangerous part. When the agent has no decision, it may ask, hedge, or follow the local code. You can often spot the gap in review. But when it has an old decision, the work looks disciplined. It can point to the rule it followed. The mistake wears the shape of compliance.
This is why "give the agent more context" is not enough. More context increases the chance that the old decision is somewhere in the pile. It does not tell the agent whether that decision still applies.
A context window full of unranked historical truth is not a product context layer. It is an archive. Archives are useful, but they do not govern action. To govern action, a system has to know which record is current, which record was replaced, and why the replacement happened.
Search alone cannot solve this
Search is very good at finding relevant records. Supersession is not the same problem.
If a team has two decisions about exports, both are relevant. The March CSV-only decision is relevant because it explains the current implementation. The June scoped-PDF decision is relevant because it governs the next implementation. A search system can return both and call the job done.
But the hard question is not "which records mention exports?" It is "which decision controls the work now?"
That is a relationship question. The June decision supersedes the March decision. It does not merely share keywords with it. It changes the status of the earlier record.
A timestamp alone is not enough either. Newer does not always mean authoritative. A Slack comment from yesterday should not overrule a reviewed decision from last month just because it is fresher. Supersession needs provenance, scope, and intent. Who made the new call? What does it replace? Does it replace the whole decision or only one condition? Is the old decision retired, narrowed, or still active in another context?
Without that structure, the agent is left with a pile of plausible records and a sorting problem disguised as judgment.
Supersession is how context stays alive
The moment a decision is captured, it starts aging.
Some decisions stay true for years. Some expire when a launch happens. Some are temporary until a risk is resolved. Some get narrowed when enterprise customers need different behavior from self-serve users. Some get reversed because the first call was wrong.
A living product context system has to handle all of those cases. Not by deleting the old decision, because the old decision still explains the system. Not by hiding it, because future work may need the history. And not by dumping both into retrieval and hoping the agent can infer governance from prose.
It needs supersession: an explicit link saying this record replaced that record, for this scope, for this reason.
That link is what lets old reasoning remain useful without remaining active. It lets the agent understand why the code was built one way and why the next change should move it another way. It preserves history without letting history masquerade as the current plan.
This is where product context becomes infrastructure
A document can hold a decision. A search index can retrieve it. A memory file can remind an agent it exists.
But none of those, by themselves, keep the decision current.
That is the infrastructure problem Brief is built around. Product context is not just the accumulation of decisions. It is the maintained state of those decisions: what they govern, what they depend on, what replaced them, and who needs to know when they change.
Entity resolution answers one question: are these two records about the same real thing?
Supersession answers the next one: if they are, which one governs now?
Without the first, the system cannot tell that "CSV-only exports" and "scoped PDF reports" are part of the same product thread. Without the second, it can tell they are related but not which one should guide the next builder.
That is the difference between context as storage and context as navigation. Storage says, "Here are the records." Navigation says, "This is the one that controls your work."
The agent should not have to be a historian
An agent asked to build should not have to reconstruct your company's decision history from scratch. That is not good autonomy. It is delegated archaeology.
The agent's job is to apply the current decision well. The context system's job is to know what current means.
So the test is simple. When your team changes its mind, does the old decision become safely historical? Or does it remain in the same pile as the new one, waiting for the next agent to retrieve it and obey it?
If both records are findable but only one is current, your system has not solved product context yet. It has only made the contradiction easier to discover after it has already done damage.
A decision record matters because someone will build against it later. Supersession is what makes sure they build against the one you still mean.
Frequently asked questions
What is supersession? Supersession is the relationship between an older decision and a newer decision that replaces, narrows, or overrules it. It preserves the old decision as history while marking that it no longer governs the same work.
Why do AI agents need supersession? Agents are asked to retrieve and follow context, and an old decision can look just as authoritative as a current one. If it is still visible but not marked as replaced, an agent can follow it perfectly and ship the wrong thing. Supersession tells the agent which decision is current.
Why not just use the newest decision? Newest is not the same as authoritative. A casual comment from yesterday should not automatically overrule a reviewed decision from last month. Supersession needs an explicit relationship, scope, and provenance.
How is this different from deleting stale docs? Deleting the old decision loses the history that explains why the system was built that way. Supersession keeps the history but prevents it from governing future work.
What does Brief do here? Brief keeps decisions connected to the product objects they govern and tracks when one decision replaces another. That lets engineers and agents see both the historical reasoning and the current rule, without guessing which one still applies.
← Back to Blog