# 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.