Technology note — this article reflects Deep Agents 0.7 (released July 29, 2026), the associated LangGraph capabilities, and the LangSmith evaluation features available or announced as of July 2026. Vendor-reported measurements are attributed as such and distinguished from anything we have reproduced. Code samples were written and import-checked against deepagents==0.7.0and langgraph==1.2.10 on Python 3.11.
Engineering AI for Production
Planning, context isolation, subagents, persistent workspaces and trajectory evaluation — what the Deep Agents line teaches about paying for capability in context.
In Part 1 of Engineering AI for Production, we looked at the retrieval layer beneath RAG systems.
Part 2 moved into the agent development loop and how to make changes measurable, testable and reversible.
Part 3 looked underneath that workflow again, comparing the infrastructure choices for the observability and evaluation platform itself.
Part 4 raises the stakes.
What changes when an agent is no longer handling a single request, but working on a task for twenty minutes, an hour or longer?
At that point, reliability becomes much less about whether the model can answer correctly in one turn. The agent has to maintain intent across hundreds of steps, manage an expanding context window, recover from detours, preserve useful state and avoid filling its own working memory with information it no longer needs.
That is where context engineering becomes one of the main constraints.
In this article, Gregorio Ferreira looks at the design patterns behind long-horizon agents, including explicit planning, persistent workspaces, subagents for context isolation and trajectory-level evaluation. He also looks at an equally important question: whether each piece of agent scaffolding is actually earning the context it consumes.
The underlying principle is simple:
Do not assume more agent infrastructure automatically produces a better agent. Measure what each capability costs, what failure it prevents and whether the evidence justifies keeping it.
The article then works through how to compose that harness deliberately, how to evaluate long-running behaviour rather than just final answers, and how to think about context as a finite engineering budget rather than an unlimited resource.
Engineering AI for Production · Part 4 of 5
Long-horizon agents fail differently.
A chatbot's failure is visible and cheap: one bad answer, one annoyed user, next turn. An agent that works on a task for twenty minutes —researching, writing files, making hundreds of tool calls — fails in slow motion. The context window silently fills with tool output until the original instructions are functionally gone. A subtask loses the plot and the agent doesn't notice, because the evidence is buried three summaries deep. One flaky API call poisons an hour of accumulated state. By the time the failure is visible, its cause is far away.
The previous pair of posts in this series covered the quality loop for agents and the platform it runs on. This post is about what changes when the horizon stretches: the design pattern that makes long -running work tractable, and the discipline — measuring what every capability costs in context — that the ecosystem itself just learned in public.
The deep-agent pattern: three mechanisms against context decay
The pattern that has crystallized for long-horizon work — popularised by the coding agents and implemented for general use by the deep agents library on LangGraph — combines three mechanisms. (This framing is our synthesis of the pattern; the library's own documentation organises it similarly as planning, filesystem, and subagents.)
Planning as an artifact, not a hope. The agent maintains an explicit plan it can re-read —which survives context compaction in a way that "the plan being somewherein the history" does not. The plan is less about coordination and more about recitation: re-reading it keeps long-term intent in the freshest part of the context.
A file system as external memory. Instead of holding everything in the conversation, the agent writes intermediate products — notes, drafts, downloaded documents — to a workspace and reads back only what the current step needs. Context stops being the storage layer and becomes what it should be: working memory. In deepagents , the workspace is a pluggable backend: agent state for ephemeral work, a LangGraph Store for persistence across sessions, local disk or a remote sandbox when the agent needs a real machine.
Subagents forcontext isolation. A research detour that would flood the main context with twenty tool responses runs instead in a subagent whose context is disposable; only its conclusion returns. Isolation — not parallelism — is the point, though since 0.5 subagents can also run async as non-blocking background tasks.
The composition in code is deliberately compact:
The lesson the ecosystem learned in public: measure your scaffolding
Here is the uncomfortable part. Every one of those mechanisms — the planner, the filesystem tools, the subagent machinery — is itself paid for in context: system-prompt text, tool schemas, coordination messages. It is entirely possible for the harness to cost more than it returns. How would you know?
You would know by evaluating it — which is exactly what happened upstream, and why it is the center piece of this post. With the 0.7 release (July 2026), the deepagents maintainers report cutting the harness's base input-token footprint by roughly 65% at comparable benchmark performance: the default general-guidelines prompt was removed, tool descriptions were cut by ~43%, and — most strikingly — the to do-list planner was demoted from default to opt-in after their own evaluations showed it did not reliably improve results (vendor-reported figures from the LangChain 0.7 announcement and its benchmarking write-up; we have not independently reproduced them).
Sit with that: the planning tool — the most iconic piece ofthe pattern — didn't pay its way as a default in the maintainers' own benchmarks. Not "planning is useless" — it remains opt-in, and for genuinely multi-phase work we still enable it. The transferable lesson is the method: treat every piece of scaffolding as a hypothesis, and let evaluations — not pattern-matching on what famous agents do — decide what stays. Your model is not the only thing consuming your context budget; your good intentions are too.
The 0.7 release also made the harness easier to right-size: middleware instances now override defaults by name (so dropping in a custom-configured Summarization Middleware replaces the built-in one instead of stacking with it), system prompts compose structurally, and file system tools can be allow listed per agent — small API changes, but together they turn "the harness" from a monolith into an itemised bill.
Applying the method takes an afternoon, not a research program, because the measurement is just an A/B over your own eval suite with token accounting on. The harness's cost is visible in the traces you are already collecting:
If Planner-on wins on task success by a margin that survives your sample size, the planner stays and the tokens are well spent. If the quality lines overlap and the token lines don't — you have found scaffolding tax, and you can cut it with evidence instead of a debate. We run this table quarterly and on every model upgrade; components have moved in both directions.
Composing the harness deliberately
In practice we assemble long-horizon agents the way the 0.7 design invites — starting from almost nothing and adding components that earn their tokens for the specific workload:
- Compaction before capacity. Summarisation middleware triggers at a configured context threshold and compacts the oldest turns; since 0.4 the harness also reacts to context overflow errors by summarising and retrying. Compaction is lossy by design — which is precisely why the file system matters: facts that must survive verbatim belong in the workspace, not in the summary's paraphrase.
- Subagents where the context is expensive, not where the task is impressive. The test is arithmetic: a step that pulls thousands of tokens into context but whose useful output is a paragraph is a subagent. A step whose output the orchestrator needs in full is not.
- Persistence that matches the horizon. Ephemeral state for single-session tasks; a durable store when work spans sessions; a sandbox when the agent needs to execute what it writes. (What keeps hour-long runs alive across restarts is the runtime's job — checkpointing, resumability — and that is the next post.)
- In-run quality signals, used with skepticism.The beta Rubric Middleware(0.6.5) has the agent self-assess against an explicit rubric during the run. We treat this as a useful tripwire —catching drift early enough to correct course — and never as a quality gate: a model grading its own homework is a signal, not a verdict. Verdicts come from the evaluation layer below.
Evaluating agents you can't eyeball
A twenty-minute run with three hundred steps cannot bereviewed by reading it. The evaluation approach from the first post still applies, but long horizons force two upgrades.
Judge trajectories, not endpoints. Final-answer evaluation is nearly blind here: an agent can produce a correct summary having read half the sources it claimed to have read, or reach the right refund decision through a hallucinated policy lookup. Trajectory-level evaluators — available among LangSmith's evaluator templates and in the open-source openevals / agentevals libraries — score the path: were the right tools called, in a sensible order, without redundant loops? Did the plan's steps actually happen? Pair them with programmatic verifiers wherever the task allows: for anything with a checkable outcome (code that runs, a file with required properties, a number reconcilable against a source), a deterministic check beats an LLM judge — and long-horizon tasks have more checkable outcomes than teams assume, because the workspace is evidence: files written, sources fetched, steps logged.
Let production tellyou what to test, at the behavior level. With long-running agents, aggregate behavioural analysis over traces (Insights-style clustering, or your own analysis over exported traces) matters more than individual trace review —the failure modes that hurt are the ones nobody predicted: a class of tasks where the agent always re-fetches what it already saved, a subagent that quietly returns empty summaries for paywalled sources. Each discovered cluster becomes a dataset and, where possible, a verifier — the same compounding loop as post one, operating on trajectories instead of answers.
Takeaway: the context-budget worksheet
Before shipping a long-horizon agent — and again at every harness change — fill this in per component (planner, each tool's schema, each middleware, each subagent):
- Cost: tokens it adds to the base context (measure: diff a minimal run's input tokens with the component on vs. off).
- Recurring cost: tokens it injects per step (tool outputs, coordination messages).
- Claimed benefit: what failure does it prevent, concretely?
- Evidence: which eval shows that failure occurring without it — and improving with it? (If the answer is "none," the component is a hypothesis. Test it or cut it — the upstream todo-list result shows even canonical components can fail this test.)
- Escape path: what happens at context overflow — compact, spill to workspace, or fail?
Two closing rules from our worksheet's history. Component earn defaults only after two workloads show benefit — one workload is an anecdote. And re-run the worksheet on every model upgrade: context budgets that were binding at one price-and-context-window combination stop being binding at another, and scaffolding that earned its place last quarter may be pure tax today.
This is the fourth post in a five-part series. Everything above assumes the run survives long enough to matter — that a deploy, a pod eviction or a flaky dependency doesn't erase twenty minutes of work. Making that true is runtime engineering, and it is the subject of the final post.
References
- DeepAgents 0.7 release — LangChain blog, July 29, 2026 (token-reduction andbenchmark figures vendor-reported; todo-list default change, middlewareoverrides by name, filesystem tool changes)
- "HowWe Benchmark Deep Agents" — LangChain blog, July 23, 2026
- deepagentsdocumentation (subagents, backends, middleware; async subagents and multimodalfilesystem: 0.5.0, April 2026; RubricMiddlewarebeta: 0.6.5, May 2026) — docs.langchain.com
- Trajectoryevaluation — LangSmith evaluator templates (April 16, 2026) and the openevals / agentevals libraries
- LangSmith Insights behavioral analysis —docs.langchain.com/langsmith
.png)
