โ† Back to all guides

The patterns

MarkdownOpen in ClaudeOpen in ChatGPT

At the end, you know which built-in workflow to pick for a task, and what each one does in its own words.

At a glance

Time: 5 minutes to read.

Every built-in workflow is on the Workflows page, drawn as a track; Open in builder shows every step and route, and Simulate walks every route on a fake harness without spending anything. Most of them need no setup; two run a command your repository declares.

Two harnesses on one problem

Each model reads what the other missed. In these three, two agents on two harnesses work the same problem, and one answer comes out.

  • Parallel plans, then build. Two plans you can compare before any code is written. Two planners, one on Claude Code and one on Codex, plan the task on their own without seeing each other's work. A lead reads both and writes one PLAN.md: what they agreed, where they disagreed and which it chose. You edit and lock it, a builder builds it, and a reviewer sends changes back for up to two rounds before you decide on the draft pull request.
  • Pair programming. A second model watching every step. A driver on Claude Code and a navigator on Codex take turns on one worktree: small complete steps, each explained and handed over, the navigator naming what is wrong and what to do next.
  • Root cause, fix. A cause backed by two independent looks, before anyone touches the code. Two read-only investigators, one on each harness, look into the issue on their own and show their evidence. A lead writes one RCA.md from both and commits nothing. You choose: fix it now, or finish with the report. A fixer repairs the cause under review for up to two rounds, then you decide on the draft pull request.

The others

  • One agent. The simplest run. One step, Workspace access, the Assistant persona unless you pick another. For a task one person would do in one sitting.
  • Plan, build, review. A plan you approve and a reviewed change. A planner writes a plan, a builder builds it, a reviewer says approve or changes_requested, and a bounded loop sends changes back to the builder.
  • Architect, build, test. Behaviour proven by tests. An architect designs from the repository's evidence, a builder builds, a tester turns the task's requirements into tests and keeps their actual output.
  • Build, fix. A command, not a model, decides when it is done. A builder, then a Check that runs the command your repository declares, and a loop back to the builder while it fails. It needs a declared check; the composer offers to initialize one.
  • Per-module builders. A change across several packages at once. A planner splits the task into work items, one builder runs per item in its own worktree, and the branches merge before the next step.
  • Reviewer panel. More than one pair of eyes on a diff. Several read-only reviewers read the same diff in parallel, each from its own angle, and a lead folds them into one list.
  • Security audit. A report first, and fixes only where you choose. Cloudflare's security-audit skill on a small graph: an audit step, your choice of what to fix, a fixer, a verifier with the same skill for two rounds, your decision, a draft pull request. The report is the audit step's own message.
  • Adviser. Help when the worker is stuck. A worker with Workspace access and a read-only adviser it can ask; the adviser answers from the code in front of it with the smallest concrete next step.
  • Orchestrator, items. Work split and checked as one. A lead splits the task into work items, a builder runs per item, a reviewer verifies the merged result and a bounded loop repairs it.
  • Orchestrator, team. A lead who decides when the work is done. A planner first, then a team round of agents, then the lead verifies before it finishes or assigns another round.
  • Design, build, panel. Ticket to merge in one run. An architect and a read-only critic agree a design for up to five rounds, a fan out builds one work item per package, a lead integrates, and your repository's verify command runs as a check with a three-round repair loop. Seven read-only reviewers read the diff in parallel (one on a second model), a lead folds them into one list for a fixer for up to three rounds, and you approve the pull request before it opens. Needs verify declared.

Or say one

Describe the pattern in the composer, with Who on Auto. The copilot writes the workflow, draws it on the card and names what it could not build as you said under Left out. Open in builder keeps it among yours. The builder's own copilot changes it from words.

Agents without a workflow are on the Agents page: Planner, Investigator, Architect, Builder, Reviewer, Fixer, Tester, Scout, Driver, Navigator, Adviser, Lead and Assistant, each with a persona of at most sixty words, each a one-step workflow when you give it a task alone.

Try it

  1. On Workflows, open Plan, build, review and press Simulate.

    You should see: every route walked on the fake harness, the loop going round and ending at its exhaustion step, and no run created.

  2. On Tasks, pick it under Who and give it a task.

    You should see: three steps on the card, the reviewer's verdicts named on the route, and up to 2 rounds in the setup sentence.

  3. Pick Root cause, fix and give it a bug you know. When the cause is in, read RCA.md and choose Finish with the report.

    You should see: both investigators' replies, the lead's RCA.md with the evidence, and the run ending with no change to your code.

Next

Change a pattern, or draw your own: Build a workflow of your own.