# Other agents Source: https://www.hyperagent.com/docs/concepts/agents/invocations/other-agents > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Let one named agent hand specialist work to another, with controls on who can call it and what each agent can do. You have a support agent that fields customer questions all day, and some of those questions belong with the product specialist down the hall. Instead of answering outside its depth, the support agent hands that question to the specialist, gets an answer back, and finishes the reply. **Other agents** is the invocation that lets one named agent start work for another. The caller writes the brief. The specialist runs in its own thread with its own instructions, model, tools, skills, and knowledge, then returns the result. Delegation lets a capable generalist bring in a specialist for the part of a job that specialist does best. It takes consent on both sides: the caller has to be allowed to delegate, and the specialist has to be willing to be called. ## How delegation works [#how-delegation-works] The caller invokes another agent by name. The agent it calls runs in its own brand-new [thread](https://www.hyperagent.com/docs/concepts/threads) with a fresh context window, does the work with its own prompt, model, tools, skills, and knowledge, then returns a short result. Nothing of the caller's conversation crosses over except the brief the caller writes for the handoff. During a run, the parent agent calls an allowed specialist by name and sends a brief: the goal, the inputs, and what a finished result looks like. Hyperagent opens a new thread on the specialist with a clean context window. It carries the specialist's own configuration, not the parent's history. The parent's transcript shows a card with the specialist's summary, a status pill, and a link into the specialist's thread so you can read the full run. The specialist hands its result back to the parent and cannot invoke a third agent. Delegation is one level deep by design, so chains stay legible. The parent's runner pays for the delegated run, and the specialist's budget is clamped to the parent's cap. A delegation can never spend more than the run that started it. ### The result card in the parent thread [#the-result-card-in-the-parent-thread] When a delegated run finishes, the parent thread shows a card for it. The card carries the specialist's name, a summary line of what came back, a status pill, and a **View thread** link that opens the specialist's own thread. The specialist is still working. The card shows elapsed time while the run is in flight. The run completed and the summary and View thread link are ready to read. The run started but could not complete. Open the thread to see what went wrong. The specialist could not be reached to run, so no work happened. ## Consent on both sides [#consent-on-both-sides] Delegation only happens when both agents agree to it. The caller has to be allowed to delegate, and the agent being called has to permit other agents to invoke it. Neither side alone is enough. On the caller's Autonomy tab, the Agent delegation section turns delegation on and holds the allowlist of agents this one may invoke, up to 500 agents. A workspace mode instead includes your other agents automatically. On the specialist's Invocations tab, the Other agents row controls who is allowed to invoke it as a sub-agent. Its chat, schedules, and channels are unaffected. ## Execution modes: Auto and Ask first [#execution-modes-auto-and-ask-first] Every agent acts in one of two modes while you are in conversation with it. The mode is set on the Autonomy tab and a thread can override it per-conversation. Agent runs everything end-to-end without stopping. Agent pauses for approval before sensitive actions. Heads up: this is a behavioral preference the agent follows, not a sandbox. Use Ask first for oversight, not for adversarial isolation. ### Ask first when nobody is watching [#ask-first-when-nobody-is-watching] Ask first works by pausing for a person to approve. That means it only applies where someone is present to answer. When a run happens on its own, on a surface with no approval to give, there is nobody to unblock the pause. On those surfaces the run either refuses or folds to Auto rather than hanging, so an unattended run never stalls waiting for an approval that can't arrive. ## The approval card [#the-approval-card] When the caller is set to ask for approval before delegating, a delegation doesn't start on its own. Instead, a card appears in the parent thread asking for your OK, and the specialist runs only after you approve it. The card shows the specialist's name and the prompt the caller wants to send, with Approve and Deny controls. The card switches to the specialist running, with a View thread link into its work. The card reads Denied - Research Agent was not invoked. and nothing runs. If a pending delegation is interrupted before it finishes, the card asks you to run it again rather than leaving the request half-started. ## Subagents are not delegation [#subagents-are-not-delegation] Both can divide work, but they solve different problems. The specialist has its own identity, instructions, tools, knowledge, and thread. Use delegation when the work belongs to a durable role you want to configure, trust, and inspect independently. A run may dispatch anonymous workers inside the same thread for short-lived legwork. They have no settings page and disappear when the work ends. The thread's Subagents setting chooses only their model. ## Trace a delegated run [#trace-a-delegated-run] A delegated run lives in the specialist's own **Activity**, the same place all of that agent's threads appear. Each row opens the thread where the work happened. From the parent side, the result card's **View thread** link takes you straight into that thread, and the run carries provenance back to the parent thread that started it. Because delegation is one level deep, tracing a delegation is a single hop from caller to specialist and back. ## Trust and tool access [#trust-and-tool-access] A delegated run is treated as external content for learning purposes. The brief the caller sends arrives in the same trust class as content that came from outside, kept separate from what you yourself wrote, so a specialist doesn't learn from a caller's prompt as if a person had typed it. What a specialist can actually do is governed by its own tool access, not the caller's. Delegating work to an agent doesn't lend it any capability it wasn't already configured with. If a specialist can't send email on its own, it can't send email just because another agent asked it to. ## FAQs [#faqs] A delegation is refused before any work starts for one of three reasons: the specialist isn't on the caller's allowlist, the specialist doesn't permit other agents to invoke it on its Invocations tab, or the call would go past one level deep. Fix the one that applies and the invocation goes through. No. Delegation is one level deep by design. The agent you call returns its result to the caller and cannot invoke a third agent. Design a hub with specialists around it, not a chain of handoffs. The caller's runner. The specialist's budget is clamped to the caller's cap, so a delegated run can never spend more than the run that started it. No. Heads up: this is a behavioral preference the agent follows, not a sandbox. Use Ask first for oversight, not for adversarial isolation. What a specialist can do is set by its own tool access, not by the caller's execution mode. No. It runs in its own new thread with a fresh context window and receives only the brief the caller writes for the handoff. Include every input it needs to do the work.