Deep Agents Architecture: Planning, Sub-Agents & Memory

Q: What is a deep agent?

A deep agent is an architectural pattern for building AI agents that can carry out long, complex tasks reliably, in contrast to a simple agent that just loops through thinking and calling tools. The term, popularised in 2026 by frameworks such as LangChain's deepagents, refers to combining four elements that together let an agent work over a long horizon of many steps without losing the plot. The first is explicit planning, where the agent writes and maintains a plan or todo list as an artifact rather than holding the plan only in its conversation. The second is sub-agents, where the main agent delegates a self-contained sub-task to a separate agent that runs in its own clean context and returns just its result. The third is a file system used as external memory, where intermediate outputs are written to files and read back on demand instead of accumulating in the context window. The fourth is a detailed system prompt that spells out how to plan, when to delegate, and how to use the filesystem. The point of all four is to keep the agent's active working context small and focused so it can run for dozens or hundreds of steps, which a naive single-context loop cannot do.

Q: How is a deep agent different from a ReAct loop?

A ReAct loop is the basic agent pattern where the model alternates between reasoning and acting: it thinks, calls a tool, observes the result, and repeats, accumulating everything in one growing context. This works well for short tasks of a handful of steps, but it has a structural weakness on long tasks: the context window fills with every tool result and reasoning trace, so after many steps the model is reasoning over a very large transcript in which the original goal has effectively scrolled out of its effective attention, leading to repeated work, goal drift, and rapidly rising cost because every step reprocesses the entire history. A deep agent is built specifically to overcome those limits. It keeps the goal in an explicit plan artifact instead of relying on the message history, isolates self-contained sub-tasks into sub-agents with their own fresh contexts so their intermediate noise never enters the main context, and offloads intermediate results to a file system so the working context stays small and bounded. The practical effect is that a ReAct loop is right for tasks under roughly ten to fifteen steps, while a deep agent is what you use when the task needs fifty, a hundred, or more steps and must stay coherent and affordable throughout.

Q: Why use a file system as agent memory?

Using a file system as memory addresses the central problem of long-running agents, which is that context windows are finite and expensive, and holding every intermediate result in context degrades both performance and cost. When an agent writes its intermediate outputs — research notes, draft sections, fetched data, partial results — to files (which may be real files, a virtual filesystem, or an object store) rather than keeping them all in the conversation, its active context can hold just the current focus plus references to where everything else lives, and it reads specific files back only when it needs them. This keeps the working context small and focused, which improves the model's ability to attend to what matters right now, and it bounds cost because each step is not reprocessing a giant accumulated transcript. It also gives the agent a durable, inspectable record of its work that survives beyond a single context window and can be checkpointed for pause and resume. Conceptually the file system becomes the agent's own working knowledge base, distinct from a retrieval knowledge base of external documents: it is where the agent stores and organises its own evolving outputs. This is the structural complement to context compaction techniques, which shrink what is in context, whereas file memory moves it out of context entirely.

Q: What are sub-agents and when should I use them?

Sub-agents are separate agent instances that a main deep agent spawns to handle a specific, self-contained sub-task, each running in its own clean context with a narrow brief and returning only its distilled result to the parent. Their purpose is context isolation: when the main agent needs to do something that would generate a lot of intermediate reasoning and tool output — researching one source thoroughly, writing one module, analysing one dataset — doing it inline would flood the main context with noise that is irrelevant once the sub-task is done. By delegating to a sub-agent, all of that intermediate churn happens in the sub-agent's context and is discarded, while the main agent receives only the clean result, keeping its own context small and focused on the overall plan. You should use a sub-agent when a sub-task is genuinely self-contained and context-heavy, such that isolating it meaningfully reduces clutter in the main loop. You should not spawn a sub-agent for trivial single tool calls, because each sub-agent carries token and latency overhead for its own setup and result-passing; over-using them adds cost and complexity without benefit. The skill is recognising which sub-tasks are worth the isolation and which should just be inline tool calls.

