Overview
An incident that spans the cluster, the cloud account and a deploy needs three specialists, and someone to decide which three. Run them by hand and you are the router: choosing who to ask, waiting, and reconciling three answers that do not agree. It runs a declarative workflow over your fleet, and it is also the Komodor Agentic Operation Platform (KAOP) account’s executor for a module workflow’sorchestrated steps.
It delegates over agent-to-agent invocation through the control plane, so every specialist call is
authorized and recorded like any other run rather than becoming an unobserved side channel.
For: questions that need more than one specialist, and for the module workflows whose steps
dispatch to it.
Not for: doing the investigation itself — it has no specialist surface of its own.
Running a workflow
A workflow is steps that fan out to several specialists at once, run in order, or loop until the work is done.
The contained-failure behaviour is the one to design around: a workflow finishing does not mean
every step succeeded, so read the steps rather than the outcome.
Executing an orchestrated step
A module workflow’s steps come in two kinds, and the orchestrator handles one of them:
Either way the outcome is written back onto the step run, which is the only place a caller learns
what happened.
An account has one step executor: whichever agent holds the
step-orchestrator role is the one
every orchestrated step dispatches to. Deploying a second does not give you two — it gives you a
question about which one holds the role.Tools supported
It reaches no external system. Its whole tool surface is the fleet, through agent-to-agent
invocation over the control plane — which is why every delegated call is authorized and recorded
like any other run.
Scenario examples
In chat, or as a run’s prompt: Let it choose the specialistsPrerequisites
Catalog ID:
workflow-orchestrator — what the deploy API takes.
As part of a workflow
It is the lead rather than a specialist — the agent a workflow runs on, not one a step delegates to. A module’sorchestrated steps dispatch to whichever agent holds the step-orchestrator role,
and that is this one.
Pair it with specialists rather than replacing them: it decides who to call and combines what comes
back, and every sub-task it delegates is its own run with its own evidence.
Limitations
- It does no specialist work itself — it routes, delegates, and synthesizes, which is what keeps its output auditable: each sub-task is its own run with its own evidence.
- It reaches only agents that are online. A specialist that is down is not queued for later; the step records that it could not be reached and the rest carries on.
- It cannot make a workflow succeed that its specialists failed. A finished workflow does not mean every step succeeded — read the steps rather than the outcome.
- An account has one step executor. Deploying a second orchestrator does not give you two; it
gives you a question about which one holds the
step-orchestratorrole.
Recommended model
claude-sonnet-5 — the shipped default. The work is judgement over evidence someone else gathered,
where a weaker model produces confident-sounding conclusions that do not hold.
Next steps
Agent catalog
Every deployable agent, and what each one is for.
Modules & workflows
The packaged workflows these steps belong to.
Runs & evidence
Reading a delegated run and the spans that link it.