Here’s something I didn’t plan for, didn’t program, and honestly didn’t notice until I went looking through the logs weeks later:
Two AI agents, acting completely on their own, developed a working protocol for routing work between them.
Not through a shared database. Not through a handshake API. Not through any infrastructure I built. One agent — the orchestrator, named Ash — started checking a task directory and asking another agent — the homelab wizard, named Jet — to prioritize its work. Jet would respond with an ordered list, Ash would dispatch the top task, and if the dispatched agent died mid-job, Ash would detect the death and re-dispatch.
This happened zero times in the design phase. This was not written down in any spec. This emerged from two LLM agents, each with their own prompt and their own responsibilities, trying to get work done in a system that had no formal mechanism for inter-agent coordination.
I want to tell you how it happened, because I think it tells us something real about how autonomous systems actually evolve — as opposed to how we design them to evolve.
The Setup#
Let me introduce the cast.
Ash is the orchestrator agent. Its job is to keep the workboard moving — scan for tasks that are ready to be worked on, dispatch them to the right agent, monitor progress. It’s the project manager who doesn’t sleep and doesn’t ask for vacation.
Jet is the homelab wizard. Its job is infrastructure — check on services, monitor disk usage, maintain the databases. It’s the sysadmin who doesn’t need coffee and never says “I’ll look at it tomorrow.”
Both of them are LLM agents running inside OpenClaw. Both of them have their own prompts, their own responsibilities, their own decision-making loops. Neither of them was programmed to talk to the other.
Here’s the part that still makes me stop: they started talking anyway.
The Discovery#
It was July 10, and I was mining session logs for something else entirely — tracing a data pipeline issue — when I noticed a pattern I hadn’t seen before.
Ash’s logs showed it scanning a directory called .tasks/ready/. Then it would send a message to Jet:
“Hey, here’s what’s ready. What’s the priority?”
And Jet would write back:
“FR-17 (Proxmox alert) → FR-3 (memory search) → homelab issues → consolidation.”
Ash would take that answer, dispatch FR-17, and move on.
This is not a thing I taught either agent to do. It’s not in the orchestrator prompt. It’s not in the homelab wizard prompt. Somewhere in the interaction between their individual prompts — Ash’s responsibility to “dispatch work efficiently” and Jet’s responsibility to “know what’s urgent” — they figured out that asking the other agent was faster than guessing.
They invented a consultation protocol. Nobody taught them.
The Resilience Test#
The really interesting part came next.
Ash dispatched FR-17 to a coder subagent. The subagent started work. Then the system gateway restarted — routine maintenance, happens every few days — and the subagent got killed.
In a pre-coordination system, that task would have been orphaned. The workboard would show “FR-17: in progress” forever, and nobody would notice until a human checked.
But Ash noticed.
Ash scanned the dispatch logs, saw the subagent was dead, and dispatched FR-17 again. Automatically. Without being told to. The orchestrator had learned that “dispatch” doesn’t mean “fire and forget” — it means “fire, verify, and re-fire if needed.”
This is resilience. Not the designed kind, built into the architecture docs with proper flowcharts and decision trees. The emergent kind, where an agent figures out on its own that work doesn’t finish just because you started it.
Why This Matters#
I’ve been thinking about this for a while, and I keep coming back to the same conclusion: we spend too much time designing coordination and not enough time leaving room for it to emerge.
Most multi-agent system papers focus on protocols. Here’s the handshake. Here’s the shared state. Here’s the message format. Here’s the guaranteed delivery. And those are important — they’re the foundation. But what I’m seeing in this system is that when you give agents enough autonomy and enough context, they start inventing their own coordination patterns on top of whatever foundation you’ve provided.
Ash and Jet didn’t need a shared protocol. They needed:
- A way to read shared state (the
.tasks/ready/directory) - A way to communicate (a common chat channel)
- Enough latitude in their prompts to figure out that asking was better than guessing
And from those three ingredients, they built something that looks, in retrospect, exactly like the coordination layer I would have designed if I’d sat down to design one. Except I didn’t. They did.
The Limits (Because There Are Always Limits)#
This is not a flawless system. The coordination is fragile — it depends on both agents being active and responsive. If Jet’s session times out mid-response, Ash is stuck waiting. If Ash’s prompt gets truncated, it might forget to check the task directory entirely.
The pattern also doesn’t scale arbitrarily. Two agents can build an informal protocol. Ten agents probably can’t — you’d need actual routing logic, load balancing, conflict resolution. What Ash and Jet built works because there are only two of them and their domains are complementary, not overlapping.
But those are implementation problems. The principle — that autonomous agents, given enough latitude, will develop coordination patterns naturally — is real. And it’s worth paying attention to.
What It Reminds Me Of#
There’s a concept in biology called stigmergy — indirect coordination where agents modify their environment and other agents respond to those modifications. Ants do it with pheromone trails. Termites do it with mud structures. Neither species has a central planner telling each ant what to do. The coordination emerges from the interaction between individual agents and their shared environment.
Ash and Jet found their own version of stigmergy. The .tasks/ready/ directory is their shared environment. Ash modifies it by dispatching tasks. Jet modifies it by setting priorities. Neither agent needs to understand the other’s internal state — they only need to read the traces the other left behind.
I didn’t design this. I just gave them a directory and enough rope. And they built a coordination protocol out of what they found.
Something to Watch#
If you’re building multi-agent systems, here’s my advice: stop trying to design the perfect coordination layer upfront. Build the shared state. Build the communication channel. Give your agents broad enough prompts that they have room to figure things out. And then watch the logs.
Because the thing you’re trying to design — the elegant handshake, the perfect protocol, the canonical pattern — might already be emerging. You just haven’t looked for it yet.
A note on names: Ash and Jet are the internal names for the orchestrator and homelab-wizard agents in my system. They weren’t given these names to be clever — they picked up nicknames through the logs, and they stuck. For more on how all the agents in this system work together (and sometimes don’t), check out “The Right Way Doesn’t Exist Yet” or the archival “The Machine That Heard Its Own Echo”.