One AI coding agent is a tool. Several of them working the same codebase in parallel is an operations problem, and it's a layer almost nobody writes about.
I'm Fran, solo founder of Olivares AI. The platform was built almost entirely with Claude Code — parallel sessions in git worktrees, each on its own branch with its own job — and, once it existed, coordinated and governed by earlier versions of itself. Full disclosure, per DEV's guidelines: this post is about my own product, and the product is AI-assisted all the way down. What follows is what broke on the way from one session to a fleet, and what I ended up building because of it.
What breaks first: hand-offs
The naive fleet is a pile of tmux windows. Session A finishes a refactor and writes "next: update the callers" into a markdown file; session B is supposed to notice. Sometimes it does. Sometimes two sessions notice, and you get the same migration written twice on two branches. Sometimes nobody notices and the note rots. And when the box restarts, whatever coordination state lived in those files and windows is gone.
The fix that survived contact was a durable work plane: work items in a queue, with fenced leases. An agent claims an item and holds a lease on it. Two agents can never hold the same item. If a lease expires and the item is handed to someone else, the original holder's late writes are fenced off — rejected, not silently merged. The queue outlives restarts, so "the fleet's state" stops meaning "whatever tmux remembers."
The part that mattered more than I expected: the work plane is vendor-neutral. Claude Code has the deepest integration, but Codex, Gemini CLI, goose and cline plug into the same queue, and local models come in through Ollama. One queue, mixed fleet. An expensive frontier model finishes a design; a cheaper local one picks up the mechanical follow-up. The hand-off is the same fenced item either way.
What breaks second: who gets what
With one session you pick the model at launch and that's the end of it. With a fleet, launch flags are how control quietly dies. An override you set for one special task gets copy-pasted into the next launch, then into the template, and days later every session inherits a decision nobody remembers making. Effort levels drift the same way. So does tool access.
So control moved off the launch command and into the platform: per-subject model access (which agents may use which model families), managed settings pushed centrally to each session — model, effort level, tools — and budget rules that bind at a governed proxy sitting in front of inference. Policies are Cedar, evaluated per tool call.
The lesson under all of that: policy has to bind at a choke point the agent cannot opt out of. A settings file is a suggestion — an agent can be launched around it. A proxy in front of inference is a fact. Traffic either goes through it or it doesn't go.
What breaks third: knowing what actually happened
Coding agents don't just edit code. They touch identity systems, storage, CI, the SIEM — real infrastructure, with real credentials. The platform puts those connectors under one policy set, and then does the thing I now think is the whole point: it draws the access map as permitted vs observed. What an agent could reach, next to what it actually reached. Unused grants show up (you gave it storage access weeks ago and it never used it — why is the grant still there?). Unexpected accesses show up too, and that's the row you read first.
One honesty rule I hold myself to here, because this category tends to oversell: the Ollama connector is read-only by design. The platform observes Ollama; it does not reach inside it. Enforcement binds at the governed proxy in front of inference. Where you can't enforce, observe — and say which of the two you're doing. An access map that blurs that line is marketing, not operations.
The facilities you'd otherwise build
Around those three layers sit the things every fleet operator ends up hand-rolling. A web console embedded in the binary: sessions, queues, audit, the access map. A hash-chained, Ed25519-signed audit ledger with SIEM export, because agents write history faster than you read it and the record has to be tamper-evident. Hook-level, deny-closed enforcement for Claude Code: a PreToolUse hook rules on each tool call before it runs, and "couldn't evaluate" means "no", not "go ahead". And a full CLI for everything the console shows.
Ops, deliberately boring
One Go binary. SQLite for a laptop, Postgres for a team. Runs fully air-gapped, which matters if your agents touch systems that must not leak. AGPL — and the community edition is the whole platform, not a teaser: the work plane, the policy engine, the console, the ledger, all of it self-hosted.
The recursive part
The strangest property of this project is that it governs the sessions that build it. New work on the platform runs as Claude Code sessions in worktrees, picking items off the platform's own queue, under the platform's own policies, writing into its own signed ledger. Earlier versions supervise the construction of later ones. That loop is also the most honest test bench I have: an agent will find the gap in your lease semantics by losing work into it.
Repo: https://github.com/olivaresai/olivares
Release write-up: https://olivares.ai/blog/olivares-ai-v26-8-0
If you're running more than a couple of agent sessions today — how do you hand work between them, and what's the failure your current setup doesn't catch?
Top comments (0)