Enterprise — Fleet & Mission
A single Workflow already coordinates many agents to close one issue, end to end, with signed audit trails and human-in-the-loop gates. The enterprise question is the next layer up: what commands the workflows? Fleet and Mission are our answer — and this page is honest about which parts run today and which are in active prototype.
Two halves, one seam. Real today (the OSS substrate): Workflows (73 node types on a DAG execution engine), Agents (named worker types), human-in-the-loop approval and input gates, signed and replay-verifiable execution traces, the SmartModelRouter across 50+ models, and sub-workflow invocation. Prototype / roadmap: the Mission (the long-running objective that spawns many workflows), the Fleet (federated deployments working together), and the Fleet Commander (the controller across instances). The first half is the foundation; the second half is what we're building on top of it now.
The hierarchy
Five levels, bottom to top. Each card states its status inline — read the tags, not just the names.
Agent real today
The individual worker inside a workflow — named worker types (data_query, reasoning, code_execution, planning, tool_orchestration, and more). Each agent gets per-task model routing via the SmartModelRouter — model chosen on complexity, cost budget, and capability (function-calling, vision, thinking). The AgentRegistry records tokens, cost, model, and success per run.
Workflow real today
1-to-many agents/flows working a single issue. A DAG of 73 node types executed by the WorkflowExecutionEngine: triggers, LLM completions, MCP tools, conditionals/switches/loops, parallel fan-out with merge gates, error handlers, approval gates, and integration nodes (Slack, Jira, ServiceNow, PagerDuty, Splunk). Every run emits a signed, replay-verifiable trace.
Mission in active prototype
The abstraction above workflows: a long-running objective that spawns 1-to-many workflows — each with its own agents — and keeps spawning, branching, and retrying until the whole goal is done. Think of it as a workflow factory with a state machine (pending → active → completed/failed) and checkpoint/resume.
Fleet in active prototype
Multiple federated Gnomus deployments working together — across regions, clusters, or trust boundaries. Work distributes across instances; each instance keeps its own credentials and audit chain. (Distinct from the "MCP fleet" of tool servers — capital-F Fleet = federated deployments.)
Fleet Commander prototype / mental model
The federation controller that owns a Fleet and dispatches Missions across instances. The mental model: if Claude Code could command N Claude Codes, watching them run workflows until every requested piece of work was done.
What a Mission is — a workflow factory, not a bigger workflow
The leap is in who decides what runs. A Workflow is a fixed DAG decided up front — you draw the graph, then the engine executes it. A Mission decides what workflows to spawn as it learns: it fans out to many workflows in parallel, branches on their results, retries failed branches, and tracks multi-workflow lineage toward one objective. It is not a larger DAG; it is the thing that writes and launches DAGs until the goal reports done.
The target, stated as a goal — not a claim of shipped capability:
Picture one Fleet prompt: "Build AgenticWork and all its dependencies, with adversarial TDD." The Fleet Commander opens a Mission, spawns a workflow per service, each workflow spins up agents to write code, write the adversarial tests, run them, and route failures back as new work — across many flows and agents — until the objective reports done. That's the target. It is not shipped.
HITL is the safety rail at every layer. Today's human_approval and human_input gates already pause a workflow, checkpoint state, emit awaiting_approval / awaiting_input, and resume on a POST. Missions inherit those same gates at the objective level — escalate / approve / reject with timeout actions and notification channels (email, Slack, Teams, in-app). The objective never goes autonomous past a gate you set.
What's real today vs. on the roadmap
This is the honesty section. Be precise about which capability exists today and what it runs on.
| Capability | Status | Substrate |
|---|---|---|
| Workflow DAG engine (73 node types) | Real today | WorkflowExecutionEngine |
| Named agent types + per-agent model routing | Real today | AgentRegistry + SmartModelRouter |
| Signed, replay-verifiable execution traces | Real today | TraceCollector + HMAC signing |
| HITL approval & data-request gates | Real today | pauseForApproval / requestData |
| Sub-workflow invocation (parent calls child by ID) | Real today | sub_workflow node |
| Retry / fallback / error routing | Real today | error_handler + retry_with_backoff nodes |
| Mission state machine (spawn N workflows to one objective) | In active prototype | net-new orchestration layer |
| Multi-workflow lineage tracking | In active prototype | net-new |
| Fleet — federated multi-deployment work distribution | In active prototype | net-new (no fleet-registry yet) |
| Fleet Commander control plane | Prototype / mental model | net-new |
| Cross-deployment credential federation | On roadmap | today: OBO is per-deployment |
SubagentOrchestratorin the codebase is deprecated and ran parallel subtasks — it is not the Mission engine. There is no Mission table, no fleet-registry, and no inter-deployment routing today. We'd rather tell you that than imply otherwise.
Why Fleet & Mission matter for AIOps
Multi-agent orchestration is not a novel idea in general — we'll say that plainly. We did not invent federated agents, and we're not going to pretend we did.
What is new is bringing a governed, auditable, multi-workflow objective layer to AIOps specifically: incident response, fleet-wide remediation, drift correction across clusters. The substrate that makes that credible in an enterprise — signed traces, HITL gates, per-tool credential isolation, RBAC — already exists and is production-ready for single-instance use. The novelty isn't "agents talking to agents"; it's an operations objective that fans out across deployments while every action stays signed, gated, and attributable.
It ties straight into AIOps nodes already shipped in the OSS workflow engine: pagerduty_incident, servicenow_ticket, splunk_search, anomaly_detect, k8s_sandbox_run, grounding_check, and guardrails. A Mission is the layer that points many of those workflows at one operational goal.
Fleet topology & Mission lifecycle
Fleet topology and Mission lifecycle — the prototype hierarchy. Toggle the views.
For the architecture that ships today — services, data plane, the agent core, and the production-ready workflow engine these prototypes build on — see Architecture. For an enterprise deployment with SSO, multi-tenant, and managed controls, see AgenticWork.
Want to shape the Mission/Fleet roadmap with us? This is the part we're building now.