Warpforge supports two complementary ways to coordinate agents.
The orchestrator agent
A regular Warpforge task is one conversation with one coding agent. Enable Orchestrator and that agent becomes a lead with tools for delegating:
spawn_agent— dispatch a bounded task to Claude Code, Codex, OpenCode, or any configured harness, and return immediately;message_agent— send a follow-up into an existing sub-agent’s session, in context;read_inbox— drain finished results and decide what happens next;list_agents,stop_agent,cleanup_agents— see, stop, and clear up its own children.
The distinctive part: sub-agents don’t have to be the same harness as the lead. A Claude Code orchestrator can put a Codex sub-agent on one piece and an opencode sub-agent on another, in the same task, and reconcile what comes back.
Orchestration stays inside a real conversation you can keep steering while child agents work. Sub-agents appear as normal Warpforge tasks linked to their parent, so you can see which harness is running, what it changed, and where human attention is needed instead of sending work into a black box.
See Agent tools for the full surface, and Choosing your mode for when delegation is worth its overhead.
Workflow pipelines
For repeatable work, choose one of the built-in Plan + implement + review loop or Implement + review loop workflows. The daemon — not a manager model — drives the fixed plan? → implement → review ⇄ fix sequence. Each stage is a visible child task with its own agent session, and each stage can use a different configured agent and model. Multiple reviewers can run in a review round, findings can point to exact lines, and repair rounds continue until approval or a configured limit.
Workflows pause at safe boundaries, survive a daemon restart, and stop for structured human input when an agent asks a question or the review limit is reached. A completed pipeline never commits automatically; it lands in Needs review with its chats, timeline, and diff available for inspection.
The two built-ins are a starting point, not the menu. Workflow definitions are versioned YAML files in .warpforge/workflows/, and any file you add there shows up in the picker for everyone who checks out the repository — a different agent per stage, several reviewers with different briefs, your own prompts. Built-ins can be copied into a project and edited in place, so the process travels with the code instead of living in one person’s UI settings.
See the workflow file reference for every key, the placeholders each stage can use, and a worked example.
Pipelines under an orchestrator
An orchestrator can dispatch a whole pipeline instead of a single sub-agent (spawn_workflow), and then drive it: pause_workflow holds it at the next stage boundary, resume_workflow continues with optional extra context, answer_workflow answers a stage’s question, and decide_workflow settles what happens when the review rounds run out with findings still open.
That combination is how a large task usually gets done well — one lead, mostly single sub-agents, and a full review pipeline on the one piece that warrants it.