LangChain Deep Agents Turns Agent Memory Into Files You Can Open

The fix for agents that get worse the longer they run is a file path, plus one backend setting that decides whether the memory survives the night

Long-running AI agents have an odd failure mode. They get worse the longer they work. The first twenty minutes look sharp, and by hour two the same agent forgets a decision it made, rereads a file it already summarized, or answers from a stale tool result buried under fifty newer ones.

LangChain has a name for this, "context rot," and on October 14 it published a guide to how its open-source agent harness, Deep Agents, fights it. The guide is titled Context Engineering: How Deep Agents Remember, and its answer is less clever than you might expect. Most of the fix is writing things to files.

That sounds boring. It is the most useful idea in agent design this month, and there is one default setting that undoes half of it.

Why agents rot

Every model works inside a context window, the fixed amount of text it can see at once. Think of it as a desk. Your instructions go on the desk, then every message, every tool result, every file the agent opened. Nothing leaves unless something removes it.

Long runs fill the desk. One database query returns a wall of rows; one web fetch drags in a page of navigation menus. After enough steps, the instructions that matter sit under a pile of material that mattered once, and the model's attention spreads thin across all of it. LangChain's post describes the result plainly: accuracy drops as agents build up more context than the model can hold.

The common fixes are blunt. Cut old messages. Truncate long tool output to the first few thousand characters. Both keep the desk clear, and both throw away evidence the agent may need ten steps later.

Deep Agents takes a different line. Its guide says it in six words: "Large inputs should be offloaded, not truncated."

The five moves, in plain terms

Deep Agents is LangChain's open-source harness for long, multi-step agents (a harness is the code wrapped around the model that runs the loop, calls tools and manages what the model sees). Each of its context tricks is a piece of middleware, a small module that hooks into that loop. Here is what each one does, using the desk.

Offloading. When a tool returns something huge, roughly 20,000 tokens or more by the post's estimate, the harness writes it to a file at /large_tool_results/{tool_call_id} before it ever reaches the conversation. The model sees a short preview (the first and last few lines) plus the file path, and it can page through the rest with a read_file tool. It is the difference between dumping a 300-page printout on the desk and putting it in a drawer with a sticky note that says where it is. Oversized messages from the user, like a pasted meeting transcript, get the same treatment at a higher threshold of 50,000 tokens.

Summarization. Before each model call, the harness checks how full the window is. Past 85% (the default), a separate model call condenses older messages into a summary and keeps the most recent ones word for word. The detail that matters: the original messages get saved to /conversation_history/{session_id}.md. So this is closer to meeting minutes with the recording kept on file than to shredding the transcript.

Skills. A skill is a folder of instructions built around a SKILL.md file. Deep Agents loads only each skill's name and description at first, and reads the full instructions only when the model decides one is relevant. The post calls this "progressive disclosure." It works like a table of contents instead of the whole book.

Subagents. Noisy work, like reading a long market report, runs in a separate context window. Only the final answer comes back. The post's example tells a "market-researcher" subagent to "return 3 short bullet points. Do not return the raw report." You send an intern to the archive and ask for the three things that matter.

Long-term memory. Memory is a markdown file the agent reads at the start of a run, includes on every model call, and edits when it learns something worth keeping. You set it with one argument, memory=[...].

The post sums up the first two in one line: "Offloading stops the small spikes, while summarization 'resets' the overall climb."

The shift: memory as files you own

Here is the idea worth stealing even if you never install Deep Agents.

Truncation and deletion treat context as a budget problem. Offloading treats it as a filing problem. The agent's desk stays small, and nothing it has seen is gone. It is one read_file call away, at a path the agent knows.

A file is also something you, the builder, can open, read, diff and fix. When an agent makes a strange call at step 140, you can look at the exact tool result it was working from, instead of guessing what the truncated version said.

And it changes what survives a model switch. LangChain's post makes the point directly: "Memory in storage you control survives a model or provider switch." If your agent's learned preferences live inside one vendor's hosted memory feature, they stay with that vendor. If they live in AGENTS.md in your own storage, the next model reads the same file.

Memory as a file sounds primitive. It is primitive. That is why it works.

The default that forgets

Now the catch, and it is not in the blog post. It is in the docs.

Deep Agents stores its files through a "backend," the layer that decides where a file path actually lives. The backends documentation says: "If omitted, the default is StateBackend()." And it spells out what that means: "Files persist across turns within a thread (via your checkpointer) and are not shared across threads." A checkpointer is the LangGraph component that saves a conversation's state between steps, so even this thread-level persistence depends on having one configured.

A thread here is one conversation. So with the default backend, your /memories/AGENTS.md file, your offloaded tool results and your saved conversation history all live inside that one conversation's saved state. Start a new thread tomorrow and the agent opens an empty notebook.

That is fine for offloading, which only needs to last as long as the task. It breaks long-term memory, which is the one piece that is supposed to outlive the task.

