-
Notifications
You must be signed in to change notification settings - Fork 162
feat(agent): read-only subagent delegation for long tasks #3383
Description
A GAIA agent cannot ask another agent to do anything. Everything a task requires — every file read, every search, every page fetched — has to happen in the one context window, and on a local model that window is 32K or 64K. Long investigative tasks therefore hit a hard ceiling: not because the agent cannot reason about them, but because it cannot hold them.
The shape that solves this is one writer with read-only helpers. The helper does the expensive reading in its own context and returns a conclusion; only the conclusion comes back to the parent. Delegation here is a context strategy first and a parallelism strategy second, which is why it matters more on a small local model than on a frontier one.
Write capability stays with the parent. One writer avoids the concurrent-edit problem entirely, and helpers do not need it to be useful.
Acceptance criteria
- The base agent can spawn a bounded sub-agent and receive a text result.
- Sub-agents are read-only — write and edit tools are not available to them, enforced at registration rather than by prompt instruction.
- The sub-agent runs in its own context; only its returned conclusion enters the parent's history.
- Depth is capped at one level and fan-out is capped at a stated number of concurrent children, so a runaway cannot spawn indefinitely.
- Sub-agent step budget is separate from the parent's, and exhausting it returns a partial conclusion rather than failing silently.
- Cancellation propagates from parent to children, leaving no orphans.
🔍 Technical details
No delegation primitive exists: grepping src/gaia/agents for spawn/delegate/subagent turns up only goal_store.py's Goal/Task hierarchy, which is a work queue, and console references. The planning structure assumes one agent executes every step of its plan itself.
Scope boundary worth stating, since it is easy to conflate: this is in-loop delegation inside a single agent run. It is not the distributed multi-agent mesh tracked in the "Agent Mesh: Distributed Agents with Delegation" milestone (#2269, #2271), which is about cross-process contracts, permissions and packaging. This issue needs neither. If the mesh work later supplies a transport, this should adopt it rather than duplicate it.