Skip to main content
A multiagent coordinator is an ordinary Agent whose configuration includes a multiagent roster. It does not introduce another Agent type, deployment layer, or transcript.
When the coordinator Agent is created or materially updated, Checkfu creates the next immutable AgentVersion and resolves every roster member to an exact AgentVersion. A bare Agent ID resolves to its current Version at that moment; an object with version pins that Version; self selects the coordinator Version. Later Agent updates do not alter an existing coordinator Version or an admitted Session.

​
Addressability is not authority

The frozen roster defines which child Agents the coordinator may address. Live authority remains separate:
Removing or narrowing a live grant can deny new child work without rewriting the coordinator Version. Approval authorizes one frozen action; it does not execute the child task or prove an external effect completed.

​
One Session remains execution truth

Session admission freezes the coordinator AgentVersion and the selected Environment. Child work stays inside that Session as SessionThreads, Turns, Runs, and RunAttempts.
Harness-native subagents may be observed as an execution lane, but their native transcript never replaces the Checkfu Session event log.

​
Start a coordinator Session

Authenticated server context supplies durable actor attribution. Client event bytes do not choose a Principal or authored_by value.

​
Recovery and effects

A replacement worker creates another RunAttempt for the same durable Run. A checkpoint can preserve continuation material, but it does not settle a provider effect. When Checkfu cannot prove whether a child action reached an external provider, the effect remains indeterminate and must be reconciled through the provider’s authoritative lookup or idempotency mechanism.

Assemble a coordinator

Create the coordinator AgentVersion, start one Session, and follow child work.

Multiagent threads

Understand governed child calls, lineage, waits, and settlement.