> ## Documentation Index
> Fetch the complete documentation index at: https://docs.actionllama.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Subagents

> How one agent calls another — fire, poll, and collect results

Agents can call other agents to delegate work and collect results. This enables multi-agent workflows like planner → developer → reviewer pipelines.

## Use Case

A planner agent triages an issue and creates an implementation plan. It calls a dev agent to implement it, then calls a reviewer agent to review the PR.

## `call_agent`: Fire a call

Use the `call_agent` tool to dispatch a task to another agent:

```
call_agent(target_agent: "dev", context: "Implement the fix for issue #42 on acme/app")
```

The call is non-blocking — the calling agent continues working immediately. The tool returns a `call_id` for polling.

## `check_call`: Poll for results

Use the `check_call` tool to check if a call has finished:

```
check_call(call_id: "abc123")
```

Possible statuses: `pending`, `running`, `completed` (with return value), `error`.

## `return_value`: Send back a result

The called agent uses `return_value` to send a value back to the caller:

```
return_value(value: "PR #17 opened. Ready for review.")
```

The calling agent sees this value when it polls with `check_call`.

## Multi-call Pattern

Fire several calls, continue working, then poll for results:

1. Call multiple agents with `call_agent` — each returns a `call_id`
2. Do other work while they run
3. Poll each `call_id` with `check_call` until all complete

Do work between polls rather than polling in a tight loop.

## Complete Example: SKILL.md

Here's a planner agent that delegates to dev and reviewer:

```markdown theme={null}
# Planner Agent

You orchestrate development workflows. When triggered, you assess the issue,
create an implementation plan, and delegate to other agents.

## Workflow

1. Read the issue from the webhook trigger or search for labeled issues
2. Assess the issue — is it clear enough for development?
3. If not, comment asking for clarification and stop
4. Write an implementation plan as a comment on the issue
5. Use `call_agent` to call the dev agent with the implementation context
6. Poll with `check_call` until the dev agent completes
7. If dev succeeded, use `call_agent` to call the reviewer agent
8. Comment on the issue with the final status
```

## Rules

* **No self-calls** — an agent cannot call itself (the call is rejected)
* **Call depth limit** — chains like A → B → C are allowed up to `maxCallDepth` (default: 3)
* **Queuing** — if all runners for the target agent are busy, the call is queued (up to `workQueueSize`, default: 100)
* **No reruns** — called agents do not re-run. They respond to the single call.

## What the Called Agent Sees

The called agent receives an `<agent-call>` block in its prompt with:

* The name of the calling agent
* The context string passed via `call_agent`

The called agent's `SKILL.md` should handle this trigger type:

```markdown theme={null}
## Trigger handling

- **Agent call**: The `<agent-call>` block contains context from the calling agent.
  Do what was requested and use `return_value` to send back results.
```

## Next steps

* [Agent Tools](/reference/agent-tools) — full tool reference
* [Agents (concepts)](/concepts/agents) — runtime lifecycle and trigger types