Skip to main content
Hyperagent

Other agents

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.

Your agents can work as a team

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

The caller invokes another agent by name. The agent it calls runs in its own brand-new thread 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.

01 · Invoke

The caller invokes an agent by name

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.

02 · A fresh thread

The specialist runs in its own thread

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.

03 · Result card

A card returns to the parent thread

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.

04 · One level deep

The specialist returns, it does not chain

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

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.

A result card in the parent thread: Research Agent with a Finished pill, a note that Support Agent delegated it, a one-line summary of what came back, and a View thread link
The specialist's result lands in the parent thread. View thread opens its full run.

Running

The specialist is still working. The card shows elapsed time while the run is in flight.

Finished

The run completed and the summary and View thread link are ready to read.

Failed

The run started but could not complete. Open the thread to see what went wrong.

Unavailable

The specialist could not be reached to run, so no work happened.

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.

Caller

The Autonomy tab enables delegation

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.

Callee

The Invocations tab controls who may call it

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.

Choose how the agent acts in conversation

Auto runs everything end-to-end. Ask first pauses for approval before sensitive actions. This setting applies while you're in the conversation.

Compare Auto and Ask first.

The caller agent's Autonomy tab, showing the execution mode control and the Agent delegation section

Turn delegation on and pick the audience

Choose Do not delegate, a workspace mode that includes your agents automatically, or Selected agents with an explicit allowlist.

The Ask for approval before delegating toggle decides whether each delegation waits for your OK.

The caller agent's Autonomy tab, showing the execution mode control and the Agent delegation section

Name the agents this one may invoke

In Selected agents mode, add each specialist this agent is allowed to call. The allowlist holds up to 500 agents.

Each named agent must also permit callers on its own Invocations tab, or the invocation is refused.

The caller agent's Autonomy tab, showing the execution mode control and the Agent delegation section
The caller's Autonomy tab. Select a region to see what it controls.

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.

Auto

Default

Agent runs everything end-to-end without stopping.

Ask first

Agent pauses for approval before sensitive actions.

Ask first is oversight, not isolation

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

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.

A pending approval card: Support Agent wants to delegate to Research Agent, the exact prompt it wants to send in quotes, and Approve and Deny buttons
The card shows the exact brief before anything runs. Approve starts the specialist; Deny means nothing was invoked.
Pending

Approve or Deny the delegation

The card shows the specialist's name and the prompt the caller wants to send, with Approve and Deny controls.

Approved

The specialist starts running

The card switches to the specialist running, with a View thread link into its work.

Denied

No agent was invoked

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

Both can divide work, but they solve different problems.

Named role

Delegation calls another agent

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.

Temporary worker

Subagents add parallel hands

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

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

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