# 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 is the Valdr layer that makes those handoffs explicit. It gives orchestrators the tools, capabilities, session runtime, and project state they need to coordinate specialized agents without turning the workflow into a pile of disconnected chats.

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.

{{< cards >}}
  {{< card title="Specialists coordinate" subtitle="Planners, executors, reviewers, auditors, and orchestrators each own the work they are best suited for" icon="user-group" >}}
  {{< card title="Handoffs are explicit" subtitle="Sessions, tasks, reviews, scores, and status changes create an inspectable execution timeline" icon="switch-horizontal" >}}
  {{< card title="Gates become enforceable" subtitle="Readiness, review, audit, merge, and closeout checks can stop the workflow before bad work advances" icon="shield-check" >}}
  {{< 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" >}}
{{< /cards >}}

## 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, launcher 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:

{{% steps %}}

### 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.

{{% /steps %}}

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:

```text
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 task
```

The 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 |

That is the core Valdr orchestration thesis: agents should not just answer; they should coordinate work through inspectable runtime state.

## Pairing with the platform stack

Orchestration depends on the deeper layers:

- **Workspace Knowledge** gives orchestrators and specialists persistent engineering context.
- **Agent Sessions** provide the persistent runtime records that make handoffs inspectable.
- **Team Capabilities** encode the workflow rules each agent follows.
- **Reviewable AI Workflows** provide the gates that decide whether work advances.

Together, those layers 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

- Read [Agent Sessions for Orchestrated AI Workflows](/valdr/docs/features/agent-sessions/) for the runtime layer behind orchestration.
- Read [Team Capabilities for AI Agents](/valdr/docs/features/team-capabilities/) for reusable workflow behavior.
- Read [Build Your Own Workflow](/valdr/docs/getting-started/workflows/) for the lower-level building blocks.
- Open the [Orchestrator UI guide](/valdr/docs/ui/orchestrator/) for screen-level usage.