Agentic Data Engineering Resources

Resource

What Are Subagents? How Modular Agent Systems Split Work Without Losing Shared Context

Learn how subagents split work across context windows, share state without sharing everything, and power production-ready multi-agent systems.

Airbyte Engineering Team

June 24, 2026

Summarize with AI:

Subagents are AI agents that a parent agent delegates work to when a task is too large, too noisy, or too specialized for one context window. They matter because splitting work can improve speed and focus, but it also creates a shared-state problem that determines whether the system works in production.

A subagent operates under a parent agent's direction to handle a bounded piece of a larger task. It executes autonomously within its own context window and returns a condensed result to the parent. The production tension sits at the boundary between subagents: splitting work creates a context fragmentation problem, and how you manage shared state across those boundaries determines whether the system works beyond a demo.

TL;DR

Subagents are child agents that handle bounded tasks under a parent orchestrator and return condensed results.
Their main benefit is context isolation: they keep intermediate tool outputs out of the orchestrator's context window.
Shared state works best through scoped checkpoints, external stores, or pre-materialized context layers rather than full history sharing.
Subagent systems work in production when orchestration, context boundaries, and unified business data are designed together.

What Is a Subagent and How Does It Differ From a Multi-Agent System?

A subagent is an agent that a parent agent invokes via a tool call to handle a specific, bounded task. It runs its own multi-step reasoning loop, uses its own tools, and returns a distilled summary, often 1,000 to 2,000 tokens compressed from tens of thousands of tokens of internal work.

This differs from a multi-agent system, where multiple agents operate as peers and hand off tasks based on specialization. It also differs from agents-as-tools, where the calling agent invokes a stateless function with no persistent conversational context.

Arrangement	Definition	Who Owns Flow Control	When to Use
Single agent	One autonomous actor takes a goal and executes the complete workflow	The agent itself	Tasks that stay within one context window and one domain
Subagents	A parent agent (orchestrator) delegates bounded tasks to child agents it controls	The parent orchestrator	Tasks that require parallelization, context isolation, or exceed a single context window
Multi-agent system	Two or more independent agents collaborate as peers; no single agent controls the others	Distributed or negotiated	Tasks where no single agent has the authority or knowledge to coordinate the full workflow

How the Orchestrator-Worker Pattern Works

The orchestrator-worker pattern is the most common production shape for subagent systems. A lead agent receives a complex query, breaks it down, and dispatches the pieces to subagents that work in parallel. Each subagent runs in its own context window and returns only a condensed result, so the orchestrator stays focused on coordination rather than execution detail.

Here is how a typical run unfolds:

Decomposition: The lead agent analyzes the query and splits it into bounded subtasks that can run independently.
Task specification: Each subtask is defined by an objective, an output format, guidance on tools and sources, and explicit boundaries.
Parallel execution: Subagents execute concurrently, each isolated in its own context window with its own access to tools.
External offload: Heavy artifacts are written to an external store, and only lightweight references are passed back to the coordinator.
Aggregation: The lead agent receives condensed summaries, reconciles them, and either continues reasoning or returns the final answer.

Anthropic's production research system follows this pattern and reports about a 7.9-percentage-point improvement over the best single-agent configuration on the BrowseComp benchmark with Sonnet 4.6.

Why Do Subagents Use Separate Context Windows?

Subagents use separate context windows for two reasons: parallelization and context isolation. Both fall out naturally once each subagent has its own window to work in.

When agents use tools with large outputs, the main context window fills up with intermediate results that the parent does not need to see. Subagents absorb that noise. The main agent receives only the final result. A Stanford Digital Economy Lab study found that agentic tasks consume 1,000x more tokens than code reasoning and code chat, with costs varying by up to about 30x across runs of the same agent on the same task.

Subagents break this snowball. Each starts from a fresh context window and carries forward only what the orchestrator explicitly passes, thereby reducing per-agent input cost and allowing smaller models to handle narrower tasks. Anthropic's system card shows an Opus orchestrator paired with Haiku subagents achieving 87.0% accuracy, a 12.2-percentage-point improvement over using Opus alone (74.8%).

