# Agent delegation Source: https://www.hyperagent.com/docs/concepts/agents/agent-delegation Split recurring work across named roles, then bring the specialist's result back to the orchestrator. **Agent delegation** lets one agent hand part of a job to another agent that is better equipped for it. You can direct several jobs yourself in one thread. Split the work into agents when the handoff should happen independently, recur without you, or use a different model, toolset, and knowledge boundary. A support orchestrator might send a technical question to a product specialist, then use that evidence to finish the customer reply. Hyperagent supports two delegation patterns: invoking another **named agent**, or creating a temporary **runtime helper** inside the current run. ## Named agents and Subagents [#named-agents-and-subagents] Invoke another **saved agent**. The specialist runs in its own child [thread](/docs/concepts/threads) with its own identity, model, tools, skills, integrations, and knowledge access. Use this for a durable role you have already staffed, such as Research, Writer, Finance Review, or Customer Support. Create a temporary helper **inside the current run** for isolated research or parallel busywork. It is not a saved agent with its own settings page. Use this when the parent needs extra hands for one turn rather than a persistent specialist role. ## Where delegation earns its keep [#where-delegation-earns-its-keep] The specialist needs a different prompt, model, toolset, or knowledge boundary. The handoff should be repeatable without you directing every step. A skill, a tool call, or a short internal helper is enough. Do not create a named agent only to move one tiny step elsewhere. Delegation can save money. Keep the orchestrator on the model that makes the hard judgment, then put recurring production or bulk gathering on a faster specialist. The quality budget stays where it matters. ## A working agent team [#a-working-agent-team] A good setup is a hub with clear specialist roles, not a chain of agents passing work forever. In this example, the Content Lead is the **Orchestrator**. It delegates research to the **Research Agent** and writing to the **Writer Agent**. Each specialist has its own prompt, model, tools, and knowledge access. The orchestrator receives the summary from the Research Agent, then briefs the Writer Agent with everything it needs to finish the job. Orchestrator Content Lead Owns intake, routing, quality bar, and final delivery. Specialist Research Agent Search, sources, notes, and factual uncertainty. Specialist Writer Agent Voice, structure, channel format, and final draft. The Content Lead sends a complete research brief, receives the evidence summary, then briefs the Writer. Because named-agent depth is capped at one, the Content Lead makes both handoffs. The Research Agent does not invoke the Writer. ## Set up the handoff [#set-up-the-handoff] ### Staff the specialist [#staff-the-specialist] **You configure:** create the named agent with the prompt, model, tools, skills, and knowledge it needs for one clear role. ### Allow the orchestrator to invoke it [#allow-the-orchestrator-to-invoke-it] **You configure:** add the specialist to the orchestrator's allowed agents and decide whether each invocation needs approval. ### Define when to delegate [#define-when-to-delegate] **You configure:** describe the boundary in the orchestrator's identity or a skill. Name the trigger, the specialist, and what a complete handoff brief must contain. ### The agent sends a complete brief [#the-agent-sends-a-complete-brief] **The orchestrator runs:** it invokes the allowed specialist with the goal, inputs, constraints, and definition of done. The child does not inherit the whole parent transcript. ### Finish with the result [#finish-with-the-result] **The orchestrator runs:** the specialist returns a summary to the parent. The orchestrator combines it with the rest of the work and delivers the user-facing outcome. ## Constraints [#constraints] * **One named-agent level.** The specialist returns to the orchestrator and cannot invoke a third named agent. Design hub and spoke, not chains. * **Allowed agents only.** The orchestrator can invoke only the specialists you make available to it. * **A full brief is required.** The child sees the handoff plus its own configuration, not the entire parent conversation. * **Approvals still apply.** Spawning a specialist may pause for approval, especially across shared or team-owned agents. * **Unattended write rules still apply.** A schedule, webhook, or Live Mode run does not gain permission to post externally simply because it delegated work. A webhook lets an external system start an agent. Delegation lets an agent start another agent inside Hyperagent. Keep those jobs separate. ## FAQs [#faqs] A person can @mention a named agent in a thread. An orchestrator can also invoke an allowed named agent during its run after you define the delegation boundary in its identity or a skill. Not with named-agent delegation. The depth limit is one. The specialist returns to the parent, which decides the next handoff. No. It receives the handoff brief and uses its own tools, skills, memories, and context. Include every input it needs. Use a named agent for a persistent specialist with its own configuration. Use a runtime helper for temporary parallel work inside one run. The orchestrator may need approval to invoke the specialist. Shared or team-owned agents can also require approval before another agent starts them. When the parent keeps the hard judgment and the specialist handles repeatable or high-volume work on a faster model. Extra handoffs are not automatically cheaper.