What an agent swarm is, from OpenAI’s Swarm library to fleets of hundreds of sub-agents, and the test that tells you when a swarm’s shared state will break under contention.
TL;DR: An agent swarm is a group of AI agents that split one job, run in parallel or hand work to each other, and combine results. Most swarms are partitioned: each agent owns its slice, and nothing collides. The hard ones contend: many agents read and write the same counter, record or budget inside a short window. That state can’t be merged after the fact, so it has to be coordinated when it’s written, and every agent has to read the current version of it before acting.
You split a job across forty agents and it worked. The research swarm read forty sources in the time one agent reads three, and a lead agent stitched the findings together. Then you pointed the same pattern at live work: outreach, purchasing, ticket triage, infrastructure changes. Two agents emailed the same prospect an hour apart. A spend cap was crossed by three purchases that each saw room under it. A ticket ended up assigned and closed at the same time.
None of those are model failures. The agents reasoned correctly over what they read. What they read was out of date by the time they acted, because another agent had changed it in between.
An agent swarm is a multi-agent system in which many AI agents work on one objective at the same time, each with a narrow role, tools and context. Work is split, handed off or run in parallel, and results are combined. Swarms differ mainly in what the agents share: nothing, a message history, or live mutable state.
The word arrived in AI engineering through a few concrete projects, and they mean slightly different things by it.
OpenAI Swarm. OpenAI’s Swarm repository describes itself as an “educational framework exploring ergonomic, lightweight multi-agent orchestration.” Its two primitives are agents (instructions plus tools) and handoffs, where one agent hands the conversation to another by returning that agent from a function. Swarm runs almost entirely on the client and does not store state between calls. The repository now points production users to the OpenAI Agents SDK, which it calls the production-ready evolution of Swarm.
AutoGen Swarm. Microsoft’s AutoGen uses the same name for “a team in which agents can hand off task to other agents based on their capabilities.” All agents in the team share the same message context.
Parallel sub-agent swarms. Moonshot AI’s Kimi Agent Swarm uses the term for a lead model that spawns sub-agents to work on parts of one task. Its launch post says Kimi K2.5 can deploy up to 100 sub-agents working in parallel. Its help center says Kimi K2.6, released April 20, 2026, raised that to up to 300.
In the first two, the shared thing is the conversation; in the third, the task. In none of them is it a balance, a quota or a customer record other agents are changing at the same moment. That is where production swarms get into trouble.
A swarm buys breadth and pays for it in tokens. One detailed public account is Anthropic’s How we built our multi-agent research system (June 13, 2025). The system uses “an orchestrator-worker pattern, where a lead agent coordinates the process while delegating to specialized subagents that operate in parallel.” On Anthropic’s internal research eval, a lead Claude Opus 4 with Claude Sonnet 4 subagents “outperformed single-agent Claude Opus 4 by 90.2%.”
The same post is just as direct about the cost: “agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.” It also names where the pattern breaks down: “some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today.”
That gives a first filter. A swarm pays off when the work splits into independent pieces that are worth the tokens. Once agents depend on each other’s state, the question changes from “is it worth it?” to “how is that state coordinated?”, which is the rest of this page.
The useful question about a swarm isn’t how many agents it runs. It’s whether two of them ever write the same thing inside the same short window.
Partitioned swarms. Each agent owns a slice of the work and the state that goes with it. A research swarm where each sub-agent reads different sources and writes its own notes is partitioned. So is a platform running thousands of agents that each draft a separate document for a separate customer. That’s a capacity problem, not a concurrency problem: no two agents race on the same row.
Contending swarms. Two or more agents read and write the same mutable state while the decision still matters. A shared outreach list where “already contacted” must hold across every agent. A team budget that several purchasing agents draw down. A rate limit on a downstream API that every agent consumes. A pool of tasks where each must be claimed exactly once.
Multi-tenant is not the same as contending. Many tenants each running agents on their own isolated state is partitioning with a platform badge on it. Read what the decision touches, not what the system looks like from outside.
Here is an illustrative scenario. The numbers are constructed, not measured.
An outbound swarm runs twelve agents. Each one picks an account, researches it, drafts an email and sends it. The rule is that no contact receives more than one email in seven days. Each agent checks a last_contacted_at field before sending. That field is updated by a sync job that copies send events from the email tool into the CRM every 60 seconds.
t = 0.0 s Agent 3 reads contact 4417: last_contacted_at = 12 days ago -> eligible
t = 0.4 s Agent 9 reads contact 4417: last_contacted_at = 12 days ago -> eligible
t = 7.8 s Agent 3 finishes drafting, sends email
t = 9.1 s Agent 9 finishes drafting, sends email
t = 60.0 s Sync job copies both send events; last_contacted_at = now
Both agents followed the rule. The contact got two emails nine seconds apart. Now notice what makes it worse with agents than with a batch job: the time between the check (t = 0.0) and the act (t = 7.8) is mostly the model drafting. That window is seconds wide, not microseconds, and it grows with the length of the reasoning. The same shape is known as agentic TOCTOU, time-of-check to time-of-use.
Making the sync job faster narrows the window but never closes it. Agent 9 read at t = 0.4, before Agent 3 had sent anything. No freshness can fix a read that happened before the other write. What fixes it is a claim: Agent 3 records “I’m contacting 4417” in the same step that checks eligibility, and Agent 9’s check sees that claim.
Some contended state already has a mature way to resolve conflicts. That state is not your problem.
Code has git. Two coding agents on separate branches are serialized by merge and review. Their conflicts surface as merge conflicts, which is the system working.
A single stored record has a row lock. If your agents update one row through an operational database, the database serializes them.
Unmergeable state has neither. Money, budgets, quotas, mandates, velocity counters, schema changes and deployed instances can’t be merged after the fact. Two refunds that each fit under a cap don’t merge into one refund; they sum past the cap. Two schema migrations don’t merge; they collide.
The litmus question for any swarm is: when two agents write this state at the same moment, what resolves the conflict today? If the answer is git, a row lock or another system’s own transaction, you’re covered. If the answer is “the pipeline usually keeps up,” you have a contending swarm on unmergeable state.
Ask what resolves a simultaneous write today. If nothing does, the swarm needs coordination at the write.
Frameworks give you ways to pass work between agents. Fewer give you ways to coordinate the state they share. These are the options, from weakest to strongest.
Only the top three steps act on the shared state. The bottom two coordinate the conversation.
Message passing coordinates agents. It does not coordinate state. A shared transcript tells Agent 9 that Agent 3 said it would contact 4417. Only a write that both agents’ checks read tells Agent 9 that the contact is taken.
| Pattern | How it works | What it guarantees |
|---|---|---|
| Handoffs only | One agent at a time holds the task, as in Swarm and AutoGen | No concurrency on the task; nothing about external state other agents touch |
| Shared transcript | All agents see the same message history | Agents know what others said, not what state is current |
| Claim with lease | Agent writes a claim row with an expiry before acting | One owner per task if claims are written atomically |
| Conditional write | Write succeeds only if a version column still matches what the agent read | Lost updates are detected; the loser re-reads and retries |
| Transaction | Check and write commit together under serializable isolation | Concurrent conflicting writes don’t both commit |
Large swarms add a second layer: something steers them. A controller watches the running fleet, derives signals such as spend so far, error rates and tool failures, then changes a policy, budget or route. Running agents act on the new policy while still running.
That loop has its own window: how long do agents keep acting on a policy that was just superseded? A revoked budget, a disabled tool or a rolled-back model route all cost money for every second the old value is still being read. The question to ask of any fleet: when you change a policy, how long do running agents keep acting on the old one, and what does that cost?
A contending swarm needs two things from the state it shares. Every agent needs to read the current version of it, raw and derived, under one consistent view. And writes that conflict need to be resolved when they are written, not reconciled afterward.
The Tacnode Context Lake™ holds the decision context for that loop: what each agent reads before it acts, and what it decided once it did. Every agent in the swarm reads the same shared context.
State the swarm owns. Claims, leases, per-agent spend limits, holds, coordination records and agent actions can live in Tacnode as the system of record. Here the check and the write run in one ACID transaction, so two agents claiming the same contact or drawing down the same budget at once are serialized: one commits, the other sees the conflict and retries.
State your systems own. CRM records, orders and account balances stay in the systems you run today and arrive by change data capture. For that data, Tacnode gives each agent’s check an internally coherent snapshot, with raw rows and derived counters computed against the same set of ingested events. It does not enforce anything inside a ledger it doesn’t hold.
Each agent’s output is written back and becomes context for the next agent’s check. That is the loop, and it’s why a velocity counter or a claim written by Agent 3 is what Agent 9 reads.
If your swarm is partitioned, none of this applies. A research swarm that only reads documents and writes its own notes needs a vector index and object storage, and pgvector on Postgres handles that well.
Former Meta and Microsoft. Built distributed query engines at petabyte scale. Author of the Composition Impossibility Theorem (arXiv:2601.17019).
Fresh Context Newsletter
The argument behind the posts — what breaks when AI acts on stale data, from the team building the Context Lake. About twice a month.
Book a demo and discover how Tacnode can power your AI-native applications.
Book a Demo