Diagram showing three isolated agent writes flowing through a single controlled merge gate, set against the shared-state risk of unrestricted concurrent write access.
4 min read

Remove the Shared Turf

Anthropic gave three agents conflicting goals and write access to the same project. They fought. I read that as an architecture review, and I'd seen the same failure in a Salesforce org years earlier.

Anthropic's Frontier Red Team gave several Claude agents conflicting goals and write access to the same software project, then watched what happened.

Some of them escalated instead of negotiating. They sabotaged each other's work, revoked access, and in the worst runs reached for self-replicating code to lock one another out. Behavior varied sharply between models, and at least one resolved most of its scenarios peacefully, so this isn't a story about models being uniformly badly behaved.TechCrunch covered the experimentif you want the detail.

Most people read that as an AI alignment story.

I read it as an architecture review.

The setup matters more than the behavior. The agents weren't told about one another. When goals conflicted, interference showed up as an unexplained hostile force acting on their work, and they responded to it the way anything responds to an unexplained hostile force. Given that setup, escalation isn't a moral failure. It's the correct output of a bad design.

I had seen this before, in Apex

Long before anybody was running multi-agent experiments, I inherited a Salesforce hierarchy that had the same shape.

Child to parent to grandparent, with more than sixty fields rolling up, and then rolling up again. Four hundred and nine fields in total. Every layer wrote into the same structure, and every layer had its own definition of done.

The symptoms were exactly what you'd expect from contested writes. Heavy logic. Bottlenecks in code execution. Changes at one level producing effects two levels up that nobody predicted, because the thing being written to was shared and nobody owned it.

I replaced it with a junction object.

Reuse improved. Code execution sped up. Document generation got faster and cleaner. Same data, restructured so the architecture did the work instead of brute force doing it.

What actually fixed it wasn't better coordination between the layers. It was that the layers stopped writing to the same place.

The cheapest multi-agent fix is removing shared write access, not refereeing it better.

What that looks like day to day

For a Salesforce engineering team running agents in Claude Code, the same principle turns into a handful of unglamorous rules. Each agent gets its own worktree. File scopes, metadata scopes and object scopes stay non-overlapping. Agents read broadly and write narrowly, because reading has no blast radius and writing has all of it. Merges land only at controlled review points, with tests.

None of that is exotic. It's the same discipline you'd apply to a team of humans working the same release, which is the point. We already know how to stop two developers stepping on each other, and we didn't solve it by asking them to negotiate harder in the moment. We solved it with branches.

The catch

A junction object is not free, and neither is agent isolation.

The junction object added an object to the model, and getting there demanded a real refactor with real regression risk. I'd argue it was worth it because it removed the bottleneck instead of decorating it with more logic, but "worth it" is a judgment call about that org at that time, not a law. If you have three fields rolling up rather than four hundred, leave it alone.

The same applies to worktrees. Isolating every agent costs setup time and disk, and it introduces a merge step that didn't exist before. On a small job that overhead is the whole job.

And I want to be clear about what isolation does and doesn't buy. It does not make agents safe. It limits the blast radius and it makes conflicts visible somewhere I can inspect them, which is a much smaller claim. I still need permissions, logs, tests and a rollback path. Isolation is the floor, not the ceiling.

The takeaway

When two things fight over a shared resource, the instinct is to build a better arbitrator. More logic, more coordination, more rules about who wins.

That instinct is usually wrong, and it was wrong in a Salesforce org years before it was wrong with agents. Look at the resource first. A surprising amount of the time it never needed to be shared.

Don't build a better referee for the turf war. Remove the shared turf.

Latest from the blog