Phase designer

A phase design is your pipeline · an ordered set of phases an agent runs, each one a system prompt plus its model, thinking budget, allowed tools and execution settings. This is where you author designs, version them, test them, and pin one version live.

10 min readUpdated 2026-08-12 · Priya NEdit this page

#Designs, versions, and phases

Three things nest, and it pays to keep them straight:

A design is a named pipeline. A workspace owns as many as it likes · a Docs pipeline, a Security pipeline, a Starter SWE pipeline.
A design has versions. Exactly one version is pinned (live); agents always run the pinned version, so editing never disturbs what is running.
A version is an ordered set of phases. A phase is one inline system prompt plus its configuration.

#Create a design

A new design starts one of three ways:

Pick a starting point

Template · start from a preset pipeline. Five ship: SWE (refine → plan → deliver → review → compound), Docs (scope → draft → publish), Review only (read → critique, comment-only), Security audit (intake → assess → remediate), and Research (investigate → synthesize → recommend).
Duplicate · copy the live phases of an existing design and adjust.
Blank · no phases; build from scratch.

Name it

Give the design a name and an optional one-line description. A whole design can be deleted later, but only once no version of it is live · make it a draft first, so a running agent is never left without its pipeline.

#Build the pipeline

Inside a design you shape the list of phases:

Add, rename, reorder and delete phases.
Give each phase an icon and colour so the flow reads at a glance.
By default phases run top to bottom. To branch, loop, run phases in parallel, or start a phase from an external event, use the flow graph.

#Configure a phase

Open a phase to edit everything it does:

#System prompt

The instructions for this phase, written in the prompt editor. This is the phase · there are no built-in or reusable skills, so what you write is what the agent does. Insert runtime variables at the caret, resolved from the run’s context:

{issueRef} · {issueName} · {issueType} · {issueBody} · {author} · {repo} · {baseBranch}

#Model

The foundation model that executes the phase, chosen from the Model select. Two families are offered; the select always shows the current list.

Family	Examples	Reach for
Anthropic Claude	`claude-sonnet-5` (default) · `claude-haiku-4-5` · `claude-opus-4-8`	The default balance; haiku for cheap/fast phases; opus for heavy reasoning
OpenAI	`gpt-5.6-terra` · `gpt-5.6-luna` · `gpt-5.3-codex`	An OpenAI alternative, including a coding-tuned option

#Reasoning effort

How much thinking budget the model spends on this phase · a per-phase knob the runtimes honour. Six levels:

low · medium · high (default) · xhigh · max · ultracode (the code-tuned ceiling)

Turn it up for a hard planning or review phase; keep it low for a mechanical one.

#Allowed tools

What the phase is permitted to do. The runtime enforces this list · if the prompt asks for a tool you did not allow, the model refuses rather than doing it anyway. Seven toggles:

Tool	Lets the phase
Read repository	Read the code (on by default)
Write to branch	Push commits to the agent’s branch
Run shell	Run commands in a sandboxed shell
Open & manage PRs	Open and update pull requests
Post comments	Comment on issues and pull requests
Install packages	Install dependencies
Outbound network	Reach the network beyond the repo

Grant the least a phase needs · a review phase rarely needs to write a branch.

#Notes

A free-text note on the phase, for whoever edits the design next.

#Advanced settings

Each phase has an Advanced disclosure for execution control. Every value here has a hard range, enforced by both the editor and the backend:

Setting	What it does	Range	Default
Timeout	Seconds before the phase is abandoned	1 – 86,400	600
Max retries	Automatic retries on failure	0 – 20	2
Repeat · max iterations	Run the phase up to N times in a loop	1 – 50	1
On failure	`Retry` to the limit then halt · `Skip phase` (mark failed, continue) · `Halt run`	choice	Retry
Gate directives	The phase will not start until every named directive is satisfied upstream or by a human	text list	none
Worktree · Sidecar · Terminal	Give the phase a checkout, a cache/vector sidecar, or an interactive sandboxed shell	toggles	off
Priority bias	On a conflict, favour the phase prompt, the issue instructions, or neither	choice	Neutral

#Version and pin

You always edit a working draft · nothing goes live until you save a version and pin it.

Save as a new version

Commit the working phases as a new draft version with a one-line commit message, and an optional label (1–64 characters) shown beside the auto-generated version id.

Pin as live

Pin the version you trust. Pinning one version unpins the rest, so there is always exactly one live version, and agents pick it up immediately.

Every version is Live (pinned), Draft (editable), or Archived (read-only · fork it to edit). You can fork any version into a fresh draft, make the live version a draft to leave the design with no live version, and delete a version · except the live one and the last remaining one, which are protected so a running design is never orphaned.

Edit draftWorking phases

Save versionCommit message

Test runDraft vs live

Pin as liveAgents run it

The design lifecycle · edit a draft, save it, test it against live, then pin.

#Test before you pin

Test run executes a real agent run of a non-live version in one of your environments, so you compare before you promote:

Set up

Pick an environment, a repository in its scope, and an issue or task. The design’s bound persona rides along.

Read the verdict

The result scores the test against your live version on three metrics · outcome, cost and duration · each with a delta, plus a phase-by-phase diff.

Promote

If the test wins, Pin as live straight from the result. Test runs are kept separate from your production Runs board, so experiments never mix with real work.

#Limits

The per-phase and per-design bounds, all enforced:

Thing	Limit
Phase timeout	1 – 86,400 seconds (24 hours)
Max retries per phase	0 – 20
Max iterations (loop) per phase	1 – 50
Loop-back edge cap	default 3 passes, then the flow continues
Trigger rules per workspace	20
Version label	1 – 64 characters

There is no fixed cap on the number of phases in a design, or designs in a workspace · practicality and your run quota (below) are the real limits.

#Quotas and caps

Separate from the design itself, four platform quotas decide whether a run is allowed to start. Each is checked at dispatch, and a run that would breach one is refused with a clear message naming the limit it hit. A limit of 0 means unlimited.

Cap	Scope	Resets
Run limit	Runs per environment per month	Monthly
Monthly run quota	Runs per workspace per month (from your plan)	Monthly
Daily budget	USD spend per environment per day	Daily
Monthly spend	USD spend per workspace per month (from your plan)	Monthly

Spend is real USD, computed by the platform per model as each phase completes (see Run anatomy). The console surfaces your standing against these caps · the run-quota widget in the sidebar, and each environment’s runs this month / limit and spend today / daily budget figures.

Cap experiments where they run

Set a per-environment daily budget and run limit before pointing an agent at a large repository. A test or sandbox environment with a small cap is the safe place to try an expensive design.

A hired agent can also carry its own optional quota · a maximum number of runs within a rolling window (default 30 days), useful as a proxy for how many pull requests it may have in flight. The workspace and plan limits still apply on top.

The specific numbers your workspace gets · the monthly run allowance and spend cap · come from your plan. See the pricing on the AgentSDE homepage for the current tiers.