Multi-Agent Code Pipeline (Claude + Codex)

A working multi-agent setup where a supervisor agent plans and reviews, and developer agents implement and test on isolated machines. It turns a chat request into:

plan → implement on a sandboxed node → open a merge request → review → merge

…with a human gate before anything ships. Built on the OpenClaw engine — this repo is the glue (the MCP bridge, config templates, and docs), published clean-room with no secrets.

---

What it is

Splitting agent roles beats one agent doing everything (context limits, blast radius):

• Supervisor (Claude) — owns the conversation (e.g. Telegram), decomposes the task, reviews diffs, and gates merges. Its raw shell is locked down; it acts only through vetted tools.
• Developer nodes (Claude or Codex) — throwaway VMs where an agent edits code and runs builds/tests with elevated permissions, isolated from everything else.
• Bridge (MCP) — a ~80-line server exposing one tool, dev_on_node, that runs a task on a node over SSH and streams the result back.
• Orchestration — nodes are cloned / started / destroyed via the Proxmox API.

How it works

      Telegram / chat
            │
      ┌─────▼───────────────┐     MCP: dev_on_node     ┌────────────────────┐
      │  Supervisor (Claude)│ ───────────────────────▶ │  Bridge (server.mjs)│
      │  plan · review ·    │                          └─────────┬──────────┘
      │  MERGE gate         │                                    │ ssh -i key
      └─────────────────────┘                                    ▼
                                              ┌──────────────────────────────┐
        Proxmox API (clone/start/stop nodes)  │  Developer node (Claude/Codex)│
                     ▲────────────────────────│  edit code · tests · open MR  │
                                              └──────────────────────────────┘

The supervisor never touches the codebase directly — it delegates. Each node is disposable, so a bad run costs a rebuild, not your infra. See docs/architecture.md for the task/node lifecycle and threat model.

What it's for

Running real code-change workflows end to end without babysitting every step:

• Feature / fix delivery — supervisor decomposes, a node implements on a branch, opens an MR that Closes #N, supervisor reviews the diff and merges.
• Automated review — a second agent (different model/lens) reviews the first agent's output before it ships.
• Fan-out — several nodes work different tasks in parallel; the supervisor keeps the plan and the gates.

Quick start

cd bridge && npm install
cp ../.env.example ../.env       # set your node's SSH host/port/key
# register bridge/server.mjs as an MCP server in the supervisor config
# (see config/openclaw.example.json -> mcpServers)

The supervisor then calls dev_on_node({ prompt, dir, engine }); the bridge SSHes to the node, runs the chosen agent CLI (claude or codex), and returns its output.

Security

• No secrets in git — .env, openclaw.json, and any keys are ignored; only *.example templates are committed.
• Locked-down supervisor — raw shell denied; only vetted MCP tools.
• Isolated nodes — disposable VMs, least-privilege SSH key per node.
• Human gates — PLAN and MERGE keep a person in the loop.

Repo layout

Path	What
bridge/server.mjs	MCP dev_on_node bridge (supervisor → node over SSH)
config/openclaw.example.json	Supervisor config template (provider, channel, permissions, MCP)
.env.example	Bridge env (node host/port/key, dev CLI)
docs/architecture.md	Roles, task & node lifecycle, mermaid diagram, threat model

License

MIT — see LICENSE.