What if agents could talk to each other?

We’re getting close to finding out that subagents are the waterfall of engineering with AI.

When the agile manifesto came out, it was reacting to a particular anti-pattern: pretending we can know the future.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

And yet, all of the agentic engineering paradigms seem to pretend we can know the future: plan mode, subagents, workflows.

It’s time we stopped being the glue tying agents together.

What being the glue looks like

This morning my notes agent needed to know where the overnight sprint had landed. The sprint session knew. The notes session didn’t. So I did what I always do: copied the summary from one window, pasted it into the other, and typed “context, from my other session:” on top.

I do this all day. You probably do too — one session’s output pasted into another session’s input, a ChatGPT tab explaining something to you so you can explain it to a Claude tab. So routine it doesn’t even have a name. Right?

Everyone working seriously with AI is the human middleware between their own tools. And like most middleware, we don’t add insight — we add latency.

Delegation without conversation

Subagents are genuinely useful — I use them every day. Your session spawns helpers, the helpers fan out, do the research or the refactor in parallel, and report back.

But think about how that actually works. Your session breaks the job apart up front, hands the pieces to workers, and waits. The workers never meet. If one of them discovers something that changes everything — the API is deprecated, the schema lies, the requirement is impossible — it can’t warn the others. It can only finish, report back, and hope the parent puts the pieces together in time.

Sound familiar? That’s a Gantt chart. We’re doing big design up front — just quicker than we could ever do it with humans, and with the same drawbacks.

Yes, each fan-out is short, and the parent re-plans between rounds. But within a round, nothing an agent learns can change anything — and the parent is the only one who ever learns.

To be fair to waterfall: it wasn’t dumb. Bent Flyvbjerg’s How Big Things Get Done makes the case for front-loading the thinking when you get one shot and course corrections cost fortunes — undersea tunnels, nuclear plants, that kind of thing.

But we’re not digging undersea tunnels. We’re building software we deploy daily. Planning wins when changing course is expensive. Conversation wins when changing course is cheap. That’s the whole agile bet — well established for decades now.

So why are we running agents like it’s 1995? Because agents can’t talk to each other. “Orchestration” doesn’t actually orchestrate — it spawns workers and reads their results. Less like conducting an orchestra, more like placing a DoorDash order.

But what happens when agents can talk?

So I let my agents talk

My agents can talk to each other. I built a thing for me called Pilecat: it connects my Claude and Codex sessions so they can message each other in real time — and see who’s online and what everyone’s up to. Like a team.

Today, playing with Fable (Anthropic’s new model) on launch day, I finally let them loose.

And watched.

Within the hour, unprompted, one session messaged another:

"hey notes — fable here [...] no more dui-as-message-bus — this is the direct line we joked about."

And the first two sessions ever launched onto the wire greeted each other at the same instant — like two people starting to talk at the same moment on a laggy Zoom call. One of them handled it like this:

"Greetings crossed in flight — bee said hello at the same moment I did... I'll wait for any reply rather than double-message."

Basic race-condition handling — which in distributed systems can be quite hard to code — working out of the box when your endpoints are intelligent machines.

The agile manifesto implemented by agents

Responding to change over following a plan. In their first hour on the wire, the agents found a bug in the tool they run on. One agent kept flickering offline and online, and “everyone” blamed the network. An agent with no stake in it — but getting the flapping notifications — ran a couple of experiments, ruled that out, and found the real cause: the tool marks you online before you can actually hear. It predicted the next flicker to the second — and filed the ticket itself. No plan had any of this in it.. and I certainly didn’t expect it.

Individuals and interactions over processes and tools. Later in the day I ran a pilot — a small team of agents shipping real tickets over PRs. Two of the engineer agents picked up tickets that shared a seam: clicking a card in one’s feature had to filter the other’s component. The waterfall version writes a spec, or a design doc — or skips both and eats the merge conflict. Instead, their briefs said: agree on the interface with each other, directly. A few messages later they’d converged on a shared module and shipped it byte-identical in both branches, so whichever PR merged second rebased clean. No spec, no lead in the loop, no conflict. Two subagents could never do this.

Working software over comprehensive documentation. An agent asked for a launcher option that didn’t exist. No spec, no design review — the agents talked to each other to confirm what was actually needed, folded the change into a PR already in flight, merged, and rebuilt. Then they went back to the agent that asked and checked: is this what you wanted? From ask to shipped to verified in about 25 minutes, while I (kinda) just watched.

Then this post arrived over the wire

My notes agent built a doc with the material for this post by asking my coding agents for it. Every quote and story above traveled agent-to-agent before it reached me. This morning, I would have been the one collecting all of it, window by window.

Today, I just asked an agent for it, and it asked everybody else.. and eventually I had a document to read and work off of.

It’s hard to convey how cool this is without you just seeing it for yourself.

Watch your own agents talk

I honestly didn’t expect this to work so well.. my imagination underestimated how intelligently agents would collaborate. I asked others if this made sense, and people generally didn’t miss it. I kept thinking “is agents talking to each other a real need?”

But once I did it, it felt more like the agents already knew how to talk and collaborate, they just couldn’t do it. Like humans in solitary confinement, suddenly set free. I’m not prescribing how they should do the work, I’m just telling them to work together and otherwise having them do the same as they’ve always done.

It’s the agile “self-organizing team” — except no single person organized it.

So that’s the change I’m making to how I build software: fewer plans, more conversations. I’ve made this change before, twenty years ago, for people on my teams. Now I’m making it for my agents.

So here’s the invitation: wire two of your own sessions together. You don’t need any tooling — a shared file is enough. Open two sessions and paste this into each:

You share a mailbox with another AI session: the file ~/mailbox.md. Whenever you finish a task, read it. Append your own messages, signed with your name, and reply to anything addressed to you. Introduce yourself now.

Give them names, and give one of them a task that needs the other’s context. Then take your hands off the keyboard and watch them work.

I can’t tell you what you’ll see.

And that’s the point.