You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/mkdocs/en/sub_agent.md
+25Lines changed: 25 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,6 +21,19 @@ A **short-lived sub-agent** is a natural fit for these problems: a fresh context
21
21
22
22
The difference is *who defines the role*: the developer (Spawn) or the LLM (Dynamic).
23
23
24
+
### How this differs from other multi-agent mechanisms
25
+
26
+
The framework already offers several ways to compose agents (see [Multi Agents](multi_agents.md)). Spawned Sub-Agents solve a different problem:
27
+
28
+
| Mechanism | Agents involved | Who decides when to invoke | Context | Typical use |
29
+
| --- | --- | --- | --- | --- |
30
+
|**Chain / Parallel / Cycle Agent**|**Pre-built** fixed agent instances |**Deterministic** orchestration — run in list order / in parallel / in a loop, regardless of input | Each agent independent | Fixed multi-step workflows |
31
+
|**Sub Agents (transfer)**| Pre-registered agents | Parent **transfers control** at runtime; the sub-agent then takes over the conversation | Shared session |**Hand off** the whole conversation to a better-suited agent |
32
+
|**AgentTool**| Wraps **an existing agent instance** as a tool | Parent LLM calls it on demand | Shares/syncs state & artifacts back to parent | Reuse a **specific, already-built** agent |
33
+
|**Spawned Sub-Agents**|**Created on the fly** per call, destroyed after | Parent LLM calls it on demand |**Strictly isolated**: fresh ephemeral session, history/state not shared by default | Delegate a **one-off** subtask while keeping the parent context clean |
34
+
35
+
In one line: **Chain/Parallel/Cycle** deterministically orchestrate a fixed set of agents; **transfer** hands the conversation off; **AgentTool** reuses one existing agent as a tool; while **Spawned Sub-Agents** create an **isolated, short-lived** sub-agent on the spot for a single task and discard it afterward — the emphasis is on **on-demand runtime creation** and **context isolation**, not reusing an existing agent or transferring control.
36
+
24
37
## Quick Start
25
38
26
39
```python
@@ -173,8 +186,19 @@ class SubAgentConfig:
173
186
174
187
max_turns: int|None=None
175
188
"""Max LLM calls the sub-agent may make. None = unlimited."""
189
+
190
+
forward_events: bool=False
191
+
"""Whether to forward the sub-agent's execution events to the parent
192
+
runner's consumer as progress updates.
193
+
194
+
True: the orchestrator can display the sub-agent's execution live (model
195
+
output, tool calls, tool results); the parent agent's LLM still receives
196
+
only the sub-agent's final result. False (default): the sub-agent runs
197
+
silently and only its final result is returned."""
176
198
```
177
199
200
+
Forwarded events reach the consumer as progress events; they are **not** written to the parent session and **never** enter the parent agent's LLM context. Consumers identify them via `tool_progress=True` on `event.custom_metadata` and read the execution from `payload` (`author` / `partial` / `content`, plus optional `error` / `usage`).
201
+
178
202
## Usage
179
203
180
204
### SpawnSubAgentTool
@@ -270,3 +294,4 @@ orchestrator = LlmAgent(
270
294
-**Session isolation**: sub-agents run in a fresh ephemeral session. Parent history is not shared by default; opt in via `include_parent_history=True`.
271
295
-**Nesting**: 1-level hard cap. Sub-agents cannot spawn further sub-agents.
272
296
-**Result shape**: the sub-agent's final text is returned as the tool result string.
297
+
-**Live execution (`forward_events`)**: set `SubAgentConfig(forward_events=True)` to stream the sub-agent's execution to the parent runner's consumer for display. Forwarded events are progress events — they never enter the parent LLM's context, which still receives only the final result. Consumers detect them via `tool_progress=True` on `event.custom_metadata` and read `payload`. See `examples/dynamic_subagent` and `examples/spawn_subagent` for a working consumer.
0 commit comments