delegation

A guide to child runs and task handoffs between agents. A child run repeats the current agent for a focused task, while delegation sends work to a different configured agent with its own identity and settings.

In plain words
What is it for?
Use it to decide when to spawn a focused child task, when to delegate to another agent, and what permissions and configuration each run receives.
Why use it?
These two ways of splitting work have different permissions, identities, and approval rules. Knowing the difference helps you choose the correct one safely.

Agent

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/zeroclaw-labs/zeroclaw/delegation
Clone the repo
git clone --depth 1 https://github.com/zeroclaw-labs/zeroclaw
Per session 0 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 6,892 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00000 $0.06892
Opus 5 $0.00000 $0.03446
Sonnet 5 $0.00000 $0.01378
Haiku 4.5 $0.00000 $0.00689

Measured yesterday against content hash f69e666619db, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

delegation scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

docs/book/src/agents/delegation.md · 240 lines

How it starts

The opening of the file, as written. The whole thing — 240 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Delegation & SubAgents

A SubAgent is an ephemeral child run spawned by a parent agent that inherits the parent's identity by default: same agent alias, same SecurityPolicy, same memory allowlist, same configured model provider, same tool registry. Auditable as a child via a tracing span agent.<alias>.subagent.<run_id>.

SubAgents are not a separate configuration concept. There is no [subagents.*] block in the schema. Every SubAgent's identity is whichever parent's agent loop spawned it.

When to use spawn_subagent vs delegate

Two tools sit nearby. They are not interchangeable.

  • spawn_subagent: runs the SAME agent again under its own identity for a focused subtask. The child sees the parent's full permissions envelope minus any narrowing. Use when the parent wants to scope an internal subtask out of its main conversation history without changing identity.
  • delegate: hands the request off to a DIFFERENT configured agent (named by alias). The target agent runs under its own identity and model provider, but delegation is gated: the caller's risk profile must set delegation_policy mode = "allow" (default is "forbidden"), and the target must be reachable as either a same-profile peer or an explicit delegates entry. Explicit entries choose mode = "bounded" or mode = "independent", which determines whether the caller's tool ceiling still applies. Use when another configured specialist should own the work. See Delegation gating below.

This page documents spawn_subagent end to end. delegate lives at crates/zeroclaw-runtime/src/tools/delegate.rs and is a separate surface.

How a SubAgent is instantiated

Two spawn sites converge on SubAgentSpawn (crates/zeroclaw-runtime/src/subagent/mod.rs:97):

  1. From an agent loop: the model calls the spawn_subagent tool with a prompt string. The tool is registered like any other in the registry (crates/zeroclaw-runtime/src/tools/mod.rs, SpawnSubagentTool::new).
  2. From cron: JobType::Agent jobs run through run_agent_job (crates/zeroclaw-runtime/src/cron/scheduler.rs) which builds the same SubAgentContext but flags the child as a top-level run (not a SubAgent) so it can itself spawn one level of subagent.

Read the full file on GitHub · 240 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 240 lines · 0 tokens per session scan A f69e666619db

Subscribe to this mod's changes

delegation is an agent published in the GitHub repository zeroclaw-labs/zeroclaw (32,680 stars, last pushed yesterday), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 6,892 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.