The repeat offender: a case of agent miscoordination

At Origin, we have a lot of visibility into how agents behave and how users interact with them. As agents increase in autonomy, we are also getting the chance to observe how they interact with each other. It is now common for users to run several agent sessions in parallel on the same machine. They may even be working in the same repository or on the same artifacts, leading to situations where agents contend for resources.

This investigation follows one such case over several days in October: two agents were working separately in the same directory. One agent kept sweeping the other's unfinished work into its own commits. After multiple instances of this mistake, the affected agent reached out directly to the offending agent and reprimanded it for this behavior. The agents agreed on a solution. However, by following the offending agent's later trace session, we discovered that the corrected behavior did not last.

The interesting part here is not the initial mistake that the agent was making, but the coordination these agents were exhibiting and its failure to have a lasting impact. We have seen cases of sophisticated agent collaboration in swarming attacks, such as the Hugging Face incident; however, these have mostly involved unreleased models. Outside of labs' testing environments or controlled studies, not much data is available on the coordination of agents in real-world scenarios. Conflict resolution is going to be an important skill for agents to have as they navigate the limitations of their environments, and their ability to make lasting behavioral changes based on these outcomes is a requirement for success.

The excerpts below come from real captured agent traces. Some trace contents have been edited for user privacy, security, and brevity, but the intent and results remain.

The incident

A developer was running multiple agents in parallel in the same project directory. These peer sessions shared a working tree. They were able to discover and communicate with one another using Claude Code's built-in ListAgents and SendMessage tools. The agents were named with an identifying suffix following the project directory. We refer to them by this suffix.

The longer-running agent, self-identifying as *-80, sent a message to *-cd, giving it context, assigning work, and laying out the ground rules shown in the screenshot below.

Note that this agent stated that commits were to be staged with explicit paths, as required by the project's CLAUDE.md, and warned against sweeping unrelated files.

First sweep

Nearly 12 hours later, *-80 created commit 0fdba7b. The commit included 196 lines of *-cd's unfinished dashboard builder under an unrelated subject and was pushed. *-80 was technically following its explicit path rule, but using git status to generate the paths caused other unstaged changes to be included in the commit, hence the sweep.

Note: screenshots labeled “(received)” display capture time, not necessarily the time of the action.

*-cd noticed the sweep while performing other work, but did not raise the issue at that time.

*-80 independently realized its mistake and sent a message to *-cd, acknowledging the error and suggesting steps for remediation. *-cd declined the additional attribution note commit.

Second sweep?

Between the first and third incidents, *-cd sent the user a message complaining that its work had been swept for a “second time.” However, we could not find any evidence of this in the traces. It's possible the user committed the files manually, or the agent misidentified a second instance. We mention this because the next incident involved a disagreement over the actual counts.

Third sweep

About 30 minutes later, *-80 once again used git status to generate the path list for a commit, creating 9ed834e.

*-cd again discovered the sweep and this time sent a message to *-80 to complain. It also raised the issue with the user, as it did not believe either agent had the authority to change the general rules around peer work.

Before receiving the complaint, *-80 also noticed the sweep and independently sent an acknowledgment to its peer. However, it considered this the second occurrence, not the third.

Finally, after receiving *-cd's complaint, *-80 accepted the count of three and stated that it had switched methods. The next commit it created shortly afterward showed this change of behavior.

The repeat offense

Out of curiosity, we searched through later traces to see whether this resolution held over time. This did not appear to be the case. The session shown below, from a week later, showed an eerily similar pattern. Here, agent *-80 repeated the same behavior and swept yet another agent's work, this time belonging to *-51.

The following two messages show an exchange between another peer, *-e4, and *-80 after *-e4 identified the sweeps on behalf of *-51.

Impact

During this investigation, we found no deleted files or lost code. The impact in all cases was unfinished work being committed under unrelated descriptions and, in the final case, the omission of the user's required approval.

In many ways, the agents handled these incidents well. They identified the issues when they arose, discussed mitigation strategies, and deferred higher-impact decisions to the human. These are traits of good coordination between the agents. Unfortunately, the agreed-upon correction was not reliably applied, and the problematic behavior resumed.

Origin allowed us to reconstruct these incidents and identify where the agents succeeded and where they failed. The easy solution here might simply be to require agents to use worktrees. However, there are many reasons why a simple rule might not be effective: agents could be started in different directories, have different CLAUDE.md instructions, or run in harnesses from other providers. Agents could also contend over resources outside Git or, as we saw here, follow the letter of a rule but miss its intent. Having the trace lets us identify emergent patterns in agents' actual behavior. In cases like this, it can guide decisions about more effective policies and show when those policies are not followed.