Delegate work to another agent

A supervisor agent can hand a task to a specialist agent: “summarize this thread”, “reconcile this invoice”. Tanomis treats the hand-off as a governed call between two versions in the same tenant, with the callee’s authority narrowed to what the caller was allowed to give it.

Availability: Runtime delegation is enabled per platform deployment; where it is off, the delegation tools are absent from the agent’s bind. See What is available where.

At a glance

• The caller lists the agents it may hand work to under delegation.calls.
• The callee lists who may call it under delegation.accepts, and optionally the skills it offers. Without skills it exposes one default skill that takes a prompt.
• The two manifests are the grant. Nothing is created out of band, and nothing has to be redone when either side deploys a new version.
• Every attempt, admitted or refused, is a ledger event carrying the full authority chain.

Declare the two halves

The callee advertises what it accepts:

agent.yaml (callee)

delegation:
  accepts:
    - tenant
  skills:
    - name: summarize
      description: Summarize a support thread and return the key facts and the customer's ask.
policy:
  scope_ceiling:
    - "llm:your-model-family:invoke"

The caller names the agents it may call:

agent.yaml (caller)

delegation:
  calls:
    - summarizer
policy:
  scope_ceiling:
    - "llm:your-model-family:invoke"

Naming a target puts the delegation tools on the caller’s bind and is the caller-side ceiling: an agent cannot reach a callee it did not name. Whether any particular call is permitted is still decided per call. Renaming a skill is a breaking change for every caller that lists it.

How a call is decided

On each delegation the control plane, not the agents, decides:

1. The caller and callee versions are resolved from platform-attested identities, not from anything the agent claims. The callee is the version currently enabled for the tenant.
2. The caller’s manifest must name the callee (and, if narrowed, the skill) under calls, and every enabled callee version must name the caller under accepts and offer the skill with one contract.
3. The callee’s effective authority is the intersection of what the caller holds and the callee’s own scope_ceiling. A scope the caller does not hold is a hard refusal, never a silent trim. An agent with no ceiling cannot receive a delegated grant at all.
4. Tenant policy is evaluated with the tenant’s posture.
5. The decision is recorded, and only then is the callee’s run dispatched.

Authority narrows at every hop and never widens. A callee that delegates further can only pass on what it was granted.

What the caller does at run time

The caller sees a small set of tools:

Tool	Purpose
start_delegation	Hand a skill invocation to a callee and receive a delegation id
await_delegation	Wait for the result; the caller can be suspended while it waits, so waiting costs nothing
check_delegation	Read the state without waiting
list_delegations	See the delegations this run started
update_delegation, cancel_delegation	Adjust or withdraw work that has not completed

The callee runs as its own session and run in the same tenant, with the same event stream, approvals, and evidence as any other run. The caller’s run resumes when the result arrives.

Evidence

Each attempt produces one agent.delegate audit event with the caller, the callee, the skill, the narrowed scopes, the authority chain, and the decision, whether it was admitted or refused. Read it with tanomis org audit; see Audit and evidence.

Where to go next

• Identity and access: the two identities on every request and why delegated authority narrows.
• Agent manifest: every field in the delegation block.