Multi-agent orchestration: one agent as a kernel, and a bus for agents that talk
I build multi-agent systems the way operating systems handle processes. Agent-0 turns one Claude Code session into a kernel with a /proc state directory, syscalls and commands to spawn, message, collect and kill Claude, Codex and OpenCode workers. A neural bus lets agents running in terminal panes message each other, tracks who owes whom a reply, and nudges a stalled agent exactly once. I build environments that test agents working together.
Running several agents at once is easy. Getting them to divide work, report back and not stall waiting on each other is the hard part, and most of it is plumbing.
Agent-0: a Claude Code plugin that runs Codex workers from a kernel
A Claude Code plugin that treats workers like processes:
- Commands to boot, spawn, send, broadcast, collect, drain, replan, kill, and show status or a dashboard.
- A
/procdirectory holding each worker's state, so the orchestrator reads facts from files instead of remembering them. - Syscalls through which workers ask the kernel for things, polled and checked before a worker is marked finished.
- Planner and synthesiser agents: one breaks the goal into work for Claude, Codex or OpenCode workers in tmux panes, and the other merges what comes back.
- A strict first boot: until its tools are provisioned, worker spawning is refused rather than improvised.
A neural bus for agents that talk
Agents running in terminal panes under herdr can message each other through a daemon backed by SQLite:
- It tracks obligations: who owes whom a reply.
- It nudges once: when an agent settles without replying, the daemon prompts it exactly once, then leaves it alone.
- It uses only stock plugin hooks and lifecycle events, so it installs with the multiplexer's own installer and needs no patched build.
- Its behaviour is written down as a contract and covered by tests.
I used these relays for real multi-agent builds, with one agent writing briefs that others built from.
Where it started: an open-ended agent sandbox
My first multi-agent project, in April 2025, gave identical agents a shared world and no objectives. Each had the same tools (search and code execution), and they had to discover work, broadcast tasks, claim and delegate them, then review and vote on solutions among themselves. It showed early how much coordination depends on the plumbing around the agents.
What you can buy
Environments that test agents working together, built to your spec: tasks that need delegation and hand-back, graders that read who did what and whether replies arrived, and harnesses that run Claude, Codex and OpenCode workers side by side.
FAQ
What is multi-agent orchestration?
Coordinating several AI agents on one goal: splitting the work, dispatching it, collecting results and handling agents that stall or fail.
How do agents communicate with each other here?
Through a message bus. Each agent runs in its own terminal pane, messages go through a local daemon, and the daemon tracks pending replies and nudges an agent that has gone quiet.
Why model orchestration on an operating system?
Because the problems match: scheduling, process state, inter-process messages and cleanup. Keeping state in files, like /proc, means the orchestrator can always re-read the truth instead of relying on its own memory.
License it, or have me build an environment in the same style.