Two builders hit the same wall in the same week. Both say the same sentence: "my agent loses the plot on long tasks." It starts strong, then somewhere around step fifteen it forgets the original goal, re-does work it already did, or confidently answers the wrong question.
Builder A reaches for a deep-agent harness — planning tool, virtual file system, subagents, the whole rig. Builder B looks harder and finds his loop was choking on one bloated tool that dumped 8,000 tokens of raw JSON into context every call; he trims the tool output and the "long task" now fits in one clean loop.
Both fixes are real. Both builders can also be wrong. Reach for the harness on a task that never needed it and you've bought latency and a debugging headache. Trim the tool loop on a task that genuinely runs for fifty steps and you'll drift again next week. The question isn't which architecture is better. It's which one this task earns.
What a plain tool-calling loop actually is#
A plain loop is the ReAct pattern: the model reasons, picks an action (a tool call), observes the result, and repeats until it decides it's done (Yao et al., ICLR 2023). That's it. There is no separate memory, no plan artifact, no orchestration. All state — the goal, every intermediate result, every dead end — lives in the growing message history.
That simplicity is the strength. One transcript tells you everything that happened. It's cheap: no extra tool calls, no prompt bloat. It's fast: the model acts directly.
The failure mode is also structural. Because every observation piles into the same window, long horizons cause context rot. The original instruction slides toward the top and loses salience. Old tool outputs you no longer need still consume budget and dilute attention. The model starts pattern-matching on recent noise instead of the actual objective. This is the "loses the plot" symptom — and on a genuinely long task, no amount of prompt-tweaking fixes it, because the problem is that one linear context is doing too many jobs at once.
What a deep agent adds#
The LangChain Deep Agents framing names four ingredients that applications like Claude Code, Manus, and deep-research agents use to escape the shallow-loop ceiling. The deepagents package bundles them on top of LangGraph (repo, docs):
- A planning tool (
write_todos). The agent writes and updates a todo list. The tool barely does anything mechanically — it's close to a no-op — but forcing the model to externalize a plan and check items off keeps the goal in view across dozens of steps instead of letting it decay in the transcript. - A virtual file system (
ls,read_file,write_file,edit_file). Scratch memory the agent can offload to. Instead of carrying a 200-line research summary inside the context window, it writes the summary to a file and reads it back when needed. Intermediate state becomes durable and stops bloating the loop. - Subagents. The orchestrator spawns focused subagents, each with its own fresh context window. A subagent can burn 40 messages exploring one sub-question and return only the three-line answer — the messy middle never touches the parent's context. This buys parallel, isolated exploration.
- A detailed system prompt. The long orchestrator prompt encodes how to plan, when to delegate, and how to use the file system. Without it, the other three tools sit unused.
Notice what every one of these actually buys: bounded context growth over a long horizon. The planning tool anchors the goal. The file system evicts state from the window. Subagents quarantine exploratory mess. That's the whole value proposition — and it's a tax. Each planning call, each file read, each subagent spawn is extra latency and tokens, and the orchestrator prompt is a fixed context cost on every turn.
A deep agent's harness is a context-window and latency tax you pay up front to survive long tasks — on a task that fits in one loop, you're paying the tax and getting nothing back.
It's not either/or#
The cleanest way to think about this: a deep agent is a tool-calling loop with extra tools. Underneath, it's still reason-act-observe. The planning tool and file operations are just more tools the model can call; a subagent is the same loop nested one level down. There's no architectural chasm to leap.
That means you adopt the pattern incrementally, not all at once. Losing the goal? Add only the planning tool — a write_todos your model checks against. That alone fixes a surprising share of "drift" cases. Carrying too much intermediate state? Add one scratch file — a read/write pair — and let the model offload. You don't need subagents until you actually have independent sub-questions worth exploring in parallel.
If you want the full mental model, start with what deep agents are, then the hands-on build with deepagents, subagents, and planning. Not on LangChain? The same four ingredients port cleanly, as shown in deep agents on Pydantic AI. And if you're weighing the framework layer itself, see LangChain vs LangGraph vs the deepagents harness.
The decision rule#
- Short, bounded task — a handful of steps that fit in one context window? Use a plain tool-calling loop. It's faster, cheaper, and you can debug it from a single transcript. Adding a harness here buys overhead, not capability.
- Long-horizon task, or one that needs durable intermediate state, or benefits from parallel isolated exploration? Use a deep agent. The planning tool, virtual file system, and subagents are exactly the tax worth paying when context would otherwise rot.
- Unsure? Start plain. When it drifts, add the planning tool first — it's the cheapest ingredient and fixes the most common failure. Reach for the file system and subagents only when the task proves it needs them.
