How do I capture decisions my agents make?
By Soumen Sarkar · October 2026
Short answer: Capture your agents' decisions by having them record each call in one sentence, with its reason, at the moment they make it, in a place every other agent searches. A decision written after the fact is usually missing the reason.
Why do agents' decisions get lost?
Because they're made in the middle of the work and live only in the session. An agent picks a date library, chooses to store times in UTC, decides retries stop after three attempts. Each call is reasonable and each one shapes the code. When the session ends, the reason goes with it.
The next agent in that code sees the result but not the why. So it either follows a pattern it doesn't understand, or quietly undoes a call that was made for a good reason.
What counts as a decision worth recording?
Any call another person or agent could reasonably make differently, and would want to follow if they knew:
- choices of approach ("store all times in UTC, convert at display");
- rules for a part of the code ("never call the payments API from the client");
- choices between options that both work ("cancel, don't refund, on trial plans").
Small implementation details don't need recording. If a future agent would make the same call on its own, skip it.
What does a good decision line look like?
One sentence for the call, one for the reason, and where it applies. Say an agent is building recurring meetings in a scheduling feature, in Scheduling · lib/scheduling. Halfway through, it records:
- Decision: store recurring events as a rule plus a timezone, and expand occurrences when they're read.
- Why: storing each occurrence breaks when daylight saving rules change.
- Where: Scheduling · lib/scheduling.
Two weeks later another developer's agent adds reminders to the same feature. It finds that decision before writing anything, expands occurrences the same way, and doesn't create a second, conflicting model of time. The decision line template gives the shape.
How do I get agents to do it?
Put it in their instructions: "When you make a call another engineer could reasonably make differently, record it in one sentence with its reason, before moving on." Then make sure the record is somewhere agents look before they decide. A decision only helps if the next agent finds it.
When a decision changes, record the new one and mark the old one as superseded, rather than deleting it. The history of why is part of the record.
How does Campfyrr capture them?
Agents call log_decision with the call and its reason, in the project and the area it applies to. Each one is checked against the decisions that stand there; if it contradicts one, the newer call stands and the earlier one is marked replaced. Decisions become part of the team record: every agent can find them with search_memory or recall, and in Claude Code they appear in the area brief the first time a session touches that code, recent and still-used ones first. A decision nobody has relied on in four months is shown with "check it still holds".
That's deciding by doing: the call is made in the work, and the sentence that explains it is the record.
Words used here
- Decision: A decision is a call made in the work, recorded with its reason at the moment it is made, so it travels to everyone who touches the same ground.
- Team record: The team record is everything a team has written down that a person or agent can search before asking: decisions, rules, handoffs, assumptions and the reasons behind changes.
- Superseded: Superseded describes a decision or rule that a later one has replaced: it no longer stands, but it is kept with what replaced it and why.
The principle behind this: Decide by doing: Our decisions live in what we do, not in what we say.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).