Built-in workflow patterns
Split a task across frontend, backend, review, docs, or custom roles. Each agent can have its own provider, model, label, and instruction.
Ask different models or providers to inspect the same implementation. Useful for release risk, regressions, security-sensitive changes, and design critique.
Run a task in stages where one agent prepares context, another implements, another reviews, and a final step summarizes.
Compare approaches before code changes begin. This is useful when architecture, API shape, or UX direction is uncertain.
Run controls
Orchestration is not only a prompt box. It gives concrete controls that make multi-agent runs inspectable and recoverable.
- Enable or disable agents before a run.
- Duplicate a provider when multiple workers from the same CLI are needed.
- Choose per-agent role, label, instruction, and stage.
- Select models per agent, including OpenCode model choices.
- Choose a fallback CLI agent for failures.
- Preview the workflow DAG before execution.
- Stream run events and inspect node state.
- Cancel active workflow runs.
- Resize left and right orchestration panes for desktop workflows.
Orchestration API example
The same system can be used by external tools through `px_` API keys.
curl http://localhost:3001/api/orchestration/workflows/agent_team/preview \
-H "Authorization: Bearer px_your_key_here" \
-H "Content-Type: application/json" \
-d '{
"metadata": {
"agents": [
{ "adapterId": "codex", "label": "Backend", "role": "backend" },
{ "adapterId": "claude", "label": "Frontend", "role": "frontend" },
{ "adapterId": "opencode", "label": "Reviewer", "role": "review" }
],
"settings": {
"maxParallelAgents": 3,
"isolation": "host"
}
}
}'