# Keeping context with the change, not in a chat log

Updated September 24, 2026.

An agent can leave a clean diff while the context that produced it stays in a chat window. Six weeks later, the next engineer can see what changed but may have to reconstruct why from scratch.

A short record kept with the change can help. It should say what the agent was asked to do, what evidence it used, which checks ran, and why a person accepted the result. Those are different kinds of information: a decision summary is an account, while a test result needs a link to the run that produced it.

Three ways that record can help

1. Onboarding

An engineer reading an unfamiliar change can start with its constraints and review decision instead of searching an old conversation. Whether that saves time depends on the quality of the record and whether it remains easy to find.

2. Reverts

A revert can undo a constraint or restore a bug the original change fixed. The recorded intent and tests give the person reverting it a better starting point for checking those consequences.

3. Evaluation

Merged history can become useful material for evaluating agent workflows: what was requested, what was changed, what was verified, and what happened later. A merge alone is not proof of a good outcome. To learn what worked, connect the change to later tests, deployments, incidents, or other results, and check that the record is complete enough for the question asked.

Start with one question

You do not need a new tool to begin. At review time, write a short answer next to the diff:

What did the agent try, what evidence supports this version, and why did we accept it?

That practice preserves a useful decision record today. Logposa is building ways to connect such records to changes and to verify the evidence they cite. The paper trail post explains why that link matters; the signing post sets out what a cryptographic claim would have to cover.