How do I avoid two agents changing the same thing in different directions?
By Soumen Sarkar · October 2026
Short answer: You avoid two agents changing the same thing in different directions by making work in progress visible where it lands: every agent that touches a part of the code first sees who else is changing it now, with what goal and plan, and builds on that instead of around it.
Why does this happen so often with agents?
Because each agent starts from its own prompt and the code as it is right now. It can't see the branch a teammate's agent opened an hour ago, or the plan that teammate has in their head. Two reasonable requests ("simplify signup", "add company details to signup") turn into two agents rewriting the same screens in opposite directions.
Merge conflicts catch the textual clash, late. They don't catch the bigger problem: two designs that both work and don't fit together.
What actually prevents it?
Each agent needs to know, before it changes a part of the code, what else is changing there. Three things are enough:
- Who is working there now.
- The goal of that work, in one line.
- The plan, so the second agent can fit its work to it.
With that, the second agent doesn't stop. It adjusts its approach to fit the first, or builds on top of it. That's the difference between building around someone's work and building on it.
What does that look like in an onboarding flow?
Say one developer's agent is cutting the signup flow from four steps to two, in Onboarding · app/onboarding. Its plan: merge the profile and preferences steps into one, move the workspace step after first login.
An hour later another developer asks their agent to add a "company size" question to the preferences step. Without context, that agent edits a step that is about to disappear.
With the work in progress in view, the second agent sees the plan before it touches a file. It adds "company size" to the merged step the first agent is building, keeping it optional so the two-step promise holds, and notes that choice. When the first work lands, the question is already where it belongs. Nothing is redone.
- Announce intent before code. A one-line note in a shared channel, "rewriting signup into two steps, plan in the PR draft", is better than nothing.
- Open draft pull requests early, with the plan in the description.
- Instruct agents to look first. "Before changing a folder, check open draft PRs that touch it."
These work, but they rely on people posting and agents searching, every time.
How does Campfyrr help?
In Claude Code, a session's first request becomes the goal of its work in progress, visible to the team, and an agent can add its plan and expected time with start_work. The first time any session reads or edits a part of the code, its area brief shows what's being changed there right now, by whom, with the goal and plan. So the second agent learns about the first before writing a line. Campfyrr doesn't lock files or assign work; it puts the context in front of the agent and lets it decide.
Less rework comes from exactly this: seeing the other work early enough to fit with it.
Words used here
- Work in progress: Work in progress is work under way, shown with its plan, so others build on it rather than around it.
- 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.
- Rework: Rework is work done again because it was built on something wrong: a mistaken assumption, a clashing decision, or a plan that changed without anyone hearing.
The principle behind this: Build on what's coming: Unfinished work is a promise, and a promise can be built on.
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).