Memory and Context Management in Long-Running Agents

Long-running agents fail because their memory setup breaks down, even when the model underneath them is strong. A coding agent working a SWE-bench-style problem racks up roughly 8 million tokens and 154 turns per task, according to research on Qwen3-Coder-Next. It's a long, winding job with dozens of steps, and every step adds weight to the context the model has to drag along.

The time cost tells the same story. Recent benchmarking clocked 14.56 hours of execution time on tasks that ran 5.79 hours when memory was handled well: more than double the wall clock on the same benchmark, same difficulty, same model. Most teams respond by throwing bigger context windows at the problem, pushing past 120,000 tokens without noticing that inference costs spike sharply beyond that point with no corresponding accuracy gain. Window size matters less than how well-organized that window is, and most teams get this backwards. Stuffing in more tokens just repeats the same mistake at a higher price.

Knowing the cost doesn't tell you what to cut, though. That takes an actual memory architecture: working context, long-term retrieval, and live web grounding, each doing one job instead of a single giant window trying to hold everything at once. Working context is the layer people default to when they don't have a plan, because it takes zero design, just stuffing things in as they come. It's what's active right now, covering the current subtask, the last few tool calls, and the immediate goal. Finished subtask history, static facts the agent already knows, and summaries from three sessions back should never make it in.

The rule that actually governs this is how much of the window you can fill before reasoning quality starts to slip, not the number printed on the model's spec sheet. That effective ceiling sits well below the marketing figure, and treating the two as the same number is where most of these systems start bleeding tokens for nothing.

Building the retrieval layer: from conversation logs to queryable long-term memory

Long-term memory holds what outlives a single session: extracted facts, user preferences, past decisions, session summaries, a glossary of domain terms, outcomes from prior runs. None of that belongs in working context by default. It sits in a store the agent queries only when it needs something specific, which keeps the load light instead of dragging the whole archive along on every step.

Mem0's architecture shows what this looks like done right. It pulls the facts that matter out of raw conversation transcripts, merges and deduplicates them so the same preference doesn't get saved five different ways, and retrieves selectively at query time. The agent asks for what it needs instead of getting handed the whole file cabinet up front.

Knowledge graphs solve a different version of the same problem, and for anything with real hierarchy, they beat flat vector search outright. Cognee stores information as interconnected nodes instead of a list of embeddings, and that structure earns its keep the moment the domain has real structure to it: enterprise data models, regulatory frameworks, product catalogs where one item's attributes depend on another's. A flat vector search just finds the nearest neighbor; a graph lets the agent reason across relationships. Teams reach for vector search because it's easier to stand up, then wonder why the agent can't connect two facts that are obviously related. The tool simply doesn't match the shape of the data.

Here's the part most teams skip: deciding what to forget. "Add everything, never delete" sounds like a safe default, but two contradictory facts sitting side by side in memory will quietly poison downstream reasoning, and the agent has no way to know which one is current. Consolidation has to run on recency and relevance, not a timestamp check. A fact from six months ago that's been confirmed twice since should outrank one from yesterday that's never been checked again.

There's a governance layer sitting on top of all this, and it has nothing to do with engineering. What's the agent allowed to remember, and who signed off on a fact before it went into the store? When did it last change, and which other agents can read it? Update triggers should be event-based, not calendar-based: a schema change, a policy update, a glossary edit, a data quality incident, a failed agent trace. Any of those should kick off a memory review on the spot. Waiting for a scheduled rebuild just means running on stale information for however long is left until that schedule rolls around.

Live web grounding as the third layer: why retrieved memory isn't enough for time-sensitive tasks

Retrieval solves the "don't repeat yourself" problem. Treating retrieval and freshness as interchangeable is where a lot of these architectures quietly fail, since retrieval does almost nothing for the "is this still true" problem. A fact stored three months ago might be dead wrong today, and the model's own training cutoff means its baseline knowledge is already stale before the agent runs its first task. Pricing pages, API docs, regulatory text, org charts, product specs, competitive positioning: these categories rot fastest, and no amount of clever retrieval fixes a database that hasn't been told the world moved on.

Live web grounding has to be its own layer for exactly this reason, not a feature bolted onto retrieval as an afterthought. The agent needs to read today's page, since a snapshot some index captured three weeks back can no longer be trusted. That distinction sounds small right up until a pricing tier changes or a regulation gets amended, and the agent keeps confidently citing the old version anyway.

