Documentation / guides
Overview
Allow declared Loops to start and coordinate bounded delegated work.
Delegation is a capability of a declared Loop topology. A parent Loop can start, message, interrupt, and inspect only the direct child Loops named by its immutable definition. The Rig owns the topology and the session runtime owns admission, delivery, restore, and shutdown.
The public boundary is deliberately small. Application code declares
loop.WithDelegates and, when needed, loop.WithDelegation, registers the
definitions with rig.WithLoops, and uses the Session and Loop contracts. The
runtime injects the parent-scoped AgentTools bundle. There is no public
generic hustle execution entry point and a tool never receives a
SessionController.
Topology first
The Rig validates a directed graph from every configured primer. Delegate names must name registered Loop definitions, and every registered definition must be reachable from a primer. A Loop definition can be frozen before the Rig checks its target names; Rig definition is the boundary that makes the complete graph valid.
%%{init: {"theme":"dark"}}%%
flowchart TD
R[Rig definition] --> P[primer Loop]
P -->|declared delegate| C[direct child Loop]
C -->|declared delegate| G[grandchild, depth checked]
P -.->|other child or ancestor| X[not in controller scope]Proof: Rig graph validation and topology tests.
One parent-scoped controller
The injected bundle has ListAgents, MessageAgent, StartAgent, and
StopAgent operations. Each call reaches a tool.DelegateController scoped
to the parent Loop. The controller rechecks the operation, allowed target,
mode, runtime selection, ownership, interrupt barrier, and session health even
when a tool request was already schema-checked.
Proof: delegate controller construction and scope and tool contract tests.
Durable lifecycle
Starting a child crosses a durable admission barrier before child events or gates can escape. Messages report delivery separately from the child’s response status. A caller context can retract work before actor acceptance; after acceptance the session owns the request. Durable intent, delivery phases, turn terminals, and cancellations let restore decide whether to resolve, reconcile, or classify work as interrupted.
Proof: delegation admission and delivery and restore tests.
Choose a page
- Declare delegates freezes names, styles, and Rig reachability.
- Start and message delegates documents the exact tool operations and result fields.
- Delivery and cancellation explains acceptance, response observation, and cancellation ownership.
- Limits and authority covers depth, quota, runtime selection, and parent authority.
- Restore delegated work describes durable reconstruction and shutdown-safe handback.
Proof: public delegation definitions and session contracts.