Context isolation is also a security boundary. A compromised or misbehaving subagent can only exfiltrate what exists within its bounded context, instead of the orchestrator's full conversation history. Anthropic's NIST submission frames this as a way to limit the blast radius of any individual compromise.

Shared context across subagent boundaries is a distributed-state problem. Four patterns address it, each with distinct tradeoffs.

Conversation passthrough allows conversation data to be passed to downstream agents, often with explicit filtering and context controls. AutoGen's Swarm uses a shared message history that agents read from and append to. The consistency guarantee is strong because all agents see the same history, but the token cost is the highest. Every downstream agent pays the full cost of all upstream context, including irrelevant content.
Checkpointed state with field-level scoping reduces what each agent receives to namespace-relevant fields. LangGraph provides persistence, checkpointing, and stateful execution for agent workflows. This pattern supports resuming from a persisted checkpoint after interruptions and other stateful debugging workflows. Teams can replay from any prior state.
External shared store moves state entirely outside the agent process. Stateless agent nodes read from and write to Redis or PostgreSQL. Redis works as a low-latency scratchpad, while PostgreSQL provides durability. The trade-off is that determining whether the derived state reflects the most recent changes in the source data can be difficult. This is the only pattern where agent nodes are trivially replaceable and independently scalable.
Pre-materialized context layer unifies and prepares data before any agent begins execution. Each agent receives a pre-computed, role-specific context slice rather than raw conversation history. Token cost per agent is lowest when done correctly, because materialization cost is paid once and shared across all consumers.

This is where the broader production thesis becomes practical. If each subagent has to rebuild business context from scattered connectors at runtime, the architecture keeps reintroducing the same fragmentation it was meant to remove.

Subagent Delegation Frameworks Overview

Dimension	LangGraph	CrewAI	AutoGen (v0.4)	OpenAI Agents SDK
Primary delegation primitive	Send (fan-out) + Command (navigate + update)	Process. hierarchical on Crew	Swarm with HandoffMessage; nested chat via custom on_messages	handoffs parameter on Agent
Default context passed to child	Only the explicit payload in Send(node, payload)	Manager controls task assignment; context is passed via task outputs referenced in the task context field	Full shared message thread (Swarm)	Full conversation history
Context isolation mechanism	Per-invocation: checkpointer=None gives a clean context window	Context passed through tasks (sequential outputs or explicit task context); no automatically shared cross-agent history by default	No isolation in Swarm; application-defined in nested chat	.as_tool() = isolation; handoffs = sharing
Parallel subagent execution	Yes, return multiple Send objects	Not documented for hierarchical process	Configure parallel_tool_calls=False to disable parallel tool calls	No native parallel handoff
Default posture	Isolation-first	Sequential passing	Sharing-first	Sharing-first (handoffs); isolation-first (.as_tool())

What Role Does MCP Play in Subagent Architectures?

The most common misunderstanding is this: the Model Context Protocol (MCP) handles agent-to-tool communication, not agent-to-agent context propagation.

In a subagent architecture, the MCP provides each subagent with standardized access to external tools and data sources. Without it, connecting agents and tools typically requires custom integration code for each agent-service pair, rather than a single standardized protocol.

Any MCP-compliant subagent connects to any MCP-compliant tool without additional integration code. For teams routing many connections across agents and services, an MCP Gateway can centralize authentication, policy, and observability.

Coordination and context sharing are handled through the MCP architecture and application design. Task decomposition, context propagation between agents, routing decisions, and result aggregation remain application-level code. Separate protocol classes, such as A2A, for agent-to-agent coordination, while MCP focuses on tool and data access rather than multi-agent coordination.

How Does the Data Layer Underneath Affect Subagent Performance?

Production systems need an organizational context: cross-system business data must be unified before subagents start reasoning.

When N subagents each independently call M external software-as-a-service, or SaaS, systems before beginning work, the compounding failure modes multiply. Multi-server MCP deployments can add protocol overhead. An agent answering a client renewal question typically makes five or six sequential API calls across multiple business systems before it can reason. Multiply that by every subagent in the system.

Beyond latency and token waste, distributed systems can also introduce fragmented context and inconsistent information. Without partitioned entity scoping, retrieval can cross entity boundaries, contaminating one subagent's context with another entity's data. Each subagent independently resolves shared entities such as customers, accounts, and tickets against its own partial view.

The architectural response is pre-materialization. Run the data unification pipeline before subagents begin reasoning. Context can be treated as a compiled view over a richer stateful system, where sessions, memory, and artifacts are the sources, and the working context is the compiled view shipped to the large language model, or LLM.

The tradeoff is freshness: pre-materialized context is a snapshot. For some sub-second decisioning use cases, on-demand retrieval remains necessary, especially when current data is required. For enterprise workflow automation where minutes-to-hours staleness is acceptable, scheduled materialization can reduce integration complexity and some cascading failure risks.

How Do Airbyte Agents Fit Into Subagent Architectures?

Airbyte Agents is a data and context layer for AI agents. The Context Store unifies data from SaaS sources into a single searchable layer, so agents query indexed business context rather than making scattered runtime API calls per source.

Two-mode execution, Search for fast retrieval from the Context Store and Direct API for live state and writes give the orchestrator flexibility to match freshness requirements to the use case. Authentication is configured per connected service, and the configured credentials are then reused across that connector's streams and interfaces.

Airbyte Agents are available through Agent MCP, Agent SDK, Agent CLI, API, and the Web app, all sharing the same Context Store. For MCP-based clients, Airbyte's Agent MCP supports tools such as Claude, Claude Code, ChatGPT, Codex, Cursor, VS Code, and Windsurf.

Want to dive deeper? Explore the developer hub for reference implementations and SDK examples.

What Makes Subagent Systems Work in Production?

Production subagent systems work when three conditions hold: the orchestrator owns shared state and delegates bounded tasks with explicit objectives; each subagent operates in a clean context window and returns condensed results; and a pre-materialized data layer sits underneath, so subagents query a unified business context instead of assembling it at runtime. The insight is that delegation alone is not enough; how context is shared, scoped, and refreshed across boundaries decides whether a multi-agent system holds up beyond a demo.

Airbyte Agents fill the data layer that every framework's subagent model implicitly requires. The Context Store unifies cross-system business data into a single indexed layer; two-mode execution (Search and Direct API) matches freshness to use-case requirements; and a single auth flow removes per-source credential management from the orchestration logic. When combined with Agent MCP, Agent SDK, and Agent CLI, it gives orchestrators a consistent way to retrieve business context regardless of the framework or interface a team chooses.

Ready to build production-grade subagent systems on a unified business context? Talk to sales to see how Airbyte Agents powers reliable, pre-materialized context for multi-agent workflows, or try Airbyte Agents and get started today.

Frequently asked questions

How Do Subagents Differ From Tool Calls?

A tool call is a stateless function that receives input and returns output. A subagent maintains its own context window, can make multiple tool calls, and performs multi-step reasoning before returning a condensed result. That difference matters when a task requires planning, iteration, or compression of intermediate work. Tool calls fit narrow operations; subagents fit bounded sub-problems with their own reasoning loop.

No. The default varies by framework. LangChain subagents are typically invoked with structured messages from the parent rather than only a raw request string, while OpenAI Agents SDK handoffs pass conversation history to the target agent by default. If you need shared memory across subagents, you generally introduce an external store or a pre-materialized context layer rather than relying on framework defaults.

What's the Difference Between Subagents and a Multi-Agent System?

Subagents operate under a parent orchestrator that controls the flow and delegates bounded tasks. A multi-agent system involves peer agents that collaborate or negotiate without a single controller. Subagents fit hierarchical decomposition with clear ownership of shared state; multi-agent systems fit domains where no single agent has the authority or knowledge to coordinate the full workflow.

When Should You Avoid Using Subagents?

Subagents are the wrong decomposition when the process has well-defined steps with strong sequential dependencies, or when the use case requires deterministic outcomes that cannot absorb evaluator-optimizer loops.

A single agent is appropriate for open-ended problems where the path forward is not clear from the start. The structural corollary is that if the steps can be predetermined, the correct architecture is a workflow rather than an agent.

Try Airbyte Agents

Airbyte connects your agents to all of your data and assembles context before they run. Build agents that actually know your business.

Try it free Talk to sales

What Are Subagents? How Modular Agent Systems Split Work Without Losing Shared Context

Related posts

Try Airbyte Agents