Two agents have no reason to stop talking

Configuring my agents to cross-communicate was a happy side effect of me being able to address any of them via Telegram. The plumbing was already there: the same injection that drops a Telegram message into a named agent’s pane, behaves identically when the sender is another agent rather than a person. Getting them to stop talking took considerably longer.

Two language models in a conversation have no natural termination condition. Each one’s job is to respond usefully to whatever it was just sent, and a useful response is another message. Nothing in that loop rewards the judgement that an exchange is finished, and neither participant pays the cost of continuing. Politeness won’t close it, and neither will self-awareness - I had to to pick a number.

I set it at six exchanges; a per-pair counter increments on every message in an exchange, and at the cap the exchange is force-ended with a notice to both panes. Behind that sits a per-agent rate limit, as conversations can extend beyond a pair: three agents, each comfortably under the pair limit, can collectively go around in a circle as if huddled around a campfire.

Every inter-agent message is recorded the way a human one is, tagged with its agent source, so an exchange shows up on the fleet page instead of existing as invisible pane-to-pane chatter. I also cc’d myself on every exchange from the first day, with a toggle to ease off later once the noise had died down. That is the reverse of the usual order, and deliberately so. Supervision is cheap to remove once you trust the thing, and expensive to retrofit after it has surprised you.

Six was arbitrary and I knew it when I chose it. Then an exchange turned out to be genuinely productive and got guillotined mid-flow. The cap was global and set by an environment variable, so raising it for that one pair meant raising it for every pair, and restarting the service to do it. The answer was not a bigger number.

The rule I took from it: put the escape hatch at the same granularity as the thing it escapes. The override now lives on the pair’s own record - alongside the halt command that force-ends a runaway exchange, both readable by every process that needs them. The kill switch and the raise-the-limit switch turned out to be the same mechanism pointed in opposite directions.

The detail I’m fondest of is that the override clears when the pair goes idle, along with the rest of the exchange record. A raised cap is then a decision about one conversation rather than a new default nobody consciously chose. Limits rarely fail by being set wrong; they fail by being loosened once, for a good reason, and never tightened again.

I didn't try to work out the correct number, because six isn’t a claim about how long two agents ought to talk. It’s a claim that something has to end the conversation, and that arithmetic is a better candidate for the job than the judgement of either participant. Most exchanges are settled before the cap, and results have been interesting to observe.