Threads and delegation

An agent can hand parts of a task to other agents. Each piece of delegated work runs in its own thread inside the same session, with its own context, tools and budget. The main conversation is the primary thread; delegated work runs in delegate threads.

Why delegate

• Focused context. A research sub-agent reads twenty web pages; only its two-paragraph summary enters the primary thread.
• Different tools and permissions. The primary agent may talk to customers but not touch billing; a billing sub-agent can, behind approvals.
• Parallel work. Several delegates can run at once.
• Cheaper models for routine steps. A delegate can run on Amara Quick while the primary uses Amara S1.2.

Setting it up

List the agents the primary agent may delegate to in its definition:

{
  "name": "support-lead",
  "model": "Amara S1.2",
  "delegates": [
    { "agent_id": "agt_01JCC0B2D4F6H8K0M2P4", "description": "Looks up shipment tracking for an order id." },
    { "agent_id": "agt_01JCC0C3E5G7J9L1N3Q5", "description": "Checks refund eligibility and drafts refunds for approval." }
  ],
  "limits": { "max_parallel_delegates": 3 }
}

The model sees each delegate as a tool named after the delegate agent and decides when to call it. The description is what it reads, so describe when to use the delegate, not how it works.

What you see

List threads shows each thread’s cost, so you can see which sub-agent is expensive.

Rules

• Delegates can delegate further, up to a depth of 3.
• Each delegate’s usage counts toward the session’s budget; a delegate can also have its own lower budget.
• Approvals requested inside a delegate surface on the session like any other approval.required event, tagged with the delegate’s thread_id.
• Interrupt a thread stops one delegate without stopping the session.