Skip to main content
The KAOP Workflow Orchestrator is the one catalog agent that does no specialist work itself. It decides which agents should, delegates to them over the control plane, and combines what comes back into a single answer.

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’s orchestrated 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.
You do not usually invoke this path directly. It is what makes a module’s workflow steps run, and it matters when you are reading a workflow’s traces or working out why a step routed the way it did.

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 specialists
Scope the roster yourself
Verify after the fact
Given a roster and no workflow it decides for itself who to call, and loops until it judges the goal met. Given a declarative workflow it follows that instead.

Prerequisites

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’s orchestrated 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-orchestrator role.
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.