Delegation

Delegation lets one AIP participant ask another participant to execute a child action while preserving identity, scope, lifecycle, and evidence.

It is intended for real multi-agent workflows, not only for calling two agents from the same process.

Parent and Child Actions

A delegation request contains:

• a stable delegation id;
• the parent action id;
• a complete child action;
• the requesting and target principals;
• the delegated scope;
• an optional callback;
• routing or scheduling metadata.

The runtime stores this as an edge in a durable action graph. The child action has its own policy, lifecycle, events, result, cancellation, transaction state, and receipts.

Remote Routing

A delegation router resolves the target principal or capability to an authenticated native HTTP or NATS route. The receiver verifies the immediate peer, expected principal, trust domain, capability, and immutable execution contract before dispatching the child.

Connector registration alone is not remote delegation. A connector invokes a product; a delegation route sends a first-class AIP request to another AIP peer.

Delegation Chain

Each hop records from, to, scope, and timestamp. The native validator limits the chain to ten entries. Deployments may impose a lower bound.

Every hop must narrow or preserve authority. A participant must not add scopes that were absent from its own authenticated grant. Federation context records the trust domains already traversed so policy can reject loops or forbidden boundaries.

Lifecycle and Results

Delegation states are accepted, running, completed, failed, cancelled, and requires-human. Terminal results contain either a child action result or a protocol error. Receipts link the delegation decision and observed result to the parent workflow.

Streaming child output can be projected into parent events, but the final child result remains the terminal authority. A model’s natural-language statement that another agent succeeded is not proof of delegated execution.

Cancellation

Cancelling a parent should propagate to active child actions according to the workflow policy. The parent cannot claim the child was cancelled until the remote peer or provider confirms a terminal state. Uncertain provider outcomes use reconciliation rules.

Security Checklist

• Authenticate each peer route explicitly.
• Match the transport identity to the declared delegate principal.
• Bind routes to allowed capabilities, scopes, tenants, and trust domains.
• Enforce a hop limit and reject cycles.
• Redact restricted context before crossing domains.
• Preserve parent-child correlation and idempotency across retry.
• Store and verify delegation receipts.
• Do not let model output create trusted delegation results.

Example Use Case

A customer-support agent receives a duplicate-charge complaint. It delegates a read-only billing investigation to a billing agent. If a refund is warranted, the child produces a transaction plan. The parent asks a supervisor for approval, commits the exact plan through a payment capability, and sends the customer a receipt-backed response. Every step is a separate, correlated AIP action rather than an unstructured conversation between models.