How I Coordinate Multiple AI Agent Swarms Across Vendors Without Letting Them Collide
Running Claude, Codex, Kimi, Grok, and local models simultaneously is a distributed-systems problem, not a prompt-engineering problem.
I'm Kris Christopher, creator of Koinessa, a project exploring Evidence-Gated Agentic Development.
I've spent much of 2026 working on a problem that becomes increasingly difficult as AI coding agents improve:
How do you coordinate multiple independent swarms, running on different vendors, across different machines, against the same codebase, simultaneously?
Not just multiple subagents inside Claude Code.
I'm talking about Claude, Codex, Kimi, Grok, and local Ollama models all doing useful work, potentially under different human operators, without duplicating tasks, overwriting each other's changes, or losing what they've learned.
And what happens when one crashes, another loses its context, and a third finishes work that has already been reassigned?
My conclusion is that we're approaching this problem from the wrong direction when we try to solve everything inside the agent harness.
The problem isn't agent intelligence. It's coordination.
Imagine running four independent coding swarms against one repository.
- Claude is modifying the authentication service.
- Codex is implementing the frontend.
- Kimi is developing tests and documentation.
- Grok is investigating security and architectural issues.
Meanwhile, a local model is summarizing CI failures and retrieving knowledge from previous development sessions.
Each swarm has its own context, tools, model-specific capabilities, and understanding of the repository.
Individually, they might be excellent.
Collectively, they have some serious problems.
Who owns which files?
How does Codex know that Claude just changed an interface it depends on?
How does Kimi learn that a previous agent already investigated and rejected a particular implementation?
What prevents two swarms from claiming the same task?
And most importantly, who decides that the combined work is actually correct?
Passing messages between agents addresses only part of the problem.
What we need is persistent, vendor-independent coordination.
Treat agent swarms like distributed workers
One of the most useful lessons from distributed systems is that independent workers cannot rely on one another's internal state.
Services crash. Networks fail. Requests time out. Messages arrive late. Workers repeat operations.
AI agents inherit all of those failure modes.
In Koinessa, I've applied familiar distributed-systems primitives to agent coordination:
- Session registration: Every participating agent has an identity and an active session.
- Heartbeats: The system tracks whether a session is still alive.
- File claims: Agents announce which files they intend to modify.
- Work leases: Ownership of a task is time-bound rather than permanent.
- Fencing tokens: Stale workers can be rejected after ownership changes.
- Durable messaging: Important messages survive session restarts and can require acknowledgment.
- Checkpoints and handoffs: Another vendor's agent can resume work without inheriting the original conversation.
- Shared operational memory: Verified decisions, previous failures, and completed work remain available to future sessions.
These aren't new inventions. They're established engineering techniques applied to an environment where the workers happen to be language models.
Why fencing tokens matter
Consider this failure:
Claude claims a task under lease number 41.
Its session stalls.
The lease expires, and Codex receives a new lease numbered 42. Codex completes the work and records the result.
Then Claude wakes up.
Claude still believes it owns the task and tries to submit its outdated result.
Without fencing, the stale worker could overwrite the newer result.
With fencing, the protected operation rejects token 41 because token 42 has superseded it.
That's the distinction between merely tracking ownership and enforcing ownership.
There's an important limitation here: cooperative file claims do not magically prevent arbitrary filesystem writes. Isolation, protected integration operations, and permission boundaries still matter. The coordination system can enforce authority at the resources it actually controls.
Separate agent memory from organizational memory
Most agent frameworks store operational context inside individual sessions.
That creates a fundamental limitation.
When a context window fills, a conversation is compacted, or an agent session terminates, critical details may become unavailable to the next worker.
And another vendor cannot necessarily consume that original session history.
My approach is to separate two things:
The model's working memory contains the information necessary to perform its current task.
The organization's memory contains persistent requirements, decisions, source-code intelligence, work ownership, verified evidence, and operational history.
Koinessa uses a federated DuckDB-backed knowledge store behind a controlled gateway.
It includes structured facts, historical decisions, code-symbol indexing, hybrid retrieval, and provenance.
When an agent starts a new task, a Context Compiler assembles a bounded packet containing relevant authoritative information.
That packet can include:
- The approved requirement and acceptance criteria.
- Relevant source symbols and exact file locations.
- Current Git state and outstanding changes.
- Existing file claims and task ownership.
- Previous decisions and verified fixes.
- The latest checkpoint from another agent.
- Required verification and applicable policies.
Now the agent doesn't need the entire project transcript.
It needs the specific information required for its assigned work.
And if the vendor changes, the organizational memory doesn't have to change with it.
The model session becomes disposable. The operational knowledge survives.
One coordination plane, multiple independent swarms
This is the architectural distinction I think matters most.
Instead of putting a supervisor agent above every other agent, put a deterministic coordination plane underneath them.
Conceptually:
Human operators
|
Shared work-item board
|
Coordination and authority
/ | | \
Claude Codex Kimi Grok
swarm swarm swarm swarm
\ | | /
Shared context and memory
|
Independent verification
|
Controlled integration
Each vendor retains its own strengths and agent harness.
The coordination plane owns the shared operational contracts.
That means multiple swarms can operate concurrently without requiring their vendors to understand each other's proprietary session formats.
For example, a task record might conceptually contain:
task: AUTH-42
owner: codex-session-18
lease_fence: 42
scope:
- src/auth/token.ts
required_checks:
- unit-tests
- typecheck
- security-scan
allowed_actions:
- edit
- test
- propose-change
status: implementing
This is illustrative YAML, not a published Koinessa API schema.
The crucial point is that task authority and required evidence are machine-readable state, not just instructions buried in a prompt.
Another agent can inspect that state, determine what is already owned, and select work that doesn't conflict.
What happens when an agent disappears?
Let's say Kimi is halfway through implementing a feature when its session terminates.
In a conventional chat-centered workflow, the replacement agent may need to reconstruct everything from the transcript.
In a durable coordination system, the successor can retrieve the work item's checkpoint:
- What was completed?
- Which files changed?
- Which requirements remain?
- What verification has already run?
- What was the last known blocker?
- Which lease is currently valid?
A Claude or Codex session can then continue from the recorded state.
The successor doesn't need to impersonate the original agent or replay its entire conversation.
It needs a valid authorization, current repository state, and an authoritative checkpoint.
This also allows inference capacity to be scheduled independently of logical work ownership.
A task might require several short sessions across multiple models, rather than holding one expensive provider session open while local tests execute.
Coordination without verification isn't enough
There's a second problem.
Suppose all four swarms successfully coordinate their work.
No file conflicts. No duplicate tasks. Every agent reports success.
Does that mean the software is ready to ship?
Absolutely not.
This is why Koinessa combines multi-vendor coordination with a methodology I call Evidence-Gated Agentic Development (EGAD).
An agent's claim that its work is complete is not the same as independent evidence that its work is acceptable.
The development loop is:
Observe → Recall → Plan → Claim → Compile Context → Execute → Verify → Approve → Ship/Observe → Learn
Verification operates separately from generation.
The system can require deterministic tests, static analysis, security checks, provenance, and approval policies before a change is accepted.
It also distinguishes between meaningful result states.
A missing scanner is not a successful scan. An infrastructure failure is not a code failure. A test being skipped is not necessarily a pass.
And an agent that discovers contradictory or impossible requirements needs a legitimate way to abstain rather than fabricate completion.
Just as importantly, the agent repairing a failure shouldn't be allowed to redefine success by deleting tests or weakening required checks.
The worker that produces the change should not control the rules that determine whether the change is accepted.
What I've actually tested
I want to distinguish operational evidence from architectural goals.
Koinessa is a founder-operated, pre-release system, not an independently audited multi-agent benchmark.
In the August 23, 2026 white-paper snapshot, the coordination plane recorded:
- 1,733 file claims.
- Eight recorded swarms.
- Interactive coordination across Kimi, Claude, Grok, Codex, local Ollama, and Ollama Cloud.
- Two human operators using separate machines on the same local network, directing independent agent swarms against a shared repository.
One documented August 12 workflow scanned the existing work board, used two parallel exploration agents, had a local 27B model help draft requirements, ran two coding agents on separate workstreams, and independently verified the result with 11,271 passing tests.
That is an internal operating receipt, not proof that every combination of vendors behaves identically or that collisions are impossible.
There's also an important distinction between interactive coordination and fully automated orchestration.
The interactive coordination plane is operational. The unified managed-provider launcher has implemented descriptors and transports, but remains gated pending provider-specific validation. Autonomous operation is similarly constrained by explicit operator controls.
I'm deliberately keeping those boundaries visible rather than claiming everything is fully autonomous.
You don't need Koinessa to apply these ideas
The architectural principles aren't dependent on my implementation.
If you're developing your own multi-agent orchestration system, I would start with a few simple rules:
First, establish authoritative shared state. Don't make a model's conversation the source of truth for task ownership or completion.
Second, make tasks independently claimable. Record identity, scope, dependencies, expiry, and ownership. Use fencing where stale actions must be rejected.
Third, persist handoffs. A successor agent should receive a checkpoint, not an archaeological expedition through chat history.
Fourth, separate coordination from inference. Vendor-specific adapters should connect to common contracts rather than forcing every model into the same proprietary harness.
Fifth, verify independently. Let agents generate candidates. Let tests, policy, evidence, and accountable humans determine what is accepted.
And start small. A shared task board, durable state, and enforced integration boundaries are more useful than a massive swarm with no reliable coordination.
Where I think agentic development is heading
I don't think the future of agentic engineering belongs exclusively to one model provider.
Different models have different capabilities, economics, context limits, tool integrations, and operational constraints.
Those differences can be useful.
A local model might classify CI failures. A frontier model might investigate a difficult architectural change. Another vendor's agent might independently review the result.
They should be able to contribute to the same initiative without requiring the entire organization to live inside one provider's context window.
The missing layer isn't necessarily a smarter agent.
It's the infrastructure that allows independent agents to cooperate without sacrificing ownership, traceability, or control.
That's the problem I've been exploring with Koinessa.
I've published the architecture and the engineering lineage in two documents:
- Evidence-Gated Agentic Development: The Koinessa Brain
- From Distributed Systems to Evidence-Gated Agentic Development
I'm interested in how others are approaching this problem.
If you're already running multiple independent agent swarms — especially across vendors — how are you handling task ownership, stale workers, shared memory, and verification?
Are you using a central orchestrator, distributed coordination, Git-based ownership, or something entirely different?
I'd be interested in comparing approaches and learning what has actually worked.
Kris Christopher — Creator of Koinessa
koinessa.com
Top comments (0)