Skip to main content

One agent, several specialists

An Agent can hand part of its work to another Agent or Flow in the same workspace. The called agent or flow runs as its own session, on its own Setup and its own connections, acting as the same person the caller acts as - and its result comes back to the caller as a tool result. An orchestrator that knows the customer, a concierge that knows the warehouse, and a refund flow that knows finance can each stay small.

A session in which the support agent started three Order Status Concierge checks in the background: the fan-out block with two returned and one waiting, two delivery messages, and the running subagent above the composerA session in which the support agent started three Order Status Concierge checks in the background: the fan-out block with two returned and one waiting, two delivery messages, and the running subagent above the composer

In the Procedure, type @ and pick the Agent or Flow this one may call. Publishing the Setup records the link. The target must be in the same organization and already published, you must be allowed to run it, and an agent or flow cannot link to itself. The Linked tab on each agent lists what it calls and what calls it.

An agent's Linked tab: the agents and flows it calls and the ones that call itAn agent's Linked tab: the agents and flows it calls and the ones that call it

At run time the Agent sees the link as a tool. It can also look up what it may call and what a target expects - a Flow's declared inputs, an Agent's published principles - before calling.

Call and wait

The ordinary call runs the target and waits. An Agent target gets a prompt and returns its answer; a Flow target gets a typed input object and returns its output. The caller's turn is blocked while the child runs, so this is the shape for work the caller needs before it can continue.

In the transcript the call renders as a card naming the spawned subagent, its status, and a link to open its session. The child's own session shows Spawned from in its details panel, linking back.

If the child cannot finish on its own, the caller learns why rather than waiting blind:

  • It asked a question - the caller gets the question and answers it in its next step.
  • It hit a write gate the caller may decide - the caller gets the request and decides it.
  • It hit a write gate only a person may decide - the caller parks, and the session shows what it is waiting for, in the child's words. Anyone who can decide it can do so from Approvals or from the child's session; the caller resumes on its own.

Call in the background

Pass background: true and the call returns at once with a handle. The child runs on; when it finishes, its outcome arrives as a new message in the caller's conversation, labelled as having come back from that agent or flow, and the caller picks up from there on its next turn. While it runs, it is listed above the composer under Running in the background, with its last progress report and why it is paused if it is. A job is in one place or the other, never both.

To start several at once, an Agent uses the fan-out call: up to ten targets in one step, always in the background, each with its own row and its own session. A partial start is the normal outcome - the ones that started keep running and the refused ones are reported by reason - and only a fan-out in which nothing started fails.

Consecutive calls fold into one block in the transcript, with a running tally of returned, failed, waiting and running.

Talking back to the caller

A called agent has two tools it only gets when it was called by another agent or flow.

Report progress sends a one-way note to the caller - a partial result, a decision taken. It lands in the child's own transcript as Reported to caller, rides home with the final result, and is the first thing a person sees when they wonder whether the child is stuck or working.

Ask the caller stops the child and waits for an answer. The caller's Setup decides how many questions it will take per call - Delegation → Questions per call, three by default, up to ten, and 0 meaning this caller does not take questions. The budget is fixed when the call starts, so republishing mid-flight cannot change the terms. When it runs out the child is told plainly and continues with what it has. A question is not an approval: it never enters the Approvals inbox, and it expires on the same clock as an approval, failing the child's turn if nobody answers.

A subagent's session parked on a question to its caller: the question in the child's own words, a link to the calling conversation, and Spawned from in the details panelA subagent's session parked on a question to its caller: the question in the child's own words, a link to the calling conversation, and Spawned from in the details panel

Approvals inside a subagent

A child keeps its own Approvals. When it reaches a gated tool, the gate goes to the people who could always decide it. The child's author can additionally open a specific gate to callers - An agent or flow that calls this agent may approve it too, under that tool in the Setup - and only then can the calling agent or flow decide it. That adds a decider; it never removes the human one, and whoever decides first wins. A caller's decision is recorded as a system decision naming the calling execution, never attributed to the person whose conversation started the tree.

An organization-mandated tool approval applies to the child like to any agent, and a caller can never decide those.

Limits on a call tree

Three limits bound a tree, and none subsumes another. All three are enforced in the engine and adjustable per organization by Yekar.AI; the defaults are:

LimitDefaultRefusal
Call depth5AUTOMATION_CALL_TOO_DEEP
Direct children of one execution20AUTOMATION_CALL_TOO_MANY_CHILDREN
Descendants under one root100AUTOMATION_CALL_TREE_TOO_LARGE

A cycle - calling an agent or flow already on the stack - is refused with AUTOMATION_CALL_CYCLE. A child also counts against the called agent or flow's own Max concurrent runs, and against the workspace's concurrent-session ceiling like any session. Each refusal reaches the calling Agent as an ordinary tool error, so it can say what happened instead of retrying blindly.

Credentials and identity

The child runs as the same person, in the target's own domain, on the target's own bindings. If the caller's turn was started with a caller-supplied credential, the usable part of that credential is handed to the child, narrowed to the integrations the target binds at caller identity and capped at the parent's remaining time. A target that requires a caller credential cannot be started from another agent or flow at all (CALLER_MODE_NOT_CALLABLE); one that merely prefers it falls back to the domain's stored credential. See Caller credentials.

Cancellation

Cancelling a caller cancels everything open beneath it. A caller that fails or times out takes its open children with it. A child that fails or is cancelled wakes the caller with a failed call, and the caller's transcript says so. A cancelled background child whose caller has moved on is still delivered, so the caller learns what happened.

Cost and records

Each child is a full session: its own transcript, its own tool calls, its own cost card. The caller's cost excludes its children; the organization report attributes each to its own agent. The caller's transcript carries the call as a tool call whose result names the child session, so the audit trail links the two in both directions.

Flows

A Flow calls agents and flows with its Run an agent or flow step - a prompt for an Agent target, an input object for a Flow target - under the same links, limits and credential rules. A flow always waits; there is no background form, because a run has no conversation for a result to land in.