The Orchestrator workspace is for deterministic agent flows.

Use it when:

• the steps are known,
• the order matters,
• each agent has a clear responsibility,
• outputs from earlier steps feed later steps,
• you want predictable execution and debugging.

An Orchestrator pipeline is a recipe:

input context -> step 1 agent -> step 2 agent -> mappings -> final output

It is not autonomous. It does not decide which step comes next. The pipeline definition decides the path.

• PipelineDefinition
• PipelineStep
• ExecutionSession
• ExecutionStepRun

Host projects may also create their own domain result models.

A pipeline defines the full recipe.

Common fields:

• name,
• description,
• active flag,
• optional entry agent,
• global input contract,
• global output contract,
• ordered steps.

Example name:

support_triage_v1

Example description:

Reads a support ticket, classifies it, checks policy knowledge, then drafts a response.

Keep a pipeline inactive while building it. Activation validates that steps are continuous and agents have contracts.

Each step points to one agent.

Fields:

• order
• agent
• input_mapping
• output_mapping
• on_error
• fallback_agent

Step order should be continuous:

1, 2, 3, 4

input_mapping maps workflow context into the agent input.

Left side: agent input key.

Right side: context path.

{
  "ticket_text": "ticket_text",
  "knowledge_context": "knowledge_context"
}

output_mapping writes agent output back into workflow context.

Left side: context key.

Right side: response path.

{
  "triage_result": "agent",
  "model_text": "llm.content"
}

Dot paths such as llm.content are supported.

on_error supports:

Use stop while testing. Use continue only for optional enrichment. Use fallback agents only when another agent can genuinely recover the step.

Open:

/admin/ai_hub/workspaces/orchestrator/

The workspace shows:

• pipeline counts,
• active pipeline counts,
• session counts,
• running or waiting sessions,
• failed sessions,
• recent orchestrator sessions,
• pipeline links.

The control center graph shows how providers, models, agents, knowledge, tools, pipelines, and steps connect.

Keep each agent narrow.

Good:

source_reader -> facts_extractor -> risk_classifier -> final_writer

Risky:

mega_agent_that_does_everything

Narrow agents make contracts, failures, timelines, and tests easier.