Coding Agents: Where the Record Should Live

Friday afternoon, say an engineer stops a coding agent mid-ticket and starts another from a bare terminal. The engineer might expect it to pick up where the first one left off. Most likely, it doesn't. It repeats a change that was already rejected.

The reason for the rejection lived in the first session, not in the ticket. The record of what was decided matters more than which agent made the edit, so choose where the record is kept before choosing the agent.

Is git history enough for the next agent?

Git history is good at accepted changes and bad at unfinished reasoning (which includes unfinished concepts). A diff shows what changed. It does not say why three other approaches were dropped.

Take a parser refactor. An agent rewrites the implementation, then finds that a test fixture depends on an undocumented edge case. The engineer stops the run before accepting the patch. Nothing gets committed. History holds nothing. The next agent can read the working tree. The reason for keeping that edge case sits nowhere, so the next agent starts blind. A commit message could carry it. Only if a person writes it first. A generated message deserves the same review as the diff, because it can describe an intent the patch never proves, and a guessed intent in permanent history reads like a confident wrong answer.

History has one real advantage, though: Any agent even in a bare terminal can read it. No setup needed. For a small refactor, a reviewed commit and a note on the ticket may be all the next engineer needs.

The cost runs the other way. Committing every exploratory edit creates cleanup work. Waiting until the end leaves the reasoning outside the record.

Can a pull request hold the handover?

Yes, while the patch is open. After that, no. A dependency update shows it well. The ticket names the package and the checks that must pass, the agent opens a pull request, and reviewers argue about a failed check right beside the lines that caused it.

The limit shows up twice. Before a patch exists, and after one closes. An unresolved requirement can shape several possible implementations, and an answer buried in the thread of a discarded patch makes the next task harder to start. Nobody reopens a closed pull request to check a rule, so the next agent works from a guess.

So keep each decision with its scope. A comment about one implementation belongs beside that implementation. A rule for future tickets belongs in the project's requirements. Copying it out of the review thread feels redundant in the moment. It isn't.

A finished agent run says nothing about the acceptance criteria. Someone has to record that verdict, and it should be a person or a named check. Otherwise the patch looks exactly like an untested one.

Why not keep the decision in the editor session?

Because the session does not transfer. It stays with whoever had it open. Say an agent changes validation across several modules and the engineer rejects a fallback that would hide malformed input. The final patch is fine. Then the session ends with open files and a clean diff. The reasoning stays behind.

The next engineer gets the files and the patch, not the reasoning. A later agent extending the feature may propose the same fallback again. A raw transcript keeps everything. That includes ideas that were later dropped, so the next reader rebuilds the decision from the discussion. A decision that exists only in chat history might as well not exist.

Convenience is the trade-off. Keeping everything in the session saves writing during the work, while recording the outcome takes a pause before switching tasks. People skip that pause once the patch is accepted.

You can test this without a benchmark. End a session mid-task, ask another engineer to resume from the saved records alone, and watch what they cannot recover.

What changes when agents share project state?

A reviewer picks up a branch after two agents touched it. One wrote code against a requirement, the other wrote tests. The session logs show what each agent did, but the reviewer needs to know which requirement the code was meant to satisfy. With a shared project store, that requirement is a record the reviewer opens directly instead of a claim inside a summary.

AuricIDE, an open-source desktop IDE under AGPL v3, is built around this model. Goals, tickets, requirements and test cases are exposed over MCP, so an agent that updates a ticket changes the same entry the reviewer sees in the backlog.

Agents come from your own CLIs, each as its own local process. A crash shows up as an error, so a dead agent never passes for a quiet one. That matters for a handover, because the next step needs to know whether the last one finished.

Chains of skills make the handover concrete. Each step picks its own agent. A step that fails ends the chain. The next step gets its own prompt plus a cleaned tail of the previous step's terminal output, labelled so the receiving agent checks it instead of trusting it. Chains run strictly one step at a time. There are no parallel branches, and each chain belongs to one project. That keeps the handover easy to follow. It also means two agents cannot work the same chain at once. The requirement in the shared store stays the authority. The tail only carries what was last visible on screen. It is a hint. Not a source.

Friday has a close cousin. AuricIDE's agents die when the app closes. On the next start they show up as interrupted, with a Resume button that begins a fresh session and tells the agent to inspect the current state first. Even there, the prompt points back at the records rather than at a memory of the old run.

For an implementation-to-review handover, that changes what gets checked: the reviewer compares the diff against the current requirement and its test cases, the same records the agents used. This is the practical role of agent orchestration: controlling which records and actions each step uses.

What does each record location cost?

A pull request asks the least of you up front, because the platform already supplies the place to talk, but it only helps once there is a patch to review. The record location also changes how the work gets reviewed. The table shows what each choice brings with it.

The shared store costs the most to set up. It has its own limit. AuricIDE keeps project data in a single SQLite file inside the project directory, which git ignores by default. The record stays on the machine by design. A clone does not bring it along. The price of keeping it private.

One caveat about "local". The record stays on the machine, but that says nothing about where the CLI sends its model requests. Treat that as a separate check.

Which record do you pick first?

Start with one question. What is still unresolved, and who may change it? Keep merged truth in git, let pull requests carry review, and put acceptance criteria in shared state only when write permission is explicit. Then pick the agent. A few lines of paperwork cost less than a rejected change made twice.

Visit AuricIDE to review the source, then try an implementation-to-review handover on a non-critical repository.