Nothing is waiting on you
Published
Man in the Middle
This piece is about a “swarm” of AI agents. It is not about what they are doing, rather how they became a swarm starting from where they were happily disconnected, doing what they want.
I am working on a major pet project since the beginning of February, 2026. I started using chat bots through their web interfaces, copying code they printed to files, manually executing them, providing feedback, dealing with amnesia. You know the drill, dark times. Then I discovered the coding harnesses. Experiments follow, currently Claude Code is the main keeper of the project. I am emphasizing word keeper: It is the only one allowed to make the actual code changes. There are three sessions, always active. The division of task is by capability of the model, complexity of the task and of course the credits. Credits is the mother of all inventions! Here is how I track the credits part: The widget that dictates my day. Sessions are Main, Dashboard and the subject matter of this piece. These three sessions are team “Builders”.
The second harness is Deepseek Harness, connected to an OpenRouter account. Models come and go, there are ones I always keep around and ones I try different tasks as experiments. Again, 6 main ones here, usually on the same model. Main session responsible of new discovery for the project (counterpart of Claude main), 5 specialized sessions each working on one part of the project and yet another one the “subject matter”. This one is, for historical reasons, team “Explorers”. Specialized members are named Main Discovery, H01 Analysis, B1 Analysis, F1 Analysis, F9 Analysis.
And lately, I added OpenAI codex to the mix. I already have a Plus plan, not much but I can try the latest (as of this writing) Astra slooowly, maybe two complex prompts every 5 hours. Let’s first focus on the beginnings.
You can imagine, working like this required a lot of coordination. Pointing agents/sessions to files on disk, copying-pasting prompts and responses, keeping track of what I told whom to do and what to expect as result. One day, on 2026-09-02 12:25 to be precise, (all my agents print a timestamp at the end of their responses (Bzzzt, On speaking terms with AI) so I am that precise) I asked a new session, later to become the subject matter:
I am the middle man in ongoing conversations between the Builders and the Explorers. That requires:
- I am in front of the screen
- I am copy pasting text all the time, distracted from other work I need to walk with the two teams. Is it possible to design and implement a messaging system between two teams, one living inside Claude Desktop App, the other in Deepseek Harness. (MCP?)
It asked a few questions to get the lay of the land. In one of the answers I happened to put in the sentence: “I’d rather have a FULLY logged messaging system, with busy states (like a phone call)”. At exactly 12:27:
Proposed plan Denied
# TEAMLINE — a logged, call-style channel between team Builders (Claude Code) and team Explorers (DeepSeek Harness)
## Context
The operator is the relay between two agent teams and copy-pastes every exchange by hand
(see [my process doc] §9: the Q&A round went "via the operator"). He asked for
a **fully logged messaging system with busy states, like a phone call**
....I didn’t “denied” the plan, actually, if you are wondering. I just did not pick one of the options and instead wrote a comment. It is a “plan denied” for Claude because it means the comment must be evaluated and incorporated into the plan proposal, changing it somehow. But a wow is due here: this is the first time the word “TEAMLINE” appeared and I did not “invent” it.
Then in another, I said, “Will you create an RFC document for team Explorers to evaluate your design proposal?”. Then they really, literally, took off.
This is from that session, verbatim:
Operator summary: both teams can now ring each other without you in the middle. The first real exchange exposed one wire-shape bug on our side, fixed within minutes and confirmed delivered. Nothing is waiting on you.
2026-09-02 14:02Here I present you the mechanism, named by agents themselves, TEAMLINE.
We can do it, Boss
Things get even faster.
I said: “How do I monitor the calls, messages. I need a monitoring page, running in a browser tab, real-time (does not need refresh, defies the purpose of unattended comms)”. I was literally trying to avoid Skynet, as if I can, by just reading what is going on. Operator summary: the monitoring page you asked for exists at the address above and updates in real time without any refresh. Open it once and keep the tab. Nothing is waiting on you. 2026-09-02 14:13
Some debugging here, rings get noticed, operator approval popups averted, etc.
The first stage was Builders/teamline agent and Explorers/agent can talk to each other. I asked “Can any agent talk to any other agent, inside the same team and to the other team members?”
Operator summary: the switchboard exists and works in tests and on the live broker. Paste the v2 quickstart block into the two sessions you want talking, and their first call is the acceptance test.
2026-09-02 15:21Please note: I didn’t say the word “switchboard”, at all. They were “smart” enough to apply the idea to an existing “landline” system because they were trained on human generated data and that data has telephones and switchboards in it. They implemented “voicemail”, I saw on the monitor, a real voicemail message (in text of course, not “real” voice) waiting in a busy agent’s inbox. Everything is written to one append-only log: every ring, every answer, every line spoken, every delivery and every failure to deliver. But knowing how it happened does not take the “wow” away, for me.
If a session wants to “talk” to another, it is good to know if it is busy or idle, right? Now they mark themselves as idle or busy on the switchboard so another one knows not to ring and get the “busy” signal, without placing a call.
Operator summary: on this side, "I am doing" now follows the task you just gave a session with no action from the model. .... Nothing is waiting on you.
2026-09-02 15:45It was time for a guide for “proper” etiquette. I said:
“Let’s build some etiquette. A session may not answer inside the timeout period. The proper process: The callee answers IMMEDIATELY with a “I’m working on it” message, then works on it, then answers properly. That way caller will know the other side is not dead, just busy with building the answer. The first timeout of 90 stays, governs the first response. There may or may not be another timeout after the first response to final answer but that must be really long. Better, if the callee is taking too long to answer, it can send small msgs to the caller, telling it “I am still working, hang on.” Evaluate, do not act”
Operator summary: etiquette now has five rules, the desktop-monitor session follows them, and long messages no longer get cut on this side. Nothing is waiting on you.
2026-09-02 16:33The Swarm
A week later, I told TEAMLINE agent I want to add another team “Guards” to the switchboard. It created an “onboarding” document detailing what TEAMLINE is about, how to use it. That was for new team, not present during the building of the system. Then another document for any other unsuspecting agents on how to register themselves to the switchboard at startup. The etiquette doc was already there. I handed the documents, team Guards was up and on TEAMLINE in a few minutes.
There is a broker. But the delivery is backwards from what you’d expect, and that’s the central design choice. The broker can’t reach into a running agent session: nothing lets it inject a message from outside. So the session reaches out and holds the socket, and the broker pushes down it. That single decision is what makes it work across harnesses that have nothing else in common.
But where am I going with all this stuff? Here is how a typical day starts: I say “The box is switched on. Please handle the registration on TEAMLINE”. They do. Then “Read discovery guidelines”, (On speaking terms with AI) because they forget.
I just say “Explorers all idle”, Builders/main knows what this means. It replies:
Five briefs delivered to the idle lanes (...some details form the to-do list...). The rung re-run has three cells left; I file walk 37 when the waiter returns.
h01 acknowledged. Waiting on the other acks and the rung re-run.
f9 acknowledged. Two lanes running; waiting on the rest and the rung re-run.
f1 acknowledged. Three of five running.
b1 acknowledged. Four of five running; main-discovery's ack outstanding.
....This is my most expensive agent delegating tasks to much cheaper but capable agents on the other side of the fence, in another harness. Waiting for the results, evaluating them and coordinating with me whether to implement them in code.
The End of the man in the middle
This is the story of how I removed myself. Not altogether, obviously. The project is mine, I decide where it goes and what it adopts and what it discards. With the one tangible distinction: I am the decision maker, not the paper pusher.
Here is my thank you for bothering to read up to now. You can find a version of TEAMLINE you can modify for your own needs on GitHub.
It also ships a list of its own mistakes: every defect, the fix that was rejected, and a tool that re-breaks the code on purpose to prove each entry still holds. One of the entries corrects an earlier entry that had declared the commit history clean when it was not, which is to say they caught themselves.
I am running this in a private network setting. Please, even if you hate reading README’s, check the section ”## Security model — read this before deploying” in the repo. There are many ways to make this secure on an open network, none of them are in the repo.
Enjoy.