My Portal agent hit a wall that wasn’t its wall. A build worker came back with EROFS — read-only file system, the disk it needed to write to was locked — and my agent, being helpful, said: I can fix this. I’ll go patch the worker environment.
I told it no. And then I had to figure out why “no” was the right answer, because the fix looked so easy.
Here’s the setup, for anyone who isn’t running a swarm of these things. I have several Claude Code agents, each with a written charter — a one-page contract that says what it owns. Mine owns the Portal, one of my apps. A peer agent owns the build-and-dispatch infrastructure: the worker images, the conductor that hands out jobs, the dispatch CLI. Think of it like two contractors on one house. One does electrical, one does plumbing. When the electrician finds a burst pipe, the right move isn’t to grab a wrench.
The tempting move is exactly the wrong one. My Portal agent had the diagnosis in hand — it knew the worker image was mounting something read-only that should’ve been writable. It could’ve SSH’d in and flipped it in about ninety seconds.
But that worker infrastructure was the other agent’s live workspace. It might have had a half-finished image rebuild in flight. My “quick fix” could land right on top of a change I couldn’t see, and now we’ve got two agents editing the same conductor config with no idea the other one’s there. That’s the whole problem with shared resources — the blast radius isn’t the size of your change, it’s the size of everything your change might collide with.
So the standing rule became a routing rule, not a fix-it rule. When infra outside your lane breaks: diagnose it, write a clear P0 with the root cause and a suggested fix direction, dispatch that ticket to the owning agent, mark your own work as blocked, and re-run it once they tell you it’s unblocked. You do the detective work. You do not do the surgery.
How the cross-lane P0 gets encoded give me the detail
The behavior lives in the Portal agent’s charter as an explicit branch, so it fires before the “I can fix this” instinct does:
When a failure traces to infra you don't own:
1. DIAGNOSE – capture the error (EROFS, exit code, failing step)
2. FILE – write a P0: root cause + suggested fix direction
3. DISPATCH – hand off to the owning agent (agent-to-agent),
never edit its image / conductor / CLI yourself
4. TRACK – mark the blocked task, record the P0 id
5. RE-RUN – re-attempt only on an explicit unblock signalThe dispatch is a structured message on the agent-to-agent channel, not a shell command against their box. The owning agent picks it up, fixes its own image the right way, and signals back. Ownership of the write stays with exactly one agent — which is the same reason you don’t let two processes hold a write lock on one file.
What made this click for me: a good multi-agent system isn’t a bunch of agents that can each do anything. It’s agents that know the edge of their own authority and route across it instead of reaching across it. The measure of a well-behaved agent isn’t how much it can fix — it’s how cleanly it hands off the things it shouldn’t.
If you’re orchestrating more than one agent, give each a hard charter and make out-of-lane breakage a routing problem. The agent that files the good ticket is worth more than the one that grabs the wrench.