The docs show the fix: a CompositeBackend that keeps everything thread-scoped by default but routes one folder somewhere durable. In the docs' words, "Thread-scoped by default, /memories/ persisted across threads."

Put this into practice

Deep Agents is MIT-licensed and marked Beta on PyPI, where version 0.7.25 landed on October 14. Install it with the command from LangChain's post (it needs Python 3.11 or newer):

uv add deepagents

Then give memory a home that outlives the thread. This combines the memory argument from the blog post with the routing example from the backends docs:

from deepagents import create_deep_agent
from deepagents.backends import CompositeBackend, StateBackend, FilesystemBackend

agent = create_deep_agent(
    model=model,  # a "provider:model" string, like the post's "openai:gpt-6"
    memory=["/memories/AGENTS.md"],
    backend=CompositeBackend(
        default=StateBackend(),
        routes={
            "/memories/": FilesystemBackend(root_dir="/deepagents/myagent", virtual_mode=True),
        },
    ),
)

What to expect: scratch files and offloaded results still vanish with the thread, which keeps things tidy. Anything the agent writes under /memories/ lands as a real file under /deepagents/myagent, where you can open it in a text editor. For an agent that serves several users, a folder on one machine is the wrong home. The docs also offer StoreBackend, which keeps files in a LangGraph store for "cross-thread durable storage" instead of on local disk; give each user their own namespace so one person's memories never load into another's run.

Keep virtual_mode=True in the code even though it is now the default. The docs warn that FilesystemBackend "grants agents direct filesystem read/write access" and that an agent can read secrets with it. The docs page still describes virtual_mode=False as the default, but the current code sets it to True, so writing it out protects you from whichever version you happen to install. Know what it does and does not do. The code's own docstring says virtual mode blocks path tricks like .. and ~ and paths outside root_dir, "but it does not provide sandboxing or process isolation." Anything inside the folder is fair game, so keep secrets out of it. A memory feature should not double as a way for the agent to read your .env file.

Three more habits make this pay off:

Read the memory file after the first few runs. It is plain markdown. If the agent wrote something wrong, delete the line. That is a fix you cannot make to a model's hidden state.
Test the 85% threshold on your longest real task. Watch what the summary keeps and what it drops. If a detail the agent needs later goes missing, summarize later or move that detail into memory on purpose.
Push noisy tools behind a subagent. If a tool routinely returns pages of output, wrap it in a subagent whose instructions say what to return. Copy the shape of the post's "return 3 short bullet points" example.

Honest limitations

Summarization is lossy and it costs money. Each summary is an extra model call, and a summary is a judgment about what mattered. The original is saved, but only in the thread unless you route it elsewhere, and the agent only goes back to it if something prompts it to.

The numbers are soft. The post says the offload threshold is "roughly" 20,000 tokens and the preview is "the first and last few lines." The 85% and 50,000 figures are stated defaults. Treat all of them as starting points to tune, not settings someone measured for your workload.

A memory file holds whatever the agent decides to write. If it misreads a user, or a web page it fetched contains a planted instruction, that mistake can get written into memory and read back on every future run. Files make the problem visible. They do not prevent it.

This is a vendor guide. It describes how LangChain's harness works, not an independent measurement of how much it helps. The post also closes by promoting LangChain's LangSmith product and a live session.

Your move

You do not need Deep Agents to use the idea. Look at the longest-running agent you have. Find the spot where it truncates a tool result or drops old messages, and ask whether that output could go to a file with a path the agent can read back instead.

Then look at where its memory lives. If the answer is "inside the conversation," it is not memory. It is a notebook that gets thrown out every night. Give it a folder you own, and check what it wrote there next week.

Sources: LangChain, "Context Engineering: How Deep Agents Remember" (October 14, 2026); Deep Agents backends documentation (Python); deepagents filesystem.py on main; deepagents on PyPI (0.7.25). Reviewed October 14, 2026.

Medium metadata

Title: LangChain Deep Agents Turns Agent Memory Into Files You Can Open

Alternates to test:

Your Agent's Memory Disappears Every Night. Here's the One-Line Fix.
Agents Don't Need Bigger Context Windows. They Need Drawers.
Agent Memory Isn't Conversation History Anymore

Subtitle options:

The fix for agents that get worse the longer they run is a file path, plus one setting that decides whether memory survives (picked)
Offload, don't truncate: what LangChain's context guide gets right, and the default it leaves out
Why the best answer to context rot is a folder you control

Description: LangChain's Deep Agents fights context rot by moving big outputs and memory into files. Here's how it works and the default that forgets.

Tags:

AI Agents: the core audience and the highest-traffic tag for this subject
LangChain: names the framework readers search for
Context Engineering: the rising term this piece explains in plain words
Python: the code sample is Python and builders filter by language
Software Development: widens reach to developers outside the AI niche

Article type and publish plan: Type A (a real release with a clear payoff and a fix readers can apply today). Post at 7 to 8 AM ET, let Medium distribute for 2 to 6 hours, and send to subscribers only if it is performing.