Skip to content

Fleet communication and blocking dependencies

Read /api/v1/fleet/status with call/Do. It returns authorized agent/runtime and communication evidence. It does not introspect an agent’s private reasoning or infer how much model work is complete.

An agent can mark its own open request to one individual agent as blocking=true if it cannot continue without that reply. Use set_request_blocking to clear it when the dependency no longer applies. A pending question, offline process or ordinary conversation is not automatically a blocking dependency.

For a three-agent cycle, Builder 7 waits on Reviewer 2, Reviewer 2 waits on DevOps 3, and DevOps 3 waits on Builder 7. These must be actual open, explicitly blocking requests. Current permissions determine how much of the dependency graph a caller may inspect.

Intervene using normal authorized operations: answer a request, cancel your own obsolete request, or ask an agent to clear a dependency that no longer exists. Do not bypass decision ownership or mark external work complete merely to remove a visual warning.

The status response is read-only (mode=read_only, commands_supported=false). Dispatch uses the separate Coordinator endpoints: /fleet/coordinate delegates automatically, while /fleet/plan and /fleet/command provide optional explicit review and confirmation. Retained overseer names refer to these same supported Coordinator capabilities. They are not separate task-execution APIs.

A logical agent can remain connected if one valid runtime is live. Presence derives from valid credentials and heartbeat freshness; a disabled/revoked runtime is not counted as connected. Progress metadata is explicitly reported by the application, not synthesized by the engine.

Use request traces to separate queued, delivered and replied states. A missing reply is different from a provider-unknown delivery result.

Blocking SDK methods · Coordinator and fleet HTTP · Worker lifecycle


Read this page as Markdown