Choosing your mode

Warpforge gives you three ways to start work. Picking the right one is most of the difference between an agent that saves you an afternoon and one that burns your quota producing a diff you throw away.

You don’t have to guess which is which: the composer draws what pressing Start will actually do — a strip of blocks showing the shape of the run. For a workflow that’s the selected template’s real stages and round limit, not a stock illustration. For an orchestrator it’s explicitly an example, staffed from your own enabled harnesses, because the lead decides the split once it has read the prompt.

The short version:

Start with a single session

A regular task is one agent in one conversation. It still gets the runtime tools, memory, and create_task — so “single” is not “limited,” it’s undivided.

Reach for it when:

• The work is one coherent change, however large — a feature, a refactor, a bug hunt.
• You want to steer as it goes. A conversation you’re watching beats a pipeline you’re waiting on.
• You don’t yet know the shape of the problem. Exploration is a conversation, not a plan.

This is the right answer far more often than it feels like it should be. Delegation has real overhead: the lead has to describe the work well enough for an agent with none of its context to do it. For a change one agent could have made directly, that description costs more than it saves.

Use an orchestrator when the work genuinely splits

Enabling Orchestrator turns the agent into a lead with 11 extra tools: it can spawn_agent, follow up with message_agent, and drain results with read_inbox — while you keep talking to it.

Reach for it when at least one is true:

• The parts are independent. Three endpoints, three files, three services — work that won’t collide.
• Different pieces want different harnesses. This is the one thing nothing else does: a Claude Code lead can put a Codex sub-agent on one piece and an opencode sub-agent on another, in the same task, and reconcile their results.
• The task is bigger than one context window. The lead spends its context coordinating; each sub-agent gets a fresh one for its own slice.

Don’t reach for it when:

• The parts touch the same code. Parallel agents editing one file is a merge conflict you asked for.
• You could have described the whole thing to one agent in a sentence. If the delegation prompt is longer than the change, delegate nothing.

Use a workflow pipeline when review is the point

A pipeline runs fixed stages — plan? → implement → review ⇄ fix — and the daemon drives the transitions, not a manager model deciding what to do next. Each stage is its own agent session with its own model, and review rounds repeat until approval or a configured limit.

Reach for it when:

• You want a second opinion by construction. The reviewer is a different session — often a different model — that did not write the code and is told not to edit files.
• The work is repeatable. Pipelines are versioned YAML in .warpforge/workflows/, so the process travels with the repo instead of living in one person’s habits. Two ship with Warpforge; writing your own is a file, not a fork.
• The change is risky enough to be worth several times the cost. Which brings us to the tradeoff.

Two things a pipeline will never do: commit on its own — a finished pipeline lands in Needs review with its chats, timeline, and diff intact — or loop forever. When it exhausts its review rounds with findings open, it stops and asks.

Combining them

These aren’t exclusive. An orchestrator can spawn_workflow, so a lead handling a large feature can send the one risky piece through a full review pipeline while dispatching the routine parts as plain sub-agents.

That’s usually the shape of a big task done well: one lead, mostly single sub-agents, a pipeline where it matters.

A decision table

See also

• Agent tools (MCP) — exactly which tools each mode gets
• Orchestration and workflows — how delegation and pipelines work
• Tasks and backlog — where the work comes from in the first place