Can you retrofit context for AI agents?

THE SHORT ANSWER

No. Every other layer in an agent stack can be added after the fact, because every other layer is a read of something that already exists. A control plane reads systems you already own, model routing is a config change, governance can be wrapped around agents that are already running. Context is different: the reason a decision was made exists only at the moment someone makes it, and only that person can record it. Logs give you what happened, schemas give you how, and neither reconstructs why. If it wasn't written down then, it is not recoverable, which makes where your team records reasoning a decision you are making this quarter rather than at renewal.

The one-line version: everything in an agent stack can be bolted on later except the record of why.

The asymmetry

Sort the layers of an agent platform by when they have to be captured, and they fall into two piles.

The big pile is everything that is a read of something already sitting in your systems. A control plane reads your catalog, your identity provider, and your job history. Model routing is a config change, reversible in an afternoon. Cost metering reads usage records that are already being written. Governance can be layered on top of agents that are already running, clumsily, but it can be. None of these need to have existed a year ago for you to have them next quarter.

The small pile has one thing in it. The reasoning behind a decision exists for a few minutes, in one person's head, at the moment they make it. Nothing writes it down automatically. No system generates it as a side effect. And once the person who made it has moved teams or rolled off the contract, it is not recoverable from anything you own.

That asymmetry is the whole answer. Most platform capabilities have a retrofit path. Intent has none.

What your stack actually holds

Your data catalog holds the what. Twenty years of validation rules, flows, and custom code hold the how, in the sense that they encode the mechanics exactly.

Neither holds the why. Why discount approval routes through finance in one region and not another. Why the last three architects killed the same proposed integration. Why one validation rule exists and which edge case it was written to catch.

An agent that inherits the what and the how without the why executes the rule perfectly, right up to the moment the rule shouldn't apply. And it has no way to know it has crossed that line, because the condition that would have told it was never written anywhere.

The four fields worth capturing

I run this in Heidi and it is deliberately small, because a capture format nobody fills in is worth nothing.

The decision, in a sentence. The options that were rejected. The reason, meaning the thing that would sound obvious in the room and cryptic in a year. And the reversal condition: what would have to be true for this to be the wrong call.

The reversal condition is the field teams skip and the field agents use most. It converts a static rule into a rule with a boundary. Without it, an agent has a policy. With it, an agent has a policy and a reason to escalate.

What this changes about vendor timing

Nothing, on the buying side. If a control plane ships in 2027 and you need one, buy it then, and you will have lost nothing by waiting, because it reads systems that are not going anywhere.

The capture decision is on a different clock. Every week you don't record reasoning is a week of reasoning you will not have when the agents arrive to use it. Decouple the two. Pick one recurring decision this week and write down why, somewhere with a subject line an agent can key on.

SOURCES

THE LONG VERSION

RELATED ANSWERS

Last reviewed 2026-09-14 · 3 min read