Build with Syntic CodeAgents and parallel workWorkflows

Workflows

A workflow is a planned set of subagent steps that Syntic Code runs for you in one go. Each step is a separate subagent with its own prompt. Steps that do not depend on each other run side by side; a step that needs earlier results waits for them and can quote their output. When everything is done, the main session gets one combined report.

Use a workflow when a job splits into many similar pieces (audit forty files, migrate twelve packages) or into stages (survey, then decide, then write) and you want the pieces done in parallel without filling your conversation.

When to use one

JobBest fit
One focused side taskA subagent
Many independent pieces, or stages that feed each otherA workflow
Several agents that need to talk while they workAn agent team
A big code change where each piece needs its own branch/batch <task>, which gives each agent its own worktree

Ask for a workflow

Describe the job and say you want it done as parallel steps:

Audit every handler in src/api/ for missing input validation. Run one
step per file in parallel, then a final step that merges the findings
into a table sorted by severity.

The agent plans the steps and starts the run with its Workflow tool. You can also let it decide for itself: with ultracode on, the agent is nudged to plan any large, multi-part request as a workflow instead of doing everything in one thread.

/effort ultracode on

The status bar shows [ULTRACODE] while it is on. It lasts for the session and does not change the effort level. /effort ultracode off turns it off; /effort ultracode on its own flips it.

How a run works

A workflow is a list of steps. Each step has:

FieldMeaning
idA short name: letters, digits, - or _, up to 40 characters, unique in the run.
promptThe task for that step’s subagent. {{id}} inserts the output of an earlier step.
agentOptional. Which subagent type runs the step, such as explore or one of your custom agents.
modelOptional. A model for this step only.
afterOptional. The ids of steps this one waits for.
output_schemaOptional. A JSON schema the step’s answer must fit.

The run as a whole can have a description (a short label) and max_concurrent (how many steps run at once).

Before anything starts, the plan is checked: every id is valid and unique, every after names a real step, there are no loops, and a {{id}} only quotes a step it waits for. A plan that fails a check is rejected with the reason, and the agent fixes it.

Then:

  1. Every step whose after list is satisfied starts, up to the parallel limit.
  2. As steps finish, the steps waiting on them become ready and start.
  3. A step with output_schema must answer with JSON that fits. If it does not, it gets one retry with the mismatch explained.
  4. If a step fails, every step that waits on it is skipped. Unrelated steps still run.
  5. The result lists every step in plan order with its state (done, failed or skipped) and its output.

An example plan

What the agent sends for a survey-then-summarize job looks like this:

{
  "description": "survey payment modules",
  "steps": [
    { "id": "cards",   "agent": "explore", "prompt": "List every place src/payments/cards charges a card and how errors are handled." },
    { "id": "wallets", "agent": "explore", "prompt": "List every place src/payments/wallets charges a wallet and how errors are handled." },
    { "id": "summary", "after": ["cards", "wallets"],
      "prompt": "Compare the error handling in these two reports and list inconsistencies:\n\n{{cards}}\n\n{{wallets}}" }
  ]
}

cards and wallets run at the same time; summary starts when both are done.

Limits

LimitValue
Steps in one run50
Steps running at once4 by default. A run may ask for more with max_concurrent, up to the cap.
Cap on steps running at once16. Raise it (1 to 256) with SYNTIC_WORKFLOW_MAX_CONCURRENT_AGENTS.
Output kept per stepThe first 6,000 characters, in the final report.

Each step is a subagent, so the usual subagent limits apply too, such as nesting depth and the total number of subagents running at once.

Set a size guideline

The workflowSizeGuideline setting tells the agent how big its workflows should be. It is advice, not a hard limit:

ValueAim for
smallAbout 5 steps.
medium (default)About 10 steps.
largeAbout 20 steps.
unrestrictedNo advice.
{ "workflowSizeGuideline": "small" }

Any settings file may set it; the strongest one wins.

Watch and stop runs

/workflows lists this session’s runs, newest first, with each step’s state (for example scan: running). Each subagent also appears in the agents view (← on an empty prompt), where Enter opens its conversation.

/workflows stop wf-3a9c

Stopping lets the steps already running finish and starts no further ones. To stop a single step’s subagent at once, select it in the agents view and press x twice.

Built on workflows

/ultrareview runs its three review passes (correctness, security, tests) as parallel workflow steps and merges their findings in a final step. See Code review.

Cost

Every step is a full subagent call. A 20-step workflow costs about as much as 20 separate subagents, plus the final summary. Per-agent spend shows in /cost. Caps set with max-budget-usd in an agent file, or agents.defaultMaxBudgetUsd in settings, apply to each step’s subagent (Spend caps).

Sibling steps of the same type start a moment apart so later ones can reuse the prompt cache the first one wrote (Prompt caching).

Turn workflows off

Starting a workflow goes through your permission rules like any other tool. To stop the agent from using them, add a deny rule:

{ "permissions": { "deny": ["Workflow"] } }

or pass --disallowed-tools Workflow for one run.

Prompts that suit workflows

Check every package in packages/ for dependencies that are declared but
never imported. One step per package, then one step that writes a single
cleanup list.
For each of the 9 locale files in i18n/, find keys that are missing
compared to en.json. Run them in parallel and give me one table.
Research three ways to add full-text search to our Postgres setup:
one step each for the built-in search, an extension, and an external
service. Then a final step that compares them for our data size.