What did the agent know before it acted?

Two Records, not One

When an agent acts, it produces two kinds of record. The first is the output record: what it did, what it said, what it recommended or produced. This record usually exists. Logs, audit trails, conversation histories — the mechanics of capturing what an agent produced are well understood and widely implemented.

The second is the input record: what the agent was working from before it acted. The context window it started with. The knowledge it drew on. The constraints it was operating under. The goals it was given. This record often doesn't exist — not because nobody thought to create it, but because most agent architectures don't treat the input state as something worth preserving in a queryable, retrievable form.

The asymmetry matters enormously when accountability is the question. Explaining what an agent did is a forensics problem if the input record is missing. You reconstruct the probable context from fragments — prompt files, retrieval logs, configuration histories, whatever the framework happened to capture — and produce an approximate account of what the agent was likely working from. That account is plausible. It is not the same as the record that existed before the agent acted.

Why the Input Record is Usually Missing

It is not obvious, at the point of building an agent system, that the input record needs to be treated as a first-class artefact. The natural focus is on output quality — does the agent produce good results? Retrieval infrastructure is instrumented for relevance. Prompt engineering is iterated for performance. The context window is optimised for the current task.

What the context window contained at the moment the agent acted, preserved in a form that can be retrieved and examined later — that is a governance requirement, not a performance requirement. And governance requirements tend to arrive after the architecture is already in place.

The result is that organisations discover they don't have the input record at the moment they most need it: when a decision is being questioned, when an incident is being investigated, when a board or a regulator is asking a question that can only be answered by the record of what the agent was given.

Retrieve, not Reconstruct

The practical distinction is between retrieval and reconstruction.

Retrieval is possible when the input record was created before the agent acted, preserved as a coherent artefact, and stored somewhere it can be found. The question "what did the agent know?" gets a direct answer: here is what it was given.

Reconstruction is what happens when that record doesn't exist. Fragments are assembled from wherever they can be found. The system prompt is recovered from version control. The retrieval results are inferred from the log of queries and the state of the corpus at the time. Configuration files from the relevant deployment are located. The resulting account is the best available approximation — and it is visibly an approximation, which matters when the account is being offered to someone who is already sceptical.

The difference between these two situations is determined entirely by decisions made before the agent acted. Either the input state was treated as something worth preserving, or it wasn't. Once the agent has acted, the record either exists or it doesn't.

What This Question Connects to

"What did the agent know before it acted?" is a B-cluster question — it lives in the territory of memory, context, and authored knowledge. But it doesn't stay there.

The same question is the entry point for AI governance, agent accountability, and the board-level conversations that organisations are already having about what their agents did and why. When the answer to the knowledge question is retrievable, those conversations are manageable. When it requires reconstruction, they are not.

That territory — who is accountable, what record a board or regulator actually needs, and what governance looks like before an agent acts rather than after — is covered in the resources on AI governance and accountability.