LangChain and n8n both published agent memory guides this week. The shared lesson: keep raw data out of the context window

Most agents that get worse over a long run are not dumb. They are carrying too much.

What happened

LangChain described how its open source Deep Agents harness fights "context rot", the accuracy drop that comes when long running agents pile up more context than the model can handle. It uses five techniques. Tool results over roughly 20,000 tokens are written to files and the model sees only a short preview and the path. When usage reaches 85% of the context window by default, older messages are condensed into a summary while recent ones stay verbatim, and the full history is saved to a file. Skills load full instructions only when relevant, subagents do noisy research in their own context and return a short result, and long term memory lives in a markdown file read at the start of each run.

n8n published a guest post on agent memory from Cognee. It splits memory into short term (the current task) and long term (preferences, past outcomes, company knowledge like tickets and CRM records). It notes that RAG reads but does not write back, that vector stores have no built in sense of which fact is current, and that a memory layer that only grows gets worse over time, so facts need timestamps, consolidation and deliberate deletion.

My take

This maps directly onto the recurring agents I see in client work: the weekly pipeline report, the lead research agent, the support triage bot. The usual failure is a design that feeds the whole CRM export or every email thread into one prompt.

Practical rules I would apply:

1. Never pass a raw export to the model. Store it, give the agent the few fields it needs, and let it fetch more on request.
2. Use a sub step for noisy research and return three bullets, not thirty pages.
3. Keep client preferences, like "figures in pesos" or "skip inactive deals", in a small file or table the agent reads every run.
4. Put a date on every stored fact and a way to delete it. A stale deal stage is worse than no memory.

None of this needs a new framework. It is plumbing decisions in n8n or code, made before the agent goes live.

Recurring agents that stay reliable week after week come down to these choices, and they are what I build for teams. romielwillautomate.dev