Pipelines: reusable multi-step, multi-provider agent chains

[jappyjan]

Problem

Real work often needs several agents in sequence, each with a different job and often a different provider. For example: one model refines the requirements, another implements, a third coordinates review. Today I do this by hand: wait for one thread to finish, copy its final answer, open a new thread on another model, paste it in with the next instructions, and repeat. It is slow, easy to get wrong, and I can't leave it running.

delegate_task and Claude's Workflow tool chain agents inside one agent's turn. Neither is a reusable, user-defined sequence that I set up once and start from the composer.

Proposal: Pipelines

A pipeline is a saved, ordered list of agent steps. Each step has:

• a name
• a provider, model and options (e.g. effort)
• permissions (runtime mode)
• optional skills, added to the prompt as $skill mentions
• a prompt template with {{input}}, {{previous.output}} and {{steps.<id>.output}}
• an optional "pause before this step"

Using it:

• Define pipelines under Settings → Pipelines.
• Start one from a new thread by picking it in the composer (or the command palette), then type the prompt.
• The run gets a parent thread showing progress, with Continue / Retry / Skip / Cancel, plus one normal thread per step, nested under the parent in the sidebar.
• Each step starts with a clean context. You can open the active step's thread and steer it like any chat.

How it runs:

• A step counts as done when its run finished, its delegated subagents settled and nothing is queued. Its final answer then fills the next step's template.
• When a run is paused, you can keep chatting in the previous step's thread to refine its answer. Continue then uses that thread's latest answer.
• All steps share the first step's workspace (worktree/branch), so the implementer works where the planner looked.
• Runs survive server restarts.

Defaults and surfaces:

• A starter pipeline ships with the app: Feature delivery (Refine requirements → Implement → Prepare QA → QA → Review → Visual review guide).
• It's added once per server, so if you delete it, it stays deleted. It's also offered as a template in "New pipeline".
• Web, desktop and mobile. Agents get MCP tools to list, start, check, continue and cancel pipelines.

Design choices worth your input

• Server-side service, not an orchestration aggregate. Definitions and runs live in plain SQLite tables, like scheduled tasks. A runner drives steps through the existing ThreadLaunchService and waitForThread(untilDelegatedWorkSettled). Thread events only gain an optional server-set pipeline field on threads.
• No plan mode in pipelines. Each step's final answer is the handoff, which keeps the contract simple.
• The parent thread is runless and read-only. Messages to it are rejected server-side, and clients show the progress view instead of a composer.
• Naming. "Pipeline" avoids clashing with the existing provider-native "workflow" UI.

Status

I have a working implementation on my fork, used locally with real runs:
https://github.com/jappyjan/t3code/tree/feat/pipelines

It covers contracts, server, client-runtime, web/desktop, mobile, agent MCP tools, tests and user docs. It has had a multi-angle review pass and a browser QA pass. I'd like to know whether you're interested in this direction and scope before opening a PR. I'm happy to cut it down, e.g. web first and mobile/MCP later, or reshape any of the choices above.

Screenshots

These were taken with the dev Replay provider, so no real agents ran.

Settings → Pipelines, with the shipped starter

Step editor: model and effort, permissions, skills, prompt template

Picking a pipeline in the new-thread composer

With a pipeline selected, the model and attachment controls step aside

Run paused before a step (sidebar marks it as needing input)

Running: steps nested under the pipeline on the Working shelf

Completed run, next to the thread details panel

A step's own thread: normal chat, linked back to its pipeline

Dark mode

Short recording of a run

Related: #22852 (grouping delegated children into one lineage node).

[EtanHey]

Agents need MCP tools for this, not only the composer. We built a harness-agnostic version locally and ran it with Codex, Claude and Antigravity children. Findings:

1. A chain only runs in a harness with its own workflow tool, like Claude's Workflow. A Codex or Gemini lead drives delegate_task by hand, one turn per step.
2. The server should own the run. Ours was one blocking MCP call: a Codex exec cell yields after ~31 s, the turn ends, and the next delegate_task fails with "Delegated tasks require an active run".
3. Fixed step lists can't express "revise until the judge passes". A "repeat the previous N steps until done, max K" step would cover review loops.
4. Smallest useful piece: an optional result schema on delegate_task, so children return validated JSON. feat: T3-run workflows and reviewed task graphs for every provider #26673 needs one too.

Our ~420-line patch is available as a reference; no PR without direction approval.

[jappyjan]

Thanks, this matches what we hit.

1–2 are covered in this branch. The run is owned by a server-side runner: it survives restarts, and no lead turn has to stay alive. Agents also get list_pipelines, start_pipeline, pipeline_status, continue_pipeline and cancel_pipeline MCP tools, so a lead on any provider can start and drive a run without a workflow tool of its own.

3. Agreed, a bounded "repeat steps N..M until a check passes, max K" step would cover review loops. I kept v1 linear on purpose; it fits as a follow-up step type.

4. Structured results on delegate_task seem like their own proposal. Pipelines pass step output as text through templates today, so a schema could plug in later without changing this design.

[renezander030]

Since every step shares the first step's worktree, Retry on Implement starts from whatever the failed attempt left on disk, and Continue hands the next step a final answer that may not match the files that step actually wrote. I'd snapshot the worktree at each step boundary (a commit or stash ref kept on the run), so Retry resets to the state the step started from and the handoff can carry the diff, not only the summary.

The shape I use for agent patches, evaluated in a throwaway clone and landed only when checks pass: https://github.com/renezander030/pi-gate

[jappyjan]

Good catch, that was true. Fixed on the branch (71ee372, e6fa6eb).

• Each step keeps the snapshot its first attempt started from. It reuses the baseline checkpoint T3 already captures before a thread's first turn, so no extra git work runs at step boundaries.
• Retry now offers Retry from step start, which puts the worktree's files back to that snapshot, or Retry with current files.
• Before restoring, it saves the failed attempt's files under a ref, so nothing is lost. It waits for the old agent to stop first.
• Restore only runs in T3-managed worktrees, never the project's own checkout.
• Commits stay on the branch: it restores files, not history, the same way conversation rewind does.

Handing the next step a diff as well as the summary is a good idea for later.

[jappyjan]

Update: the branch now has a coordinator on top of each run, and feedback to earlier steps (16f1e54).

• Coordinator: a run's parent thread is now a chat with a coordinator agent that knows the run. It can check status, send feedback to steps, continue past a pause when you ask it to, rerun or cancel. It only acts when you message it and doesn't edit files itself. You can also open it beside any step's thread (header button, command palette, or a sheet on mobile).
• Feedback: instead of rerunning from scratch, you can send feedback to an earlier step, from the run page, on an assistant message or on selected text. That step fixes its work in its own thread and hands off again. Every later step gets a note about what changed and redoes its work against the new result. Agents can do the same through a revise_pipeline_step MCP tool.

Some background: I've built similar things before as software factories, most recently bobs-factory. This approach is turning out to be much more effective. Steps aren't tightly coupled to per-step tools, permissions or schema validation. Each step is a normal thread with a prompt, and so far it just works. There are still some MVP rough edges, the coordinator in particular, which I'm ironing out right now.