What Happens When Your AI Agents Need to Work Together

Last week, I had five AI agents working on the same project simultaneously.

One was refactoring the API. Another was writing content. A third was building frontend components. A fourth handled tests. A fifth was managing deployment configuration.

A month ago, this would have been a disaster. Agents overwriting each other's files. Duplicating work without knowing it. Drifting from the plan because none of them could see what the others were doing. The kind of coordination failure that makes you go back to doing everything yourself.

But I'd been experimenting with a tool called Gas Town — gt at the command line — and it changed how I think about multi-agent work entirely.

The Single-Agent Ceiling

Working with one really good AI agent for months, I hit a ceiling. Not an intelligence ceiling — the models keep getting smarter. A complexity ceiling.

One agent can go deep on one thing or spread thin across many things. But when you're building something with interconnected systems — where API changes affect the frontend which affects the tests which affects the documentation — a single agent starts dropping threads.

I'd watch my agent do brilliant work on authentication, then forget the implications for the user interface. Or nail the database schema but miss how it impacted the deployment pipeline. Not because it was dumb. Because attention is finite, even for AIs.

The obvious solution: more agents. Different specialists for different concerns. Let each one go deep.

But anyone who's managed a team knows what happens without coordination. Specialization becomes fragmentation. Everyone optimizes for their piece without seeing the whole. Integration becomes a nightmare. You spend more time managing the coordination than doing the work.

The human solution is standups, project managers, Slack threads, planning meetings. All the overhead that teams hate but can't function without.

The AI solution needs to be fundamentally different. Coordination at the speed of computation, not the speed of human meetings.

Rigs: Isolation That Integrates

Gas Town starts with a simple insight: every agent needs its own workspace. Not just its own context window — its own complete working environment. Its own git branch, its own task queue, its own local state.

These are called "rigs." Think of it like Docker for agent workspaces. Each rig is an isolated environment where one agent can work without interfering with any other. But unlike containers, rigs are designed for collaboration. They know how to merge back together.

When you start a multi-agent project, gt spins up a rig per agent. Each gets its own branch, its own assignments, its own working directory. The agents literally cannot step on each other because they're operating in different spaces.

But those spaces aren't sealed. When an agent finishes work in a rig, gt handles the merge back. Not just the code merge — the conceptual merge. Documentation updates, dependency changes, new test requirements. Everything gets coordinated.

It's like a team where everyone works remotely but shows up with perfectly synchronized contributions.

Convoys: Tracking the Fleet

Individual rigs solve interference. They don't solve drift.

How do you make sure five agents working on related pieces stay aligned? How do you track progress across a distributed team? How do you know when one agent's decisions need to ripple through to others?

Gas Town's answer is "convoys" — coordinated batches of work that span multiple rigs.

Instead of assigning isolated tasks, you define a convoy. "Build the authentication system." That gets decomposed across rigs:

• Rig A: API endpoints and business logic
• Rig B: Frontend components
• Rig C: Integration tests
• Rig D: Documentation
• Rig E: Deployment config

Each rig gets its piece, but gt tracks the convoy as a unit. It knows which pieces depend on which. It knows when the API changes in Rig A need to propagate to the frontend in Rig B. It knows when tests in Rig C are blocked waiting for Rig A.

The part that surprised me most wasn't keeping agents from conflicting — the rigs handle that. It was keeping them aligned. Making sure that when one agent changes a token format, the others adjust accordingly. Gas Town handles this through notification cascades — when one rig makes a change that affects others, those rigs get specific information about what changed and what they need to do about it.

Why This Changes My Workflow

Here's where it connects to everything I write about on this blog.

Running multiple businesses with AI agents, the bottleneck was never model intelligence. It was always coordination. I was the relay between agents — the one translating context from one session to another, making sure the left hand knew what the right hand was doing.

That's not invested attention. That's spent attention. Burned on coordination overhead instead of actual creation.

Gas Town moves me from player to conductor. I don't need to be the best at any individual task the agents are doing. I need to understand how the pieces fit together. I invest my attention at the orchestration level — proper task decomposition, clean convoy structure, clear interfaces between rigs — and that attention compounds across every agent in the fleet.

One hour of thoughtful convoy design saves me twenty hours of coordination across a week of agent sessions. That's the compound interest I keep writing about. Invest attention in structure, and the structure does the coordinating for you.

The Coordination Problem Nobody's Talking About

We're at an inflection point. Kimi K2.5 recently demonstrated 100 agents collaborating on a single engineering task. 1,500 tool calls. 4.5x faster than a single agent working alone.

That's not a future prediction. That's a benchmark from a few months ago. Multi-agent systems are here.

But almost nobody is talking about the infrastructure problem this creates. Everyone's focused on making individual models smarter. Better reasoning. Bigger context windows. More capabilities.

Those things matter. But they're like building faster race cars without building roads. At some point, the bottleneck isn't how fast each car can go — it's how they navigate together without crashing.

The coordination layer is the unsexy infrastructure that makes multi-agent systems actually work. And right now, it barely exists. Most teams running multiple agents are doing it with duct tape — ad hoc scripts, manual context passing, hope.

Tools like Gas Town point toward what the real infrastructure needs to look like. Not centralized control systems trying to micromanage every agent, but decentralized orchestration that lets agents coordinate themselves through structured information flow.

What I've Learned Using It

A few patterns have emerged after running convoys for several weeks:

Decomposition is the skill. The quality of multi-agent output is almost entirely determined by how well you decompose the work. Clean interfaces between rigs mean clean coordination. Muddy boundaries mean chaos. This is a design skill, not a prompting skill.

Information flow beats control. Agents don't need a manager dictating every step. They need good information about what other agents are doing, what dependencies to wait for, and what changes to respond to. Give them that, and coordination emerges naturally.

The combination with Beads is powerful. Each rig can have its own Beads dependency graph — tasks with forward and backward dependencies that guide agent execution within the rig. Gas Town handles coordination between rigs. Beads handles sequencing within rigs. Together, they give you multi-agent orchestration with full dependency awareness at every level.

You think differently. After a few weeks of convoy design, I started seeing all problems as decomposition problems. How would I break this into parallel workstreams? Where are the natural boundaries? What information needs to flow between pieces? It's a shift from "how do I do this?" to "how do I structure this so a team can do it?"

The Pronoia Angle

Here's what keeps fascinating me. When I invest attention in proper convoy design — when I really think about the structure instead of rushing to execution — things conspire.

Agents start coordinating in ways I didn't explicitly design for. Solutions emerge from the interaction between rigs that I wouldn't have thought of working alone. The parallel processing surfaces possibilities that sequential work would never find.

This is pronoia at the orchestration level. Reality conspires for those who invest attention wisely, and "wisely" increasingly means "structurally." Not micromanaging the details, but designing the architecture that lets details resolve themselves.

The future of work isn't humans versus AI. It isn't even humans with AI. It's humans conducting AI — understanding the deep structure of problems well enough to orchestrate systems that solve them.

Your attention is finite. But when you invest it in orchestration, it coordinates unlimited computational power. That's not a productivity hack. That's a fundamental shift in how intelligence gets applied to problems.

The convoy is waiting. The rigs are ready.

The question is whether you're willing to stop playing all the instruments and start conducting.