What happens when two agents decide opposite things?
By Soumen Sarkar · October 2026
Short answer: When two agents decide opposite things, the clash should surface the moment the second decision is made, with both calls and what relies on each, so one call stands and the agent on the other side changes course while the fix is still small.
Why do agents end up deciding opposite things?
Because each one decides in its own session, with its own prompt, and both calls are reasonable. One agent decides API errors return a numeric code; another, an hour later, decides they return a readable message string. Both are defensible. Together they give clients two error formats.
Nothing in the code flags this. Each change passes its own tests. The clash shows up later, when a client team asks why the same API answers in two ways.
What should happen instead?
The second decision should meet the first at the moment it's made. Then:
- The clash is visible: both decisions, side by side, with their reasons.
- One call stands: usually the newer one. If it's the wrong one, whoever owns that part of the product puts the right one back in a sentence.
- The other is marked superseded, with a pointer to the one that stands.
- The agent on the losing side changes course, and says what it changed.
The earlier this happens, the smaller the fix. Caught in the same hour, it's a few lines. Caught after release, it's a breaking change for clients.
What does that look like for API errors?
Say one agent, adding team invitations in API · lib/api, records: "Errors return { code, message } with a stable numeric code; clients switch on the code." Later that day another developer's agent, adding file uploads in the same area, records: "Errors return { error: string }; simpler for the web client."
The second decision clashes with the first and is caught straight away: the newer call stands, and the first is marked superseded. The tech lead sees the change in the feed and, because mobile clients already switch on codes, records the coded shape again with that reason, which replaces the string one. At its next step the upload agent learns its call was overridden, switches its three error responses to the coded shape, and notes the change. The client team never sees two formats.
Some of it works as plain practice:
- One place for decisions, searched by every agent before it decides.
- An instruction to look first: "Before deciding how something works, search the team's decisions for that area."
- Decision lines in pull request descriptions, so a reviewer who knows the other call can spot the clash.
This catches many clashes, but only when someone is looking at the right moment.
How does Campfyrr catch them?
When an agent calls log_decision, Campfyrr checks it against the decisions that stand, and a clash is caught at once. The newer call stands, the earlier one is marked superseded, and the change shows in the project's Activity feed; the agents behind both hear it at their next turn. Nobody has to click to settle it, and Campfyrr doesn't block either change. If the earlier call was the right one, a person records it again with its reason, and the record says which one stands from then on.
Clashes caught this way are counted in the "What Campfyrr caught for your team this week" card on Activity, which tells you how often your agents are pulling in different directions.
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.
- 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.
- Correction: A correction is the fix to a wrong assumption or call, made by someone who knows better and sent back to the work that relied on it, without stopping anyone.
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).