Above the Workflow: Fleet, Mission, and the Orchestration Layer We're Building for Enterprise AIOps
Start with the unit that is real and running today. A Workflow in the platform is a directed graph — a DAG built from 76 node types — that coordinates up to 15 agent types to close one issue. It fans out work in parallel, merges results at gates, retries failed branches, pauses at human-approval checkpoints, and emits a signed, replay-verifiable trace for every run. That part is not a slide. It is in the self-hosted platform, and you can run it.
So what commands the workflows? That is the question this post is about. The honest answer is that the layer above the workflow — the one that takes a single objective and spawns many workflows toward it — is in active prototype. We have the substrate. We are building the objective layer on top of it now. This post draws the seam between the two as precisely as we can, because the multi-agent orchestration idea is not new in general; what is new, and what we are building, is a governed, auditable, multi-workflow objective layer for AIOps.
The four words we use, and exactly what each one means
Loose vocabulary is how roadmaps get sold as releases. So here is the canon, with the status of each term stated in line. We use these exact words and we do not invent synonyms for them.
- Agent — an individual worker inside a workflow. One model, one role, one scoped credential set. Real today in the OSS platform.
- Workflow — one-to-many agents working a single issue, wired as a DAG with retries, parallel fan-out, and human-in-the-loop gates. Real today in the OSS platform.
- Mission — the abstraction above the workflow: a long-running objective that spawns one-to-many workflows (each with many agents) and keeps going until the whole goal is done. In active prototype.
- Fleet — multiple deployments of the platform, federated, working together across regions, clusters, or trust boundaries. In active prototype.
- Fleet Commander — the federation controller that owns a Fleet and dispatches Missions across instances. In active prototype.
One disambiguation before we go further. Capital-F Fleet here means federated deployments. It is not the “MCP fleet” of tool servers you may have seen in our architecture diagrams — that phrase refers to the pool of MCP tool servers an agent can call. Different thing. Keep them distinct: a Fleet is made of platform instances; an MCP fleet is made of tool servers.
What's real today — the substrate
Everything Missions and Fleets are designed to stand on already exists in the self-hosted platform you can run. Being specific matters here, because the credibility of the vision rests entirely on the substrate being genuinely enterprise-grade rather than a demo.
The execution engine. The WorkflowExecutionEngine is a DAG walker. It does parallel fan-out, merge gates, sequential routing, and conditional routing, with node-level error handling so a failed branch does not take down the run. This is the machinery that a Mission would eventually drive many instances of.
76 node types. The node library is deliberately ops-shaped. Alongside the generic control-flow and model nodes are the AIOps primitives: pagerduty_incident, servicenow_ticket, splunk_search, anomaly_detect, k8s_sandbox_run, grounding_check, and guardrails. You build incident response, drift correction, and remediation flows out of these directly.
15 agent types with real model routing. Each agent type routes its model selection through SmartModelRouter, which spans 50+ models across Bedrock, Azure OpenAI, Vertex, and Ollama. It routes on capability, cost, and structural analysis of the request — there is no pre-LLM intent-classifier in the path; that was removed in Phase E.1. The right model for each step, chosen per agent.
Human-in-the-loop, as architecture. The human_approval and human_input gates are not confirmation dialogs bolted on after the fact. A gate pauses the run, checkpoints the workflow state, emits an event, and resumes when a POST arrives. This is the mechanism that makes a long-running, partly-autonomous objective safe to operate.
Signed, replay-verifiable traces. The TraceCollector records every step and seals each trace with an HMAC-SHA256 contentHash. Replay-verification is prebuilt: you can re-run a trace and confirm it matches its signature. For ops on production infrastructure, this is the difference between “the agent did something” and “here is the cryptographically attributable record of exactly what it did.”
Workflows can already call workflows. The sub_workflow node lets a parent workflow invoke a child by ID, inheriting the parent's auth context. This is the closest the shipped substrate comes to composition above a single flow — and it is the seed the Mission engine grows from, though it is not the Mission engine.
This is the part you can run today. It's the foundation everything above it is designed to stand on.
Mission — the abstraction above the workflow
Here is the conceptual leap. A Workflow is a fixed DAG: you decide its shape up front, and the engine walks it. A Mission decides what workflows to spawn as it learns. It fans out to many workflows in parallel, branches on their results, retries the branches that failed, and tracks lineage across all of them — a state machine moving through pending → active → completed/failed, with checkpoint and resume the whole way — until the objective is actually done, not until a predetermined graph has been traversed.
The mental model we keep coming back to — and we frame this clearly as the goal, not today's reality — is: if Claude Code could command N Claude Codes. Imagine one Fleet prompt: “build the platform and its dependencies via adversarial TDD.” That opens a Mission. The Fleet Commander spawns a workflow per service. Each workflow spins up agents to write the code, write the adversarial tests, run them, and route the failures back as new work. Across many workflows and many agents, the Mission keeps going — spawning, branching, retrying — until all the requested work is done. That is the shape of the objective layer. It is what we are building toward.
Fleet — federating deployments
This is the enterprise tier — the reason a large organization runs the platform rather than a single instance of it. A Fleet is designed to federate across many clouds, many tenants, and many trust boundaries at once — multi-cloud, multi-tenant, multi-anything — under one Fleet Commander that holds fleet-wide control of every Mission and the Workflows beneath them. The point of that control plane is duration and scale: very long, very complex workloads — a multi-region migration, a quarter-long hardening program, continuous cross-cluster drift correction — managed as a single governed objective over days, weeks, or months, while each federated instance stays independently attributable with its own credentials and its own audit chain. That is what Fleet and the Fleet Commander are being built for. To be exact about status: it is in active prototype, not shipped — the framing here is the design target, not a current capability.
A Fleet is the next ring out: multiple deployments of the platform working together across regions, clusters, or trust boundaries. Work distributes across instances, and — this is the point — each instance keeps its own credentials and its own audit chain. A federated deployment does not mean a shared god-credential; it means many governed instances cooperating while each remains independently attributable.
The Fleet Commander is the controller that owns the Fleet and dispatches Missions across it — the “fed master” that decides which instance runs which Mission and reconciles the results. Today, to be plain about it: on-behalf-of authentication and credentials are strictly per-deployment, and there is no inter-deployment routing. The Fleet Commander is the controller we are designing to sit above that boundary.
Why this is new FOR AIOps specifically
Generic multi-agent frameworks exist. We did not invent federated agents and we are not going to claim we did. What is unproven — and what we are aiming squarely at — is the governed, multi-workflow objective layer for operations: fleet-wide remediation, cross-cluster drift correction, incident response that spans many runbooks at once rather than one alert at a time.
The reason we think we can credibly build this is that the substrate underneath is already ops-grade. Signed traces give you attribution. HITL gates give you control over consequential actions. Per-tool credential isolation and RBAC give you least privilege that holds even inside automated runs. A Mission that spans a Fleet inherits all of that. The novelty is not “many agents” — it is many agents, across many workflows, across many deployments, that remain auditable and ops-shaped the whole way down. That is the gap general-purpose agentic platforms leave open, and it is the gap we are building into.
None of this displaces the rest of the platform. The platform is the whole: SmartModelRouter, ChatMode, CodeMode, AgenticWorkflows, Deep Research, OATS, credential isolation, DLP, audit trails, RBAC, and the MCP Workshop. Mission and Fleet are a new orchestration tier on top of those existing capabilities — not a replacement for them, and no single piece is “the solution.”
Let's be precise about the seam
Let's be precise about the seam. Workflows, agents, HITL gates, and signed traces are real and running in the self-hosted platform today — that's the substrate. Mission and Fleet are in active prototype: there is no Mission table, no fleet-registry, no inter-deployment routing, and no Fleet Commander control plane in the codebase yet. The deprecated SubagentOrchestrator ran parallel subtasks; it is not the Mission engine. We're building this layer now, and we'd rather show you the honest map than sell you a roadmap as a release. No customer counts, no benchmarks — just the architecture and where it's going.
Where we're headed, and how to get involved
The enterprise roadmap stacks in the order the dependencies demand it. First, the Mission state machine with multi-workflow lineage — the ability to spawn, branch, retry, and track many workflows toward one objective. Then Fleet work distribution — spreading those workflows across federated deployments. Then the Fleet Commander control plane with cross-deployment credential federation — the controller that dispatches Missions across the Fleet while every instance keeps its own audit chain.
If you want to see the boundary drawn formally, read the Enterprise docs page on our open-source core — it carries the FleetFlow diagram and the boundary table that marks exactly what is substrate versus what is prototype. The OSS substrate — workflows, agents, HITL, signed traces — is installable today, so you can run the foundation now and watch the objective layer land on top of it. And if fleet-wide, governed AIOps is the problem you are living with, reach out: this is the moment to shape the Mission and Fleet roadmap rather than inherit it.