How Delegation Works
An agent withinvoke_agent in its tool allowlist can spawn child agents. Each child runs in its own pod and — if a Slack channel is configured — posts to the same thread as the parent.
To allow delegation, two things must be configured in the parent agent’s YAML:
invoke_agentmust be included intools.list- The child agent name must be listed under
agents_squad
Callback / Resume Pattern
For workflows where the parent needs the child’s result before continuing, passcallback_session_id to invoke_agent. The parent pod idles until the child calls notify_parent_session, then wakes up with the child’s output as its next input.
The parent does not idle forever: it stays alive up to its inactivity timeout (24 hours) and hard lifetime limit (48 hours). If the child takes longer than that, or fails to call back, the parent shuts down.
Limiting Delegation Depth
Depth is implicitly limited by whetherinvoke_agent appears in a child agent’s allowlist. If the test-maintainer above does not include invoke_agent in its tools, it cannot delegate further — the chain stops there.
This is the recommended approach: only give invoke_agent to orchestrator agents, not to leaf agents.
invoke_agent vs run_subagent
Both let an agent hand off work, but they are different mechanisms:
invoke_agentspawns a named agent (defined under.dinoai/agents/) in its own pod, running asynchronously with its own tools and Slack thread. Use it for durable, specialized agents and for the callback pattern above.run_subagentruns a lightweight, read-only research task in the same pod, synchronously, and returns its findings inline. It has no YAML definition, no Slack thread, and no callback. Use it for quick lookups where spawning a full agent is overkill.
Related
- YAML Configuration —
agents_squadandtoolsfields - Tools Reference —
invoke_agent,notify_parent_session,run_subagent - Examples — See tutorials on how to get started deploying agents