How do decisions reach every agent that touches the same code?
By Soumen Sarkar · October 2026
Short answer: Decisions reach every agent that touches the same code when they're tied to that part of the code and delivered the first time an agent reads or edits it, before it writes anything, rather than waiting for the agent to think of searching.
Why isn't writing decisions down enough?
Because an agent doesn't know what it doesn't know. A decision in a document only helps if the agent thinks to look for it, picks the right search words, and does so before it starts writing code. Most of the time it won't. It reads the files in front of it and gets to work.
So a written decision is necessary but not sufficient. It also has to arrive.
What makes a decision arrive?
Two things:
- It's tied to a place in the code. "Media · lib/media", not "somewhere in the backend". Then the question "what applies here?" has an exact answer.
- It's delivered at the moment of touch. The first time an agent reads or edits that part of the code, the decisions for it are put in front of it, before it changes anything.
Global rules that apply everywhere belong in the agent instructions file. Decisions about one part of the code belong with that part, so every agent gets the ones that matter to its work and not a hundred that don't.
What does that look like for image uploads?
Say the team decided, a month ago: "Store original images untouched; generate resized versions on request and cache them. Why: we keep changing the sizes the app needs." That decision is tied to Media · lib/media.
Today a developer asks an agent to add avatar thumbnails. The agent's first step reads lib/media/upload.ts. At that moment the decision arrives with the rest of what's known about the area. So instead of resizing on upload and storing a 64-pixel copy, which is the obvious approach, it adds a 64-pixel size to the on-request resizer. One more line in a size list, and the team's call holds without anyone having to repeat it.
How do I keep decisions current?
Decisions go stale. Two habits keep them useful:
- When a call changes, supersede the old one with the new decision and its reason, instead of editing it silently.
- Notice decisions nobody uses. If no one has relied on a decision in months, check it still holds before an agent follows it into a wall.
How does Campfyrr deliver them?
Campfyrr names areas from their folders (renamable) and ties decisions to them. In Claude Code, the first time a session reads or edits a part of the code, it gets an area brief: what's being changed there right now, the decisions made there to follow, what changed this week, approaches tried and dropped, and open assumptions. Recent and still-used decisions come first; one nobody has written to or relied on for four months is shown with "check it still holds".
Agents in Codex or Cursor get the same team record by calling recall or search_memory, following the server's instructions. For where decisions should be written in the first place, see where a team's decisions should live.
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.
- Area brief: An area brief is what a person or agent is told the first time they touch a part of the code: what's changing there now, what was decided, and what was tried.
- 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.
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).