The problem you see after the tenth call

Ever watched an agent do the right thing for the first three actions, then at the sixth step forget a constraint you gave it at the start and fail? It happens when the task is long: initial requirements, failed attempts, open sub-goals end up buried in the history or beyond the context window limit. The agent acts only on what it sees in the last few lines, and loses the decision-making state that matters.

The paper calls this behavioral state decay: relevant information exists somewhere in the trajectory, but the agent doesn’t surface it when it needs to decide.

Why it matters for you

If you’re building an agent for tasks lasting more than a few calls, you run into this problem immediately. A system debug requiring ten commands, an analysis spanning multiple files, a configuration with dependencies to maintain: every time the trajectory gets longer, relevant state scatters. Today the most common solution is pushing everything into the system prompt or periodically summarizing by hand, but neither scales well.

The paper proposes active memory that doesn’t wait to be asked: a separate agent that watches the recent trajectory, updates structured memory, and autonomously decides whether to inject a reminder to the action agent or stay silent. The module attaches to an existing agent without modifying it, and works with frameworks already in use.

If you have an agent that loses pieces on long tasks, this architecture gives you a concrete starting point.

What the paper says

The authors built a memory agent that runs in parallel to the action agent (the one that decides actions). At each step:

1. It receives the recent trajectory (last actions, observations, outputs)
2. It decides whether to update structured memory (a dictionary with keys like task_requirements, environment_facts, failed_attempts, diagnoses, open_subgoals)
3. It decides whether to inject a text reminder to the action agent or let it work without intervention

Memory isn’t a passive database to query: the memory agent chooses when to intervene, and only does so if it believes the relevant state isn’t already visible to the action agent.

They tested it on two benchmarks:

• Terminal-Bench 2.0: Linux terminal tasks requiring long sequences (system configurations, multi-step debugging)
• τ²-Bench: tasks on web interfaces and desktop applications, where the agent must remember goals across multiple pages

Results on pass@1 (percentage of tasks completed on first attempt):

• Terminal-Bench: +8.3 percentage points with the memory agent versus the action agent alone (for both weaker and stronger agents)
• τ²-Bench: +6.8 percentage points

The authors compared five variants:

1. Proactive memory agent (the proposed one): injects reminders only when it decides they’re needed
2. Passively exposed bank: the action agent always sees the entire memory state
3. Continuous injection: every update gets injected, always
4. Advisor-only: the memory agent proposes actions, doesn’t manage state
5. Generic retrieval: recovers information on request, like RAG

Selective intervention beats all alternatives. Injecting always creates noise, exposing everything passively doesn’t guarantee the action agent uses it at the right moment, and on-demand retrieval requires the agent to know what to search for.

As a proof of concept for an open-weight memory policy, they fine-tuned Qwen3.5-27B on a dataset called SETA using supervised fine-tuning and GRPO (a reinforcement learning algorithm). The model improves on validation and shows partial transfer to Terminal-Bench, but remains a preliminary experiment.

How much to trust this

This paper works from abstracts and arXiv page information: the full PDF wasn’t accessible. What we know:

• Improvements are measured on two specific benchmarks (Terminal-Bench 2.0 and τ²-Bench), covering terminal tasks and graphical interfaces, but don’t represent all possible long tasks. Gains on other domains remain to be verified.
• The architecture is plug-and-play with existing agents, but requires a second LLM agent running in parallel: there’s computational and latency cost. The paper doesn’t report how many additional calls are needed per task, or total execution time.
• Training an open-weight memory policy (Qwen3.5-27B) is described as a preliminary step with partial transfer, not a ready solution.
• The ablations show selective intervention beats tested alternatives, but we don’t know how much depends on the quality of the memory agent’s prompting: a simpler policy might work nearly as well.
• It’s unclear how the memory bank scales when tasks last tens or hundreds of steps: eventually even structured memory fills up.

In short: results on benchmarks are solid, the idea is clear and testable, but implementation details and practical limits require the full paper to evaluate thoroughly.

What to do with this

If you’re building an agent on tasks lasting more than five to ten steps and see it losing relevant information, try this architecture:

1. Add a second agent that watches the recent trajectory and maintains a state dictionary (task requirements, environment facts, failed attempts, open sub-goals).
2. Give it a simple intervention policy: inject a reminder only if it sees the action agent about to violate a constraint or repeat an error, otherwise stay silent.
3. Test with and without: measure pass@1 on your tasks. If it doesn’t improve, the problem isn’t distributed memory, it’s something else (unclear initial prompt, ambiguous observations, unstable environment).

The mistake to avoid: thinking it’s enough to expose a complete log to the action agent. The paper shows that selective active intervention beats passive memory exposure, because it reduces cognitive load and injects information only when it matters.

Another implication: if your agent uses retrieval (like RAG over documentation), proactive memory is complementary, not alternative: retrieval recovers static knowledge on demand, memory holds the task’s decision state in progress and injects it without waiting to be searched.

Where to go deeper

On the site:

• Lesson “State and memory in agents” (not yet published, in builder roadmap): how agents track context across multi-step tasks
• Scaffold “Two-agent architecture” (to be created): basic schema for separating the action agent from the supervision agent

Beyond the site:

• Paper on arXiv
• Terminal-Bench and τ²-Bench (search official repos for reference tasks)