Decide by doing: our decisions live in what we do
By Soumen Sarkar · October 2026
Our decisions live in what we do, not in what we say.
What does "decide by doing" mean?
Decide by doing means decisions are made in the work, at the moment they come up, by the person or agent whose call it is, with the reason said plainly in a sentence. That sentence, recorded right then, is the decision. From there it travels with the work to everyone it touches.
It doesn't mean deciding without a reason, or without a record. It means the record and the reason are made where the decision is made, instead of somewhere else, later.
Why does it matter at agent pace?
Because agents make decisions constantly, whether anyone names them or not. In one session an agent might settle how many times to retry a failed payment, whether timestamps are stored in UTC, and what shape an error takes. Each of those is a decision. Unrecorded, the next agent makes it again, and may well make it differently.
At a pace of dozens of changes a day, two agents can decide opposite things in parallel and find out only when their work collides. A meeting can't catch that; by the time it's scheduled, a hundred more changes have landed. A document written afterwards arrives late and usually without the reason, which is the part that mattered.
There's a quieter cost as well. An agent doesn't carry memory from one session to the next. Whatever it understood about why the code is the way it is ends when the session ends, unless that understanding was written down where the next session will find it. A team of people can lean on what everyone half remembers. A team of people and agents can't.
So the only place a decision can keep up with the work is inside it.
What does it look like in a working day?
Here's a scenario. On the same morning, two people on one team are each running agents in different parts of the product.
Lena's agent is reworking notifications, in the area "Notifications · lib/notify". It needs to send times to the mobile app, and makes a call: every time sent to a client is a UTC string, because the app formats times for each person's own clock. It records that decision, with its reason, as it makes it.
An hour later, Dev's agent is building a reports endpoint in "Reports · lib/reports". It's about to return dates in the account's local time zone, and records that as a decision too: "Return dates in the account's time zone, because accountants read them directly."
The second decision is checked against the ones that stand, and the clash is caught at once: Dev's newer call stands, Lena's is marked replaced, and the change shows in the feed. Dev sees it within minutes. Reading Lena's reason, he realises both are right for different readers. He puts Lena's decision back for anything the API sends, and his agent makes a narrower call in place of his own: the API returns UTC, and the downloadable spreadsheet, which a person reads, shows local time. That call is recorded with its reason as well.
The fix is two files, because it was caught an hour in rather than a week in. And the next agent to touch Reports, maybe next month, is told both decisions before it writes a line.
Notice what didn't happen. Nobody called a meeting about time zones. Nobody wrote a design document after the fact. Neither Lena nor Dev had to know the other was working nearby. The decisions were made where the work was, the reasons were said at the time, and the clash surfaced on its own while it was still cheap.
What do people do?
You make the call in the work and say why in a sentence. That sentence is the record. "Retry payments three times, because the provider rate-limits after that" is enough. The decision line template has the shape.
When you change your mind, you say so. A new decision that overrides an old one names the one it supersedes, so nobody follows a call that no longer stands. And when you find a clash, you settle it in the work too: read both reasons, keep the one that holds, and record why.
What do agents do?
An agent records every call it makes, with its reason, at the moment it makes it. Not the trivial ones, such as a variable name, but any call another agent might otherwise make differently: data formats, limits, error handling, what a public interface promises.
Before it decides, it checks what's already been decided in the area it's working in, and follows it. If it means to go against a standing decision, it says so out loud, with a reason, instead of quietly doing something else. That's how two agents deciding opposite things becomes a small, early fix instead of a late surprise.
Isn't this deciding without discussion?
No. The reason is spoken plainly, so anyone can read it and disagree, and a recorded decision is much easier to challenge than one buried in a diff. Deciding by doing makes disagreement cheaper, not rarer.
It also has honest limits:
- Doing doesn't excuse silence. A call made in code with no sentence of reason isn't a decision anyone can follow. It's a habit the next agent will undo. Decide by doing still records the reason, every time.
- Big calls still deserve conversation. Whether to rebuild billing, or what a product is for, is worth people talking. When they do, the outcome goes into the work and the record the same way, with its reason.
- Some calls carry high stakes. Decisions about money, customer data, access or deleting things should reach the right person straight away. Making them in the work doesn't mean making them unseen.
- Decisions age. A call nobody has relied on in months may no longer hold. Treat old decisions as something to check, not something to obey.
How does Campfyrr make it hold?
Agents record calls with log_decision as they work. Each new decision is checked against the ones that stand, and when one clashes, the newer call stands and the earlier one is marked replaced. The change shows in the project's Activity feed, so whoever sees it can put the earlier call back in a sentence if it was right, and each week Activity counts the clashes caught.
Decisions reach every agent that touches the same ground. In Claude Code, the first time a session reads or edits a part of the code, its area brief lists the decisions made there, to follow. Decisions that are recent or still in use come first; one nobody has written to or relied on for four months is shown with "check it still holds". When work is committed, its reasons include the calls made in it, so a reviewer sees the decisions alongside the change. Over time, the Record tells the story of the project's calls.
Campfyrr doesn't approve or block anything. It lets the newer call stand, makes the change visible the moment it happens, and leaves the last word to people.
What changes when a team works this way?
The same question stops being decided three times. Clashes are caught in the hour they happen, while the fix is small. New people and new agents learn the team's calls from the work they touch, with the reasons attached.
Decide by doing is how a team's values become visible. They aren't what it says. They're what it ships, and why.
Questions this answers
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).