Skip to main content
A manager compares Airbnb stays in three cities. Each lane is a real h/web-surfer-flash child session, sped up 10x. The first Annecy subagent finds no match, so the manager spawns another.

How it works

Any agent becomes a manager by listing other agents in its subagents. You run it like any agent: one session, one result. Each child session is isolated, and the manager may spawn follow-ups to fill gaps or verify findings. Use it for work that splits, with one subagent per source, city, or site.

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.
The SDKs wait for the answer. Over raw HTTP, follow the manager’s session by the polling rules.

What a subagent sees

Watch 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 tree with group_id and list it with GET /sessions?group_id=....
  • Force an answer on the manager cascades to its subagents. Cancelling the manager stops its subagents too, with no grace window.
  • Subagents fail if you are at your concurrency limit.