Skip to main content

Orchestration & Agent Teams

Single agents do focused work; real work is composed. This area covers how agents are shaped into teams, driven by a workflow graph, addressed as signed jobs, and composed across cells and to the edge, with placement treated as a governed decision, not a scheduler detail.

The workflow graph​

An orchestration is a graph of metadata, nodes, and edges. The default executor registry wires exactly fourteen node types: join, gate, parallel, climb, skill, agent, tool, conditional, human_approval, inbox, consensus, service_call, subgraph, and contract, where climb iterates toward a target under governance rather than looping freely, and a single service_call executor subsumes what were once six per-service nodes (data, storage, catalog, messaging, security, metrics).

A python node exists as an executor class but the default registry does not wire it in, and older catalogue names, broadcast, team, checkpoint, retry, timeout, reflect, loop, have no registered executor. Do not quote a node-type count above fourteen. See The workflow graph for the full registry, the placement ladder, and peer-resume.

Edge conditions never execute arbitrary code

Edges may be conditional, but conditions are written in a sandboxed, serialisable expression DSL evaluated by a purpose-built interpreter that never executes arbitrary code. Execution is topological with parallel batching.

Every graph runs on the Agent Runtime, so it inherits the durable journal, the lease-based resumption, and the external-replay guarantees described there. Templates span enterprise, security, governance, and industry categories.

Agent teams​

A team is a structured thing, not a swarm:

  • A formation is the shape of a team.
  • A billet is a post in a formation, the role, independent of which agent fills it.
  • A crew is a formation instantiated with agents in those posts.
  • A blueprint is a reusable agent or team definition.

A formation budget policy splits a budget across the team rather than handing each member an unbounded one.

Coordination without a manager​

Spawned peer agents coordinate through a shared tiered blackboard, posting, claiming, and completing tasks, with no manager relay. Each action is attributed to the acting agent and scoped to the team. This is genuine mesh coordination rather than a supervisor fanning out work and collecting results.

When several agents produce answers, a consensus engine evaluates agreement, resolves conflict, and produces a unified result, available as a workflow node type as well as a service. An expertise tracker scores agents by domain from outcomes, and a specialisation router sends work to the best-suited agent by skill match and current load, using dispatch patterns including fan-out, negotiation, and auction.

Communication​

Agents do not talk over a side channel, they use the platform's messaging service, so their conversations inherit classification, workspace scope, audit, and durability:

  • per-agent inboxes for point-to-point delegation, with an inbox node so a graph can wait for a message;
  • team topics for broadcasts and status, and per-workflow channels for run coordination;
  • typed messages: task delegation, task result, status update, negotiation, escalation. That are durable and survive a cell restart, delivered across cells by messaging replication.

Distributed agent jobs​

Separate from the workflow graph, a unit of work can be a signed job envelope addressed from one entity to another and carried over the entity messenger. The receiver verifies the seal against the sender's published signing key, binds the envelope's authority, re-derives tenancy on the receiving cell, de-duplicates on the request id, and hands the job to the executor registered for its type. The authority written into the record is the envelope's, not the receiving node's.

Why this is different from a queue. A queue entry is anonymous work in a pipe. Here the unit of work is addressed from an identity to an identity and signed, so who asked for this, who ran it, and under whose authority is a property of the job itself, not something reconstructed from logs afterwards.

What is reachable today

The seal → send → verify → execute path is mounted and reachable behind a live route on the node's front door. The wider job plane around it, the dispatcher, router, placement (including edge placement), work stealing, the job ledger, the coordinator, and the state machine, is built and tested but not yet wired. This is a wiring gap, not an unbuilt one. In particular, placing a job on a field device is not a present-tense capability.

Composition across cells and to the edge​

The estate is a mesh, and orchestration spans it:

  • Cross-cell dispatch routes a task to the best-equipped cell; agent migration rebalances load or survives failover; partition resilience maintains function during a split.
  • Placement scores clearance and topology as hard constraints before cost and availability (see Agent Runtime → Placement).
  • Roll-up. Workspace-level state aggregates into a node-level view, so an operator sees the whole estate rather than one cell at a time.

Governed federated cognition​

Reasoning can be distributed across cells through conductor, leaf, and reduce trees with capacity adverts, egress gating, and model routing. At the edge, a device runs a federated-cognition leaf that can be promoted to sub-conductor when the cloud goes dark, so a disconnected group of devices can still answer a question among themselves. The promoted device runs a deterministic decomposition (rule-based plus a small local model, never a frontier one), the role is held under a lease so two devices cannot both claim it, and under adversarial disconnection it answers inconclusive rather than guessing.

Cross-platform agents​

The platform interoperates with other vendors' agent systems in both directions, targeting the current GA release of the open Agent2Agent specification:

  • As a producer, it serves a signed agent card at the specification's standard well-known discovery path (a detached JSON Web Signature over the canonicalised card), publishes its keys at a JWKS endpoint, and implements the task lifecycle with push-notification webhooks.
  • As a consumer, it keeps a workspace-scoped registry of external agents it may delegate to, with credential by reference rather than embedded secrets, and trust-on-first-use pinning of the counterparty's signed card so a silently swapped identity is detected.

Every crossing is on the audit chain, with per-agent cost attribution on both sides, an interop surface with an accountability model attached, rather than a walled garden with an API.

See also​