Skip to content
Documentation
Features
Multi-Agent Workflow Orchestration

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.

Specialists coordinate
Planners, executors, reviewers, auditors, and orchestrators each own the work they are best suited for
Handoffs are explicit
Sessions, tasks, reviews, scores, and status changes create an inspectable execution timeline
Gates become enforceable
Readiness, review, audit, merge, and closeout checks can stop the workflow before bad work advances
Work keeps moving
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 goalWhat Valdr enables
Discover current stateQuery projects, tasks, sprints, reviews, agents, sessions, and knowledge before deciding what to do
Choose the right specialistRoute planning to planners, implementation to executors, review to reviewers, and scoring to auditors
Launch work with contextStart task-scoped sessions with the right agent, capability set, launcher preset, and instructions
Route feedbackSend review feedback or clarification back to a running or idle session without losing the execution timeline
Enforce gatesVerify review status, audit results, task readiness, and workflow state before advancing
Continue the chainClose 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 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 routingValdr orchestration
Manual copy-paste between chatsExplicit handoffs through tasks, sessions, reviews, and MCP tools
Context gets re-explained every runWorkspace Knowledge and capabilities travel with the workflow
Review depends on memoryReview and audit attach to the execution record
Follow-up work starts from scratchSessions can be messaged, restarted, or chained
Process lives in one person’s headWorkflow 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

Team Capabilities for AI AgentsReviewable AI Agent Workflows