The Workflow Graph
An orchestration is a directed graph of metadata, nodes, and edges, a document, not a script. What makes it dependable is what surrounds the graph: edges are guarded by a sandboxed expression language that never runs arbitrary code, a durable journal lets a peer cell resume a dead coordinator's run from the last completed entry, and placement treats clearance and topology as hard constraints before it ever weighs cost.
For agent teams, the blackboard mesh, distributed jobs, and cross-platform interop, see Orchestration & Agent Teams.
A workflow, and the registry that runs it
Figure D6: a workflow graph. Execution is topological with parallel batching; a conditional edge (cyan) is decided by a sandboxed serialisable DSL that never executes arbitrary code; a gate node (amber) is a net-effect boundary that can refuse; a human_approval node holds for quorum. Every completed step is written to a durable journal and signed with the executing cell's identity (green). This is one graph drawn from the fourteen registered node executors listed below.
Table equivalent
| Node in the figure | Registered executor | Role |
|---|---|---|
| agent | agent | Runs an agent |
| parallel | parallel | Topological batch fan-out |
| tool | tool | Invokes a governed tool |
| skill | skill | Invokes a skill |
| join | join | Merges branches with one of three strategies |
| conditional | conditional | Branches on a sandboxed-DSL condition |
| gate | gate | Net-effect decision boundary: can refuse |
| human_approval | human_approval | Holds for quorum or two-person confirmation |
| completed | (terminal) | Journalled with a cell-identity signature |
Fourteen registered executors, and nothing above that
The default executor registry wires exactly fourteen node types. Quoting a larger number is an overclaim the platform explicitly warns against.
| Executor | What it does |
|---|---|
join | Merge branches (three merge strategies) |
gate | Net-effect decision boundary that can refuse |
parallel | Topological batch fan-out |
climb | Iterate toward a target under governance, rather than looping freely |
skill | Invoke a skill |
agent | Run an agent |
tool | Invoke a governed tool |
conditional | Branch on a sandboxed-DSL condition |
human_approval | Hold for quorum / two-person confirmation |
inbox | Wait for a message on a per-agent inbox |
consensus | Reconcile several agents' answers into one |
service_call | Call a platform service: subsumes the former six per-service nodes (data, storage, catalog, messaging, security, metrics) |
subgraph | Run a nested workflow |
contract | Evaluate a governed contract |
A single service_call executor replaced what were once six per-service nodes.
Names that appear in older catalogues, broadcast, team, checkpoint, retry,
timeout, reflect, loop, have no registered executor. A python node exists
as an executor class but the default registry does not wire it in. So the
honest ceiling is fourteen registered executors, do not quote a higher number.
Edges never execute arbitrary code
Edges may be conditional, but a condition is written in a sandboxed, serialisable expression DSL evaluated by a purpose-built interpreter that never executes arbitrary code. Execution is topological with parallel batching and three merge strategies. This is the difference between a workflow you can admit into a regulated environment and one you cannot: a graph's control flow is data, not code smuggled through a condition string.
Durable journal and peer resume
Every run writes intent → executing → completed/failed journal entries, each carrying an input hash, an output hash, the executing cell, and a cell-identity signature, through a write-ahead log with an audit chain over the journal.
Because the journal is durable and a coordinator holds its run under a lease with compare-and-swap renewal, a peer cell can resume a dead coordinator's workflow from the last completed entry, and an external auditor can replay and verify the run from the journal alone. This is the same durability the Agent Runtime provides for single agents, applied to a whole graph.
The placement ladder: hard constraints first
Placement is a governed decision, not a scheduler detail. Candidate cells are scored against a strict ordering:
| Order | Criterion | Kind |
|---|---|---|
| 1 | Topology | Hard constraint: a candidate that fails is excluded |
| 2 | Clearance | Hard constraint: a candidate that fails is excluded |
| 3 | GPU availability | Preference |
| 4 | Model availability | Preference |
| 5 | Data locality | Preference |
| 6 | Cost | Preference, penalised by load |
Topology and clearance are evaluated first and as hard constraints, so a job is never placed somewhere its clearance or topology forbids in order to save cost. Only after the hard filter do GPU, model availability, locality, and cost rank the survivors.
Related topics
- Orchestration & Agent Teams: teams, the blackboard mesh, distributed jobs, and interop.
- Agent Runtime, the durable journal and lease-based resumption the graph inherits.
- The Net Potential Gain (NPG) gate, what a gate node routes through.
- Platform Architecture → Cell Model, the mesh placement spans.