Roman Poliashenko
For the past year, the debate around "AI employees" has run on two tracks: how smart the models are, and who governs the agents. We build these systems for companies, so let me be blunt: in production, the agent breaks somewhere other than where everyone is looking. The most common reason an AI "employee" doesn't survive to the end of a long task is dull and mechanical. It isn't intelligence and it isn't "governance." It's what happens to the agent's context window while the task is running.
And there's a counterintuitive trap baked in. It seems logical: if the agent "forgets," give it memory. In 2026 we now have rigorous data showing that naively bolting on memory often makes the agent worse, not better. Let's look at where the real bottleneck is — and what actually works.
The "reliability cliff" on long tasks is real — and measured
The first thing to accept: long work is a different task, not "the same one, only longer." In the "Beyond pass@1" study (arXiv:2603.29231, March 2026), across 396 tasks, 10 open-source models, and 23,392 episodes, aggregate pass@1 fell from 76.3% on short tasks to 52.1% on very-long tasks — a 24.3-point drop. The model is the same; only duration changes — and reliability sinks with it.
For a business this means something simple but uncomfortable: a demo on a short scenario tells you nothing about how the agent handles a real, multi-step process. The metric most teams watch — success on a short task — systematically inflates expectations.
Why "just give it memory" is not the fix
Now the least obvious part. The same study tested the direct intuition — "the agent forgets, so add memory." The result: a memory scaffold never once improved long-horizon reliability, and hurt 6 of 10 models (worst case Δ = −0.14 on a "graceful degradation" score, on Kimi K2.5). The plain reason-act (ReAct) baseline loop turned out to be "strictly better in aggregate."
The practitioner's read: naively bolted-on memory feeds the agent noise, not signal. It starts drowning in what it once saw instead of moving forward through the task. "Give it long-term memory" is not a universal fix — it's often a regression. That's the lesson most teams learn only after spending a quarter building "smart memory" that made the agent dumber.
What works: forget on purpose, don't compress
If you accumulate everything, the agent suffocates; if you add naive memory, it gets worse. The working answer sits between them, and it has an ugly name — context engineering: deliberately deciding what the agent keeps in its working window, what it evicts, and what it never remembers at all.
It's important to distinguish two approaches. The common one is compaction: periodically "compress" history into a summary. It is lossy by definition — it loses detail, destroys cause-and-effect structure, and produces "compression-induced hallucinations," where the agent confidently cites something the summary already dropped. The alternative is structured eviction: not blind summarizing, but precisely removing from the window what is no longer needed while preserving structure.
How well that works is shown by "Beyond Compaction" (arXiv:2606.11213, May 2026). Their context-lifecycle scheme let a single agent session complete 89 sequential tasks, burning 80 million tokens, with no measurable degradation in quality: on Terminal Bench 2.0 the accumulating session scored 68.25% versus 68.40% for isolated per-task runs — within three points across all benchmarks. The lever isn't a bigger window or summarization; it's disciplined eviction.
This is an engineering problem, not "model magic"
Tellingly, the model makers reached the same conclusion — investing not in "smarter magic" but in context-control primitives. According to Anthropic, combining a memory tool with context editing delivered a +39% quality gain on an internal agentic evaluation (context editing alone: +29%), and on a 100-turn web-search evaluation context editing cut token consumption by 84% while letting the agent finish workflows that would otherwise die of context exhaustion.
The message is identical from both sides — researchers and labs alike: manage context and the agent reaches the finish; don't, and it collapses. The problem isn't the model's "intelligence"; it's engineering what that model sees at each moment.
The scale almost nobody provisions for
One more expectation worth calibrating early. New memory benchmarks (such as BEAM) now evaluate agents at 10 million tokens — which, in their own words, is roughly "a year of daily conversations with an AI agent, a company's entire internal documentation corpus, or the complete output of a software project across hundreds of sessions." At that scale, "just stuff everything into context" is physically impossible: only a real memory architecture with selective retrieval survives, not an inflated prompt.
This doesn't contradict the previous point — it completes it. Naively bolted-on memory hurts on an ordinary task; but when volume outgrows any window, what you need isn't more memory in general — it's well-designed memory, where it's decided what to fetch and what to leave out of view. Either way the answer is the same: engineering, not size.
Why this is economics, not just accuracy
There's another reason to take context seriously — money. Context isn't free. Per Anthropic's engineering data, an agent burns about 4× more tokens than a plain chat, and multi-agent systems about 15× more. On the BrowseComp benchmark, token usage alone explains 80% of the variance in outcomes (all three factors together — token usage, number of tool calls, and model choice — explain 95%).
Hence the discipline: "more context" isn't a free advantage — it's a line item. The goal is to spend context where the value of the task justifies it. Anthropic puts it plainly: multi-agent systems "require tasks where the value of the task is high enough to pay for the increased performance," and it cautions that "most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time." More agents and more context — not by default, only where the math works out.
How we see it (an integrator, not a box)
For a voice or AI system that runs all day and holds long, multi-step conversations, the real difference isn't which model is "under the hood," nor how many agents sit in the "org chart." The difference is the engineering of the context lifecycle: what the agent keeps in the window, what it evicts, what it never remembers, and on what token budget all of it lives. It's dull, invisible work — and it's exactly what we design and test before we ship, because it's what decides whether the agent carries a long conversation to a result or falls apart halfway.
Where to start
- Measure reliability on long tasks, not pass@1 on short ones. A three-turn demo says nothing about a 30-step process.
- Don't add memory by default. First prove on your own process that it helps rather than adding noise. Often the plain loop is more reliable.
- Manage context deliberately. Evict the irrelevant precisely; don't rely on blind summarization that loses detail and invents things.
- Treat tokens as a budget. Spend context where the task value justifies it, not "just in case."
- When volume outgrows the window, trust the memory architecture, not size. At enterprise-data scale, selective retrieval wins over "stuff it all in."
Why this matters right now
In 2026 the model is table stakes: powerful agents are available to everyone. The advantage comes not from a "smarter" agent but from context discipline. An agent that knows how to forget correctly and spend context on a budget carries long work to completion — while "smarter" but undisciplined ones drown in their own history. Whoever understood this earlier builds AI employees that work, instead of ones that dazzle in a demo and fail in production.
