OAO coordinators can delegate work to named, versioned child agents. Each child
gets its own durable session and Flue instance, while every thread in the
delegation is bound to the coordinator’s workspace. This gives the child access
to files created by the coordinator without mixing their conversation histories.
Publish the roster first
A coordinator can call only delegates frozen into its immutable agent version:
agentVersionId is an exact immutable child version, not a mutable agent alias.
Delegate keys and version IDs must be unique. A coordinator can contain at most
32 delegates, and maxParallel is from 1 through 8. Publishing rejects a child
version from the coordinator’s own agent definition. The platform tool names
delegate_agent and message_agent are reserved.
Because the workspace is shared, coordinator and child versions must select
the same sandbox enabled state, provider key, snapshot, and network policy.
Their capability arrays may differ, so a child can receive a narrower set of
filesystem, shell, or browser tools. Publication also rejects direct or
indirect delegate cycles.
The console exposes the same roster under Agents → Delegates. Selecting an
agent records its latest version at publication time. A later child publication
does not change an existing coordinator version. Child versions with an
incompatible sandbox identity remain visible but disabled, with the mismatched
enabled state, provider, snapshot, or network policy explained beside them.
Runtime flow
OAO, not Flue’s ephemeral subagent helper, owns the durable relationship. The
runtime uses a separate registered ManagedAgent instance for each child
thread. PostgreSQL stores the coordinator-child relation, exact versions,
workspace binding, run sequence, idempotency hashes, and cancellation state.
The coordinator uses:
delegate_agent({ agent, prompt }) to create a persistent child thread;
- the returned
delegationId to correlate later work; and
message_agent({ delegationId, prompt }) to create another run in that same
child session after its previous run settles.
Different child versions can therefore carry different prompts, model presets,
Skills, tools, approvals, sandbox capability policies, and limits. The child is
still constrained by the shared sandbox’s provider and network boundary; its
Flue conversation and transcript remain isolated.
Durability and safety
- PostgreSQL is authoritative. Deterministic request keys make tool replay
return the existing delegation or child run instead of duplicating work.
- Before a platform tool claim, the runtime idempotently provisions its
tenant-scoped service principal. Internal broker or database failures become
a generic platform-tool failure instead of exposing database details to the
model or transcript.
- The platform tool claim behind
delegate_agent and message_agent holds a
bounded lease that the runtime renews on a heartbeat for as long as the child
runs, so a delegation that takes minutes still returns the child’s response
in one attempt. If another worker takes the claim over, the superseded
executor aborts its wait and stands down without submitting a result.
- Child threads use the normal fenced admission, wake recovery, product-run
deadline, and Flue retry paths.
- Cancelling or timing out a parent run cascades cancellation to its unsettled
children. Operators can also cancel a delegation directly.
- Parallel calls are allowed up to the published
maxParallel value. Each call
has a separate child thread but shares the workspace.
- Raw delegation prompts are stored only as authorized child transcript/run
input. Tool ledgers, product events, audit records, logs, and traces receive
IDs and bounded metadata such as character counts, never the prompt text.
- RLS repeats organization and project identity across every orchestration
relation. API reads and mutations require the delegation scopes documented in
HTTP API.
Operator follow-up
GET /sessions/{sessionId} includes delegations. The console renders links to
the persistent child sessions. The Sessions table also places every visible
child immediately beneath its coordinator with an indented tree connector;
the child uses a compact row treatment, and both rows remain direct links to
their own isolated transcripts. Filtered or
paginated results never hide an otherwise visible child merely because its
parent is outside the current result set.
An operator can submit a later child turn with
POST /delegations/{delegationId}/messages, using a fresh idempotency key, or
cancel the relation with POST /delegations/{delegationId}/cancel.
The MVP does not dynamically discover arbitrary agents, change a roster on a
published version, move a child to a different workspace, or merge child
conversation history into the coordinator. Human approval belongs to the
normal durable tool/approval flow; only after settlement should the
coordinator or operator send a follow-up to the same child.