Multi-Agent Workflow Orchestration
{"content":"Most agent workflows still depend on a human operator to move work from one agent to the next. You ask one agent to plan, another to code, another to review, then manually stitch together the handoffs.\n\nMulti-Agent Workflow Orchestration makes those handoffs explicit. Orchestrators use tools, capabilities, session history, and project records to coordinate specialized agents and keep their work connected.\n\nOrchestration turns individual agents into an **operating system for engineering work**.\n\n## What changes\n\nWithout orchestration, you are the workflow engine. You decide what runs next, copy context between agents, track which review is blocking, and remember whether the task is ready to advance.\n\nWith Valdr, orchestrator agents can discover state, choose the next action, launch the right specialist, route review, send follow-up input, verify gates, and keep work moving through the lifecycle.\n\n{{\u003c cards \u003e}}\n {{\u003c card title=\"Specialists coordinate\" subtitle=\"Planners, executors, reviewers, auditors, and orchestrators each own the work they are best suited for\" icon=\"user-group\" \u003e}}\n {{\u003c card title=\"Handoffs are explicit\" subtitle=\"Sessions, tasks, reviews, scores, and status changes create an inspectable execution timeline\" icon=\"switch-horizontal\" \u003e}}\n {{\u003c card title=\"Gates become enforceable\" subtitle=\"Readiness, review, audit, merge, and closeout checks can stop the workflow before bad work advances\" icon=\"shield-check\" \u003e}}\n {{\u003c card title=\"Work keeps moving\" subtitle=\"An orchestrator can launch follow-up runs, message sessions, and dispatch the next task when gates pass\" icon=\"play\" \u003e}}\n{{\u003c /cards \u003e}}\n\n## What orchestrators can now do\n\nOrchestration is not a UI chat feature. It is workflow control for agent systems.\n\n| Orchestration goal | What Valdr enables |\n|--------------------|--------------------|\n| Discover current state | Query projects, tasks, sprints, reviews, agents, sessions, and knowledge before deciding what to do |\n| Choose the right specialist | Route planning to planners, implementation to executors, review to reviewers, and scoring to auditors |\n| Launch work with context | Start task-scoped sessions with the right agent, capability set, provider preset, and instructions |\n| Route feedback | Send review feedback or clarification back to a running or idle session without losing the execution timeline |\n| Enforce gates | Verify review status, audit results, task readiness, and workflow state before advancing |\n| Continue the chain | Close completed work, clean up sessions according to policy, and launch the next step |\n\nThis is where Valdr starts to feel less like agent tooling and more like orchestration infrastructure.\n\n## The orchestration loop\n\nValdr workflows usually follow a loop:\n\n{{% steps %}}\n\n### Discover state\n\nThe orchestrator reads project, task, sprint, review, session, and knowledge state before taking action.\n\n### Decide next action\n\nIt evaluates whether the work needs planning, execution, review, audit, feedback, cleanup, or next-task launch.\n\n### Dispatch the specialist\n\nIt launches or messages the right agent session with the task, role, capabilities, and context needed for that step.\n\n### Verify the result\n\nIt checks status, review decisions, score evidence, session state, and worktree output before moving forward.\n\n### Advance or stop\n\nIf the gate passes, the workflow advances. If the gate fails, the workflow stops with evidence instead of silently drifting.\n\n{{% /steps %}}\n\nThat loop is simple, but it changes the operating model. The human does not need to be the router for every handoff. The workflow itself becomes a persistent operational system instead of a series of disconnected prompts and handoffs.\n\n## Example workflow\n\nA full Valdr workflow can look like this:\n\n```text\nGunnar discovers context\n -\u003e Freya plans the work\n -\u003e Skadi staffs and launches execution\n -\u003e Executor implements in a session worktree\n -\u003e Sigrid reviews the output\n -\u003e Auditor scores the session\n -\u003e Skadi routes feedback or advances the task\n```\n\nThe important part is not the agent names. The important part is that each step has a role, a record, and a gate.\n\n## What makes this different from ad-hoc agents\n\n| Ad-hoc agent routing | Valdr orchestration |\n|----------------------|---------------------|\n| Manual copy-paste between chats | Explicit handoffs through tasks, sessions, reviews, and MCP tools |\n| Context gets re-explained every run | Workspace Knowledge and capabilities travel with the workflow |\n| Review depends on memory | Review and audit attach to the execution record |\n| Follow-up work starts from scratch | Sessions can be messaged, restarted, or chained |\n| Process lives in one person's head | Workflow behavior lives in capabilities and orchestrator actions |\n\nYou can inspect each handoff, see what ran, and check the evidence before work advances.\n\n## Pairing with other features {#pairing-with-the-platform-stack}\n\nOrchestration uses these features to keep work connected:\n\n- **Workspace Knowledge** gives orchestrators and specialists persistent engineering context.\n- **Agent Sessions** preserve the history that makes handoffs inspectable.\n- **Team Capabilities** encode the workflow rules each agent follows.\n- **Reviewable AI Workflows** provide the gates that decide whether work advances.\n\nTogether, these features let agents understand, execute, review, remember, and continue work across workflows.\n\n## Guardrails\n\nMulti-agent orchestration should be explicit, not magical:\n\n- Use idempotency keys for launches and mutating workflow steps.\n- Verify state before advancing tasks or launching follow-up work.\n- Keep reviewer and auditor gates separate from executor output.\n- Preserve session timelines so handoffs remain inspectable.\n- Let failed gates stop the workflow instead of auto-approving questionable output.\n- Keep capabilities focused so orchestrators do not inherit unclear responsibilities.\n\nGood orchestration is not \"let agents do anything.\" It is controlled delegation with state, evidence, and gates.\n\n## Next steps\n\n- See [Durable Workflows](/valdr/docs/features/workflows/) to turn these handoffs into repeatable processes that resume after waits or restarts.\n- Read [Agent Sessions for Orchestrated AI Workflows](/valdr/docs/features/agent-sessions/) to launch, inspect, message, and continue agent work.\n- Read [Team Capabilities for AI Agents](/valdr/docs/features/team-capabilities/) for reusable workflow behavior.\n- Read [Build Agent Routines with Capabilities](/valdr/docs/getting-started/workflows/) for the lower-level building blocks.\n- Open the [Orchestrator UI guide](/valdr/docs/ui/orchestrator/) for screen-level usage.","description":"Coordinate planners, executors, reviewers, auditors, and follow-up sessions through explicit workflow control instead of manual prompt routing.","title":"Multi-Agent Workflow Orchestration"}
Most agent workflows still depend on a human operator to move work from one agent to the next. You ask one agent to plan, another to code, another to review, then manually stitch together the handoffs.
Multi-Agent Workflow Orchestration makes those handoffs explicit. Orchestrators use tools, capabilities, session history, and project records to coordinate specialized agents and keep their work connected.
Orchestration turns individual agents into an operating system for engineering work.
What changes
Without orchestration, you are the workflow engine. You decide what runs next, copy context between agents, track which review is blocking, and remember whether the task is ready to advance.
With Valdr, orchestrator agents can discover state, choose the next action, launch the right specialist, route review, send follow-up input, verify gates, and keep work moving through the lifecycle.
Planners, executors, reviewers, auditors, and orchestrators each own the work they are best suited for
Sessions, tasks, reviews, scores, and status changes create an inspectable execution timeline
Readiness, review, audit, merge, and closeout checks can stop the workflow before bad work advances
An orchestrator can launch follow-up runs, message sessions, and dispatch the next task when gates pass
What orchestrators can now do
Orchestration is not a UI chat feature. It is workflow control for agent systems.
| Orchestration goal | What Valdr enables |
|---|---|
| Discover current state | Query projects, tasks, sprints, reviews, agents, sessions, and knowledge before deciding what to do |
| Choose the right specialist | Route planning to planners, implementation to executors, review to reviewers, and scoring to auditors |
| Launch work with context | Start task-scoped sessions with the right agent, capability set, provider preset, and instructions |
| Route feedback | Send review feedback or clarification back to a running or idle session without losing the execution timeline |
| Enforce gates | Verify review status, audit results, task readiness, and workflow state before advancing |
| Continue the chain | Close completed work, clean up sessions according to policy, and launch the next step |
This is where Valdr starts to feel less like agent tooling and more like orchestration infrastructure.
The orchestration loop
Valdr workflows usually follow a loop:
Discover state
The orchestrator reads project, task, sprint, review, session, and knowledge state before taking action.
Decide next action
It evaluates whether the work needs planning, execution, review, audit, feedback, cleanup, or next-task launch.
Dispatch the specialist
It launches or messages the right agent session with the task, role, capabilities, and context needed for that step.
Verify the result
It checks status, review decisions, score evidence, session state, and worktree output before moving forward.
Advance or stop
If the gate passes, the workflow advances. If the gate fails, the workflow stops with evidence instead of silently drifting.
That loop is simple, but it changes the operating model. The human does not need to be the router for every handoff. The workflow itself becomes a persistent operational system instead of a series of disconnected prompts and handoffs.
Example workflow
A full Valdr workflow can look like this:
Gunnar discovers context
-> Freya plans the work
-> Skadi staffs and launches execution
-> Executor implements in a session worktree
-> Sigrid reviews the output
-> Auditor scores the session
-> Skadi routes feedback or advances the taskThe important part is not the agent names. The important part is that each step has a role, a record, and a gate.
What makes this different from ad-hoc agents
| Ad-hoc agent routing | Valdr orchestration |
|---|---|
| Manual copy-paste between chats | Explicit handoffs through tasks, sessions, reviews, and MCP tools |
| Context gets re-explained every run | Workspace Knowledge and capabilities travel with the workflow |
| Review depends on memory | Review and audit attach to the execution record |
| Follow-up work starts from scratch | Sessions can be messaged, restarted, or chained |
| Process lives in one person’s head | Workflow behavior lives in capabilities and orchestrator actions |
You can inspect each handoff, see what ran, and check the evidence before work advances.
Pairing with other features
Orchestration uses these features to keep work connected:
- Workspace Knowledge gives orchestrators and specialists persistent engineering context.
- Agent Sessions preserve the history that makes handoffs inspectable.
- Team Capabilities encode the workflow rules each agent follows.
- Reviewable AI Workflows provide the gates that decide whether work advances.
Together, these features let agents understand, execute, review, remember, and continue work across workflows.
Guardrails
Multi-agent orchestration should be explicit, not magical:
- Use idempotency keys for launches and mutating workflow steps.
- Verify state before advancing tasks or launching follow-up work.
- Keep reviewer and auditor gates separate from executor output.
- Preserve session timelines so handoffs remain inspectable.
- Let failed gates stop the workflow instead of auto-approving questionable output.
- Keep capabilities focused so orchestrators do not inherit unclear responsibilities.
Good orchestration is not “let agents do anything.” It is controlled delegation with state, evidence, and gates.
Next steps
- See Durable Workflows to turn these handoffs into repeatable processes that resume after waits or restarts.
- Read Agent Sessions for Orchestrated AI Workflows to launch, inspect, message, and continue agent work.
- Read Team Capabilities for AI Agents for reusable workflow behavior.
- Read Build Agent Routines with Capabilities for the lower-level building blocks.
- Open the Orchestrator UI guide for screen-level usage.