Skip to main content
Any agent becomes a manager by listing other agents in its subagents. You run it like any agent: one session, one result. Behind it, the manager splits the task, runs each piece as an isolated child session in parallel, may spawn follow-ups to fill gaps or verify findings, and merges the results. It pays off on parallel work: collecting data from many sources, pairing a fast text-mode searcher with a visual subagent for pages that need real clicks, or having one subagent verify another.

Build a manager

Create the subagents, then reference them by name from the manager so each stays reusable and inspectable (inline agent objects also work for one-offs).
  • Write each subagent description as a capability statement (“Use for…”): the manager routes on it, the same way an agent routes on a skill.
  • A manager that only delegates sends environments: []. Give it one only if it should also act on a surface itself.
From the CLI, run an existing manager with hai run --agent research-orchestrator "...". Over raw HTTP, long-poll changes until the session is terminal before reading latest_answer.

What a subagent sees

Observe and control the tree

  • The manager’s status lists its children in subagent_session_ids. Retrieve or watch any of them like a normal session.
  • List children with GET /sessions?parent_session_id=..., or tag a whole run with group_id and list it with GET /sessions?group_id=....
  • Force an answer on the manager cascades: in-flight subagents get about 30s to wrap up, partial results fold into the manager’s answer, and anything unfinished is cancelled. Cancelling the manager stops its subagents too, with no grace window.
  • Child sessions never queue: at your concurrency limit, a child create fails with 429.
Related: Watch and steer sessions, Get typed answers