Subgraphs let you compose complex agents from smaller, focused units. agent() streams their output through the same message, state, tool-call, and custom-event signals as the parent graph.
iSubgraphs vs subagents
LangGraph subgraphs are graph nodes. Deep Agents-style subagents are delegated tool calls. agent() requests subgraph streams by default, but the subagents() signal is populated only for tool calls whose names match subagentToolNames and whose args include a subagent_type.
The subagents() signal contains a Map of active delegated subagent streams. Use it when your graph delegates through tool calls, such as Deep Agents' default task tool or your own delegation tools. Plain subgraph nodes do not appear in this map.
const orchestrator = agent<OrchestratorState>({ assistantId: 'orchestrator', subagentToolNames: ['task', 'delegate_to_researcher'],});// All subagent streams (active and completed)const subagents = computed(() => orchestrator.subagents());// Only active onesconst running = computed(() => [...orchestrator.subagents().values()].filter((subagent) => subagent.status() === 'pending' || subagent.status() === 'running' ));const runningCount = computed(() => running().length);// Lookup helpers for common UI pathsconst specific = computed(() => orchestrator.getSubagent('research-tool-call-id'));const researchers = computed(() => orchestrator.getSubagentsByType('researcher'));// React to count changeseffect(() => { console.log(`${runningCount()} subagents currently running`);});
Each SubagentStreamRef exposes its own reactive signals — status, messages, and state — so you can surface granular progress in your UI.
// Access a specific subagent by its tool call IDconst researchAgent = computed(() => orchestrator.getSubagent('research-tool-call-id'));// Or get the subagents spawned by a specific AI message with tool callsconst messageAgents = computed(() => { const message = selectedAiMessage(); return message ? orchestrator.getSubagentsByMessage(message) : [];});// Track its progressconst researchStatus = computed(() => researchAgent()?.status());const researchMessages = computed(() => researchAgent()?.messages() ?? []);
The orchestrator pattern delegates specialised work to subagents and merges their results. Each subagent runs its own graph independently while the parent coordinates.
By default, subagent messages appear in the parent's messages() signal. Filter them out for a cleaner parent view.
const orchestrator = agent<OrchestratorState>({ assistantId: 'orchestrator', filterSubagentMessages: true, // Hide subagent messages from parent subagentToolNames: ['task'],});// Parent messages only (no subagent chatter)const parentMessages = computed(() => orchestrator.messages());
✓Subagent tool names
Set subagentToolNames to the tool names that spawn subagents. agent() uses this to identify tool calls that create subagent streams. Those tool calls must include a subagent_type argument for type-based lookup helpers such as getSubagentsByType().
Each subagent exposes its own status() signal. A failure changes that subagent's status to 'error' without necessarily stopping sibling delegates.
const agents = orchestrator.subagents();for (const [id, agent] of agents) { effect(() => { if (agent.status() === 'error') { console.error(`Subagent ${id} failed`); // Retry, surface to user, or fall back gracefully } });}// Collect all failed subagents reactivelyconst failedAgents = computed(() => [...orchestrator.subagents().entries()].filter( ([, agent]) => agent.status() === 'error' ));
!Partial failures
Always check failedAgents() before presenting final results. A completed orchestrator can still have subagents that errored — success at the top level does not guarantee all delegates succeeded.
Use subagents when tasks are independent and can run in parallel, when each task needs its own context window, or when you want isolated error boundaries. Use a single agent for sequential reasoning, tasks that share tightly coupled state, or when latency from spawning subagents outweighs the parallelism benefit.