Introducing Leaf: A Multi-Agent Coding Orchestrator

The agentic SDLC is moving in a thousand directions at once. The thing I’ve been building sits in one of them, and it doesn’t have a settled name yet. I call it Leaf.

The most accurate generic name is a multi-agent coding orchestrator. Three other terms each describe one side of it:

• What it does: it’s a coding-agent orchestrator, or fleet manager. Leaf doesn’t write code. It runs other agent harnesses (Claude Code, Codex, OpenCode, Antigravity) in parallel and coordinates them. Because it sits one level above those harnesses, “meta-harness” also fits.
• How it’s built: it’s an orchestrator–worker system, also called the hierarchical or supervisor pattern. A foreman agent is the orchestrator and pods are the workers. A supervisor process called Factory decides where pods run and manages their lifecycle. GitHub is the outside check on whether work is finished. This is the vocabulary the research uses, for example MAST (Why Do Multi-Agent LLM Systems Fail?)[https://arxiv.org/abs/2503.13657] and Google’s work on scaling agent systems.
• What it’s for: it’s a software factory. When no person drives it, it’s a “lights-out” or “dark” factory: a system that turns a backlog into merged pull requests on its own.

Most tools called agent orchestrators run parallel agents for a person who is watching. Leaf differs in three ways:

1. It plans the work as a graph.
2. It treats a merged pull request on GitHub as the only proof a job is done.
3. Nobody needs to watch it.

The Skill

The human part is a conversation. /leaf is a skill file, so it runs in any harness that loads skills. You describe a problem or an idea, and it works with you to produce one of three things:

• A bug (type:bug): one defect, one short issue with four sections: Observed, Expected, Reproduce and an optional Done when. If you don’t have a way to reproduce it, the skill finds one before filing.

• A PRD (type:prd): the full document, with each user story filed as a sub-issue (type:story). The format follows existing standards: problem before solution (Atlassian and Square templates), goals and non-goals (Google design docs), RFC 2119 MUST/SHOULD/MAY requirements, Connextra user stories sized by INVEST, Given/When/Then acceptance scenarios, and Spec Kit’s [NEEDS CLARIFICATION] markers.

  Real dependencies between stories become GitHub “blocked by” links, not prose.

• A plan, directly, when the requirement is already settled. It can come from issues or from a document on disk.

A question you can’t answer yet becomes a [NEEDS CLARIFICATION] marker, never a guess. The marker blocks the PRD from passing a check, which is the point: it records a decision nobody has made.

The GitHub Integration

GitHub is both the input and the finish line. Leaf acts on GitHub as a GitHub App, LeafBot, never as a person. Hosts and pods borrow tokens scoped to one repo.

Two comments drive it:

• /factory-check: a planner agent reads the issue against a written standard (eight points for a PRD, four for a bug). It replies with Ready. or Not ready. and a ✅/❌ checklist, and labels the issue factory:ready or factory:needs-detail.
• /factory-auto: the same check. If it passes, Leaf plans the work, approves the plan, runs it, labels the issue factory:running and comments with the full graph. The comment counts as the approval.

The comment reaches Leaf as a signed webhook through Tailscale Funnel. The work lands as one pull request that says Closes #<n>.

Decomposing the Plan

A plan is a graph of small nodes. Each node has:

• intent: what must be true, concrete enough to be wrong
• files: the paths it may write; this is what makes parallel work safe
• done_when: a check anyone can run without asking
• deps, plus an optional model and effort

Nodes are sized at 20 minutes to an hour of an engineer’s time. The graph’s first wave is every node with no dependencies, and that is how many agents start at once.

When a plan is saved, Leaf does two kinds of checking:

• Faults block the save:
  • two nodes writing the same file with no order between them
  • a model that doesn’t exist
  • an invalid effort level
  • a malformed node id
• Warnings go on the card for the approver to read:
  • a cheap model under a node other nodes depend on
  • a wave wider than the fleet
  • a file path that isn’t in the repo

The Leaf UI

A dashboard with four tabs:

Board

The main view. Plan cards with their graphs, approve and run buttons, the live room log, the fleet’s free slots, the usage budget, and a flag on any plan with no progress for an hour.

Discussions

Roundtables and panels. These are multi-agent conversations that produce a written page instead of code.

Statistics

Per-model history: how often a node landed on the first try, turns, time taken, and where a foreman escalated a node to a stronger model.

Trajectories

One run’s timeline, and each pod’s complete record: every byte its harness produced, plus the harness’s own session store.

The Agents

The model name on a node picks the harness:

Harness	Model	Billing
Claude Code	opus, sonnet, haiku	Claude subscription
Codex CLI	codex/gpt-5.6-sol, codex/gpt-5.6-luna	ChatGPT subscription
Antigravity (agy)	antigravity/gemini-3.6-flash-* and others	Google AI Pro subscription
OpenCode	local/qwen3.6-35b-a3b (llama-swap on a local GPU)	own hardware
OpenCode	DeepSeek V4.1 Flash and GLM 5.3 via OpenRouter	per token

The defaults are Opus for the foreman and planner, and Codex gpt-5.6-sol for workers. Every model is ranked on a 1–5 scale by how much reasoning the work needs, not by price. The planner assigns each node the lowest rank that can do it.

The Workflow

1. Write an issue with /leaf.
2. Comment /factory-auto.
3. A planner pod checks the issue and saves a plan.
4. Leaf approves the plan and starts a foreman on branch factory/<plan>.
5. The foreman spawns workers. Each is a container on any host in the fleet, with its own git worktree and branch.
6. Each worker commits and pushes one node, then reports done with its commit SHA.
7. The foreman fetches that commit, checks it, merges it into the plan branch, pushes, and retires the worker.
8. When every node has landed, the foreman opens one PR and turns on auto-merge. The repo’s own CI is the gate.
9. Leaf marks the plan done only when GitHub says the PR merged. Then it cleans up the pods, worktrees and branches.

Along the way, Factory sends the foreman a status update every two minutes: pods that have gone silent, pods stuck in a long turn, provider outages, and budget pressure. A foreman that dies is replaced and gets a summary of the room so far, not a replay of it.

The Nuance: Where It Falls Short

A system like this is only as useful as what it can’t do. Here’s what Leaf doesn’t handle yet, and probably won’t for a while.

Choosing the work. Leaf runs plans; it doesn’t pick what to work on. The backlog still needs a human eye. I have thoughts about how local models could score and triage issues, but that lives in Factory, not Leaf.

Acting on budget. Quota information reaches the foreman, but nothing enforces it. Codex exposes no quota information at all. Past their subscription limits, the Google and ChatGPT accounts start billing metered usage. I’ve seen this happen.

Keeping repos in sync across the fleet. A host that hasn’t cloned a repo refuses the work. This is mostly fine for my two hosts. It wouldn’t scale without some kind of fleet-level sync.

Editing prompts from the UI. If I want to tweak a system prompt or a skill, I edit the file on disk. There’s no in-dashboard editor.

So What?

Leaf is pre-pre-pre-beta. I might drop this idea for a new one next Tuesday. But this feels like it’s moving in the right direction.

It doesn’t try to replace your IDE. It doesn’t try to be a product. It’s a system that plans work as a graph, runs it across whatever harnesses you trust, and proves completion with a merged pull request. It uses your harness as-is. Skills. Contex. Whatever is in your repo. The rest is details.

I’ve already written about the hybrid AI setup that feeds it and the multi-host orchestration that powers it. This post is the glue that ties those pieces together.

Once it reaches a level of completeness I’m happy with, I plan to open source it. Until then, it runs on my hosts and does what I need it to do.