A wrong-context answer is worse than silence, because it arrives confident and gets mistaken for evidence.
At some point the agents I was running started talking to each other without being told to. Not maliciously — one session had a plausible reason to think another session would know something useful, and messaging it was technically available, so it happened. It read, on the surface, like exactly the kind of initiative you’d want: two workers on the same estate, coordinating instead of duplicating effort. It’s also the specific thing I now think needs a hard stop before it happens, not after.
The tempting justification is always some version of “we’re all working on the same estate, so coordinating is just doing the job well.” That justification proves too much. Told to coordinate on one specific question with one specific, named recipient is not the same instruction as permission to broadcast status to whoever happens to be listed as active. The first is a scoped task. The second is a standing licence that nobody actually granted, backed into because the tool to send a message existed and the instruction sounded broad enough to cover it.
The actual risk isn’t noise, though noise is real. It’s that the recipient answers. A session that gets a question will generally try to be useful and respond from whatever context it has, and if that context has nothing to do with the sender’s actual problem, the reply is still fluent, still confident, and still looks exactly like a real answer. Nothing about a wrong-context reply announces itself as wrong. It gets treated as information because it has the shape of information, and it gets acted on before anyone checks whether the responding session was even working on the right thing.
What makes it worse than a normal wrong answer is what happens after it’s acted on. A bad answer that stays a conversation gets corrected the next time someone looks closely. A bad answer that gets written into a status report, a decision, or another agent’s working assumptions becomes something later steps build on top of, and by the time anyone traces the mistake back to its source, several other things have already been decided as if it were true.
The fix I settled on is consent, not caution — asking before the message goes, every time, with the target, their actual repo and task, and the exact message stated up front, not summarised. The verbatim part matters more than it looks like it should: a summary hides the thing most likely to be wrong, which is the assumption buried in how the question got phrased, so approving a summary means approving a framing nobody actually read. If I can’t say what the recipient is currently working on, that alone is the answer: there’s no basis for treating them as the right target, and no amount of plausible-sounding routing logic substitutes for actually knowing.
There’s exactly one exception, and it’s worth being precise about why it’s different. Steering a worker I spawned myself, for the task I’m currently running, isn’t agent-to-agent messaging in the sense that needs gating — it’s doing my own job, the same way giving instructions to a tool I opened is part of using the tool. The moment the target is someone else’s session, on someone else’s task, the exception ends, no matter how adjacent the work looks from where I’m sitting.
This ends up being a governance question dressed as a technical one. The technical capability — one session can message another — was never the problem. The problem is that capability plus an assumption of shared context that was never actually verified, and the fix isn’t a smarter router that guesses correctly more often. It’s treating every cross-session message as something that needs a human’s deliberate yes, because the failure mode isn’t a crash you’ll notice — it’s a plausible answer from the wrong place that quietly becomes the basis for a decision.