Notes on coordinating AI agent swarms
Async Digital Ltd Cardiff, UK
Agent swarms are trivially parallel: many model calls on separate compute, each with its own context window. They are almost nothing else. Current runtimes ship without the primitives a working concurrent system needs, so every parallel-agent pattern of value is a hand-rolled concurrency primitive bolted on by hand. Six primitives are missing: a shared memory model, synchronisation, ordering guarantees, fast inter-agent communication, back-pressure, and transactional boundaries. Direct session-to-session messaging has since arrived, which is a pipe rather than a primitive. Five manual workarounds fill the gap: a conflict matrix on overlapping files, isolated git checkouts per writer, read-only investigation agents, lead fan-out at phase boundaries, and advisory locking negotiated between peer sessions. Agent swarms accelerate independent investigations, scoped file rewrites, and parallel research queries. They fall over on anything requiring synchronisation, cross-agent invariants, or ordered commits to a shared artefact, which is, in practice, most non-trivial engineering work.
The name is deliberate. As a single engineer learning to become a team of several, I have to learn how to work asynchronously. AI agents are the team-of-several taking shape.
The missing primitives
Agent swarms are trivially parallel: many calls on separate compute, with separate context windows. But they have almost none of the primitives a concurrent system actually needs.
- No shared memory model. Agents each have their own context. They don’t see each other’s reasoning unless it’s explicitly piped. Decisions can diverge silently.
- No synchronisation primitives. No mutex for “I’m editing this file”. Conflicts are detected post hoc, by git merge or by file overwrites. The rule I keep for myself about not delegating overlapping work to agents concurrently exists because the runtime doesn’t provide one.
- No ordering guarantees. “Run these in parallel” means independent execution, not coordination. Agent A might commit before Agent B’s invariants land; nothing in the runtime stops it.
- Communication is high-latency, low-bandwidth. A direct channel now exists: separate terminal sessions can address one another over a local socket, without routing through a person or a lead. The pipe is new; the cost is not. Every message is still prose a model has to read, write and reason about, priced in tokens and seconds. Compare to threads sharing memory at nanoseconds, or Erlang actors passing messages at microseconds.
- No back-pressure or flow control. Three agents asking a fourth for input means no queue management; the fourth just gets whatever arrives.
- No transactional boundaries. No way to say “either all three agents commit or none do”. Each ships independently; rollback is bespoke per task.
The workarounds expose the gap
Every parallel-agent pattern I’ve ended up writing down is a manual concurrency primitive bolted onto a runtime that doesn’t provide one.
- Conflict matrix before delegation. A rule I keep for myself that agents touching overlapping files cannot run in parallel. A manual mutex.
- Isolated checkouts. Each parallel writer gets its own git worktree. Process isolation, rebuilt by hand.
- Read-only investigation agents. Investigations skip the isolated checkouts because they don’t write. No write contention by construction.
- Lead fan-out at phase boundaries. Sub-agents inside a session communicate via the lead, not directly. A scheduler implemented in prompts. Peer sessions are no longer bound by this; sub-agents still are.
- Advisory locking by negotiation. Two sessions about to write the same shared files settle the overlap in conversation. One declares what it is about to touch, the other answers with its own claim, and they agree an order and a signal on release. The arrangement works, and it is a lock built out of good manners. Nothing enforces the yield, nothing times it out, and a session that has gone quiet looks exactly like one still holding.
Where swarms win, where they fall over
Agent swarms are genuinely useful for independent investigations, scoped file rewrites in non-overlapping directories, and parallel research queries. They fall over on anything that needs synchronisation, cross-agent invariants, or ordered commits to a shared artefact. Which is, in practice, most non-trivial engineering work.