The format live content arrives in matters more than most teams expect. Raw HTML burns tokens on navigation bars, ad slots, and boilerplate that has nothing to do with the task at hand. Clean Markdown strips that noise before the content ever gets chunked, and structured JSON extraction goes further still, skipping the parsing problem entirely and handing the agent only the fields it actually needs. Feeding an agent raw HTML quietly runs up a token bill nobody's watching.

Token efficiency matters, but the bigger stake is coherence. Grounding on live web data is what keeps a long-running agent stable when the world it operates in changes faster than any index can be rebuilt to track it.

Change detection as memory maintenance: keeping all three layers current without manual intervention

A memory setup that's accurate on day one starts rotting on day two. Pages change, documents get revised, policies shift, and nothing in the architecture described so far catches that on its own. Something has to actively watch for change, or the retrieval layer calcifies into a very confident record of how things used to be.

Website change detection turns that watching into an agent capability instead of a person's job. Point it at a URL, and it flags when the content shifts, which triggers re-ingestion into the retrieval store. That replaces the old habit of rebuilding an index on a fixed schedule, whether or not anything actually changed, with updates that fire only when something's worth updating.

A handful of things should trigger that update path: a detected change on a monitored URL, a failed agent trace suggesting a stored fact was wrong from the start, a policy or schema change further upstream, or the agent catching a contradiction between what memory says and what the live page says. That last case closes the loop cleanly: the web layer catches the change, the extraction pipeline processes it, and the update overwrites the stale entry, no manual step required.

One practical snag worth naming: plenty of sites lean on JavaScript to render their actual content, and a plain HTTP request against those pages comes back an empty shell. Any change detection system worth running has to render the page the way a real visitor's browser would. Modern scraping infrastructure now handles that rendering in the cloud, so nobody needs to run their own browser instances just to catch a price update.

Multi-agent systems and the memory coordination problem

Multi-agent orchestration works like this: an orchestrator gets a goal, breaks it into pieces, hands those pieces to specialized worker agents, and stitches the results back together. Worker count and task assignment get decided at runtime, which means the system has no way of knowing in advance how many agents will be touching shared memory on any given run.

That's where it gets messy, and this is the failure mode most teams underrate. Multiple agents writing to the same long-term store can produce flatly contradictory entries: two workers extract slightly different versions of the same fact, both get written, and now the store holds a contradiction nobody resolved. It's the same forgetting problem from the retrieval layer, just multiplied across every agent with write access, and it compounds fast once a system runs more than a couple of workers at once.

Shared memory needs write governance to survive this. Either the orchestrator or a dedicated memory agent has to arbitrate whose write wins, how contradictions get flagged, and when a person needs to step in. Live web grounding sidesteps the whole problem, since it's stateless by design. Any agent can fetch a fresh URL on its own without checking in with anyone else, because there's nothing shared left to corrupt.

Gartner projects that by 2026, 40% of enterprise applications will include AI agents, up from under 5% in 2025. That's a steep climb in a short window, and memory coordination is exactly the kind of infrastructure problem that decides which of those deployments hold up under real use and which quietly fall apart once three or four agents start writing to the same store at once.

Putting the architecture into practice: a decision framework for choosing what each layer handles

Working context: is the current subtask, and only the current subtask, sitting in the window? Anything finished, static, or historical needs to move out, with no exceptions.

Retrieval layer: the question worth asking is blunt. Are full transcripts getting passed around, or are compressed, queryable facts getting stored instead? Transcript dumping is the single most common mistake teams make here, and it's the fastest way to blow past the effective context ceiling without gaining a thing in return.

Live web layer: which facts in this task could have changed since anyone last checked them? Pricing, specs, org structure, regulatory language: if the answer touches any of those, that fact belongs behind a live fetch, not a cached memory lookup, and no exceptions apply there either.

None of these three layers is optional, and none substitutes for the other two. Working context keeps the immediate task sharp, retrieval keeps the agent from relearning what it already knows, and live grounding keeps it honest about a world that keeps moving regardless of when the last index was built. An agent that skips any one of them still runs, just expensive, slow, and eventually wrong.