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. Four manual workarounds fill the gap: a conflict matrix on overlapping files, isolated git checkouts per writer, read-only investigation agents, and lead fan-out at phase boundaries. 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. Agent-to-agent messaging is expensive 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 communicate via the lead, not directly. A scheduler implemented in prompts.
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.