DEV Community: Kris Christopher

[Boost]

Kris Christopher — Mon, 12 Oct 2026 18:06:18 +0000

Kris Christopher

Oct 12

How I Coordinate Multiple AI Agent Swarms Across Vendors Without Letting Them Collide

#ai #architecture #devops #programming

8 min read

How I Coordinate Multiple AI Agent Swarms Across Vendors Without Letting Them Collide

Kris Christopher — Mon, 12 Oct 2026 14:20:53 +0000

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:

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

I Built an AI Layer for Claude Code with Persistent Memory, 88 Skills, and Codebase Intelligence

Kris Christopher — Sun, 11 Oct 2026 03:35:29 +0000

I've spent the last several months building an AI development system for my own software projects, and I've decided to release part of it as an open-source Claude Code plugin.

It's called Bootstrap AI Layer.

The project started because I kept running into the same limitations with AI-assisted software development.

Agents would lose important context between sessions. They'd repeatedly search code they'd already analyzed, sometimes make changes without understanding dependencies, and occasionally report that work was finished when the verification wasn't there to support it.

I wanted something more structured than another collection of prompts.

So I started building an engineering layer around the agents themselves.

What I built

AI Layer currently contains 88 skills and 25 agent definitions across three plugin packs, according to the published release inventory.

The system brings together several capabilities:

Persistent project memory: A local DuckDB database retains session history and project knowledge across restarts.
Codebase intelligence: A TypeScript language server provides symbol definitions, references, types, and dependency information without repeatedly reading entire files.
Retrieval-first workflows: Agents are instructed to check existing knowledge and code indexes before searching or researching the same information again.
Software engineering workflows: Skills covering requirements gathering, PRDs, research, implementation, documentation, testing, and CI/CD operations.
Specialized agents: Defined roles for architecture, engineering, QA, security, documentation, and other responsibilities.
Marketing automation: Optional skills for lead research, outreach, content generation, social media, and analytics.
Infrastructure automation: Optional K3s and GitLab CI runner management.

Some of the advanced workflows, including multi-agent work ownership, coordination, and full release orchestration, require a separate Brain Gateway that isn't included in this repository.

The local development and memory tools work without that Gateway.

How the memory system works

One of the more useful parts of the project is the local DuckDB brain.

Claude Code sessions can preserve conversation history and project information so future sessions can retrieve relevant context.

The TypeScript language-server integration complements that memory by helping agents navigate actual code symbols and their references.

This is important because having a large context window isn't the same as having useful context.

My approach has been to retrieve the specific information an agent needs rather than continuously feeding it entire files, old conversations, and unrelated project documentation.

Try it yourself

The public repository is MIT-licensed.

Repository: https://gitlab.com/kriscodes2-claude-plugins/ai-layer

Inside Claude Code, install the Core plugin using:

/plugin marketplace add https://gitlab.com/kriscodes2-claude-plugins/ai-layer.git
/plugin install ai-layer-core@kriscodes2-claude-plugins
/ai-layer:doctor --fix

Restart Claude Code, then initialize it inside your project:

/ai-layer:init

The installation requires Node.js 20 or newer. TypeScript code navigation also requires TypeScript in your project.

You can inspect the available skills using:

/ai-layer:help

The optional marketing and infrastructure packs can be installed separately.

What I've learned

One of the biggest lessons from building this has been that more capable models don't automatically produce more reliable engineering workflows.

The surrounding system matters.

How does an agent locate the correct code?

How does it know what previous sessions discovered?

How do multiple agents avoid changing the same files?

How do you distinguish a completed task from a task that has actually passed verification?

These are software engineering and coordination problems, not simply prompting problems.

I ended up spending a considerable amount of time on retrieval, state management, documentation, testing, and the boundaries between individual agents and shared infrastructure.

There's still plenty to improve, but the experience has reinforced my belief that AI-assisted development needs stronger engineering practices around the models.

Why I'm sharing it

I originally built this tooling for my own projects. It wasn't designed around selling subscriptions or acquiring customers.

Now I'd rather make the reusable components available to other engineers who might find them helpful.

The public release doesn't include the entire platform I developed, but the standalone tools, local memory implementation, MCP servers, and plugin packs are available to explore.

I'm particularly interested in feedback from developers working with Claude Code, MCP, TypeScript, or multi-agent systems.

If you're building similar tools, how are you handling persistent memory, codebase retrieval, and verification?

I'd be interested in comparing approaches, discussing architectural trade-offs, and reviewing contributions.

Source code: https://gitlab.com/kriscodes2-claude-plugins/ai-layer