Q: How do deep agents control cost on long tasks?

Deep agents control cost through two complementary mechanisms that together keep the per-step cost roughly flat instead of rising with task length, which is what makes long-horizon runs affordable. The first is bounding context growth: by offloading intermediate results to a file system and isolating sub-tasks in sub-agents, the main agent's active context stays small rather than accumulating the entire history, so each step processes a modest, fairly constant number of input tokens instead of an ever-larger transcript. In a naive loop, cost per step climbs continuously because every step reprocesses everything that came before; deep agents flatten that curve. The second is prompt caching of the large static elements: a deep agent relies on a long, detailed system prompt plus extensive tool definitions, and these are identical on every step, so caching that stable prefix means the agent pays full price to process it once and a small fraction on every subsequent step, often around ninety percent cheaper for the cached portion. Combined, bounded context and a cached static prefix turn what would be a steeply rising cost curve into a roughly flat one. Adding per-agent budgets on total steps, cost, and recursion depth provides a hard backstop so a misbehaving loop cannot run away financially.

Q: When should I NOT build a deep agent?

You should not build a deep agent when the task is short or simple enough that the extra machinery is pure overhead. A deep agent introduces real complexity: planning logic that maintains a todo artifact, sub-agent orchestration with its own spawning and result-passing, a file system layer for external memory, and ideally checkpointing for durability. All of that is justified only when the task genuinely needs a long horizon, struggles with context pressure, or must be resumable after failure. If your task completes in under roughly ten tool calls, a plain ReAct loop is simpler to build, cheaper to run, and far easier to debug, and wrapping it in deep-agent structure would add cost and surface area for bugs with no reliability gain. Similarly, even within a deep agent you should not isolate every sub-task into a sub-agent, because spawning one carries token and latency overhead; reserve sub-agents for genuinely self-contained, context-heavy sub-tasks. The right approach is to match structure to horizon: start with the simplest loop that works, and adopt deep-agent pillars incrementally — first a plan artifact, then file memory, then sub-agents, then checkpointing — only as the task length and reliability requirements actually demand them.

Q: How do deep agents relate to durable execution?

Deep agents and durable execution are highly complementary, because the same design choices that make a deep agent scale also make it naturally checkpointable. A deep agent externalises its state: the plan lives in an artifact, intermediate results live in a file system, and the agent tracks its position in the loop. That externalised state is exactly what a durable execution layer needs to persist in order to pause, resume, and recover a long-running process. Durable execution frameworks, such as those built on Temporal or LangGraph checkpointing, provide the machinery to snapshot the state of a workflow, survive crashes and restarts, and continue from where it left off rather than from the beginning. Applied to a deep agent, this means a task that runs for a hundred or more steps and happens to fail partway through can resume from its last checkpoint instead of discarding all the work done so far, which for long agent runs is the difference between a recoverable system and one that wastes large amounts of compute on every failure. So the relationship is layered: the deep-agent pattern decides how the agent thinks and manages context over a long horizon, while the durable execution layer makes that long-horizon run reliable, resumable, and fault-tolerant by persisting the agent's externalised state.

Q: Why keep the plan outside the message history?

Keeping the plan in a dedicated artifact rather than only in the conversation history directly counters the most common failure of long agent runs, which is goal drift. In a naive loop the original instruction and any plan the agent formed sit at the start of the message history, and as the agent takes more steps the history grows with tool outputs and reasoning until the early content is far back in the context, where the model attends to it less reliably and can effectively lose track of what it was trying to accomplish. By writing the plan or todo list to an artifact that the agent explicitly re-reads and updates as it works, the goal is always brought back into the immediate, attended-to part of the context regardless of how long the task runs, and progress is tracked deliberately rather than implicitly. This technique, sometimes implemented as a simple todo tool, is cheap to add and has an outsized effect on reliability, because it converts the goal from something buried in a growing transcript into a living, front-and-centre piece of state. It also makes the agent's intentions inspectable to operators and provides a natural structure for checkpointing and for deciding when the task is actually complete.