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.
If the account a sub-agent would run on is out of quota, spawn_agent is refused with the reason, so the lead can pick another agent instead of starting one that fails on its first message.
See Agent tools for the full surface, and Choosing your mode for when delegation is worth its overhead.
Workflow pipelines
For repeatable work, start a task in Factory mode and choose a workflow template: one of the built-in Plan + implement + review loop, Implement + review loop or Implement + verify + review loop, or your own. Warpforge — not a manager model — drives the fixed plan? → implement → verify? → 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.
With a verify stage, an agent tests each change in the running app before any reviewer sees it: it starts the project’s dev services, walks through the flow the task describes in the in-app browser, checks the console, and takes screenshots. A failure goes back to the fix stage with the failed steps as findings, and the fix is tested again. Only a pass moves on to review, and the verdict, checklist and screenshots stay on the pipeline and in its final summary. A task in a background copy of the repository cannot be verified, because the dev services run from your project folder; with Where it runs set to Automatic, a Factory task that tests the running app runs in your project folder for you — see the verify reference.
Workflows pause at safe boundaries, survive a restart of the app, and stop for structured human input when an agent asks a question, the review limit is reached, or verification keeps failing. A pipeline also pauses before a stage whose agent account is out of quota, with a note in the timeline saying which account and when it resets. Press Resume once the limit resets — resuming checks again, and keeps the pipeline paused if the account is still exhausted. Nothing is started and no review round is used up while it waits.
A pipeline Warpforge paused on its own shows up in Needs you with the reason: an account out of quota, a stage whose agent quit, or a restart that caught a stage mid-turn. A pause you asked for stays out of that list, since you already know it is waiting.
Unless you ask for a pull request, a completed pipeline never commits: it lands in Needs review with its chats, timeline, and diff available for inspection. With Open a draft PR when done on, Warpforge commits the change on a fresh branch and opens a draft pull request instead — it never merges.
The 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 Factory mode’s template 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.
By default that pipeline is the orchestrator’s own child: it starts at once, commits nothing, and its outcome comes back to the orchestrator. Asked to ship the change, the orchestrator passes pull_request: true instead, and the pipeline runs as a Factory task like one you start from New Task: it waits for the project’s Factory limits, opens a draft pull request for you to review when it succeeds, and marks a linked backlog item done when you merge it. The orchestrator can pick the lead agent and model, where it runs, and a backlog item to work from; to start several backlog items at once it uses runner_enqueue — see the MCP tools reference.
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.
When quota blocks work
Warpforge holds back unattended work — automation runs, pipeline stages, and spawn_agent — only when it knows the account is exhausted. An account that is running low, or whose usage could not be checked, is never blocked. A task you create yourself is never blocked either: you are there to see the failure and switch accounts.