STACKPLANNER: When Agents Learn to Forget

Enterprise agents usually fail in an undramatic way.

They do not rebel. They do not suddenly become conscious. They do not announce, with cinematic timing, that humanity has been replaced by a spreadsheet. They simply lose the thread.

A research agent searches once, finds something half-relevant, and keeps dragging that result through the rest of the task. A report-writing workflow collects too many fragments and then forgets which ones were actually useful. A coordinator delegates to sub-agents, receives noisy outputs, and treats every message as equally important because, apparently, all context is sacred now. By the final step, the system has not become more intelligent. It has become a very expensive meeting transcript.

That is the problem STACKPLANNER tries to formalize. The paper, STACKPLANNER: A Centralized Hierarchical Multi-Agent System with Task-Experience Memory Management, argues that centralized multi-agent systems do not only need better planning or more tools. They need explicit memory control.¹ In other words, an agent workflow should not merely remember more. It should decide what to keep, what to compress, what to remove, and what prior experience is worth reusing.

That sounds almost too obvious. Of course an agent should manage memory. The useful part of the paper is not the slogan. The useful part is the mechanism: STACKPLANNER treats memory as an action space, trains the coordinator with reinforcement learning, and separates short-term task memory from reusable experience memory. That makes the paper less about “multi-agent systems are powerful” and more about a colder operational point: coordination quality depends on memory hygiene.

The real bottleneck is not that agents forget; it is that they remember badly

The common instinct in agent design is additive. Add more agents. Add more tools. Add a longer context window. Add a supervisor. Add a critic. Add a memory store. Add another retrieval step because the first one looked lonely.

STACKPLANNER pushes against that instinct. The paper’s diagnosis is that centralized multi-agent systems become fragile because the central coordinator accumulates execution traces without enough control over them. Sub-agents return raw observations, intermediate plans, failed retrievals, partial summaries, and local reasoning artifacts. These artifacts are often useful when they first appear. They become toxic when they are carried forward indiscriminately.

The authors describe three related failure modes:

This is where the paper’s main misconception matters. More agents do not automatically produce better long-horizon reasoning. More context does not automatically produce better memory. Sometimes it gives the coordinator a bigger desk on which to pile the same mess.

The paper’s answer is to make memory part of the coordinator’s job, not a passive byproduct of the conversation.

STACKPLANNER makes the coordinator smaller, not louder

STACKPLANNER uses a centralized hierarchical design. There is a central coordinator, but it is not supposed to perform every concrete task itself. Its job is high-level control: planning, delegation, revision, and final integration. Specialized sub-agents handle execution, mainly search and report generation.

The important design move is separation. The coordinator’s memory is not simply a shared dumping ground for every sub-agent output. Instead, the coordinator maintains a task memory stack and decides how that stack should change.

At the high level, the paper frames the coordinator’s action space as:

The appendix implementation expands these into prompt-level actions such as PLAN, REFLECT, SUMMARIZE, DELEGATE, and FINISH. The conceptual structure remains the same: the coordinator is not merely thinking; it is deciding when the task state itself needs repair.

That repair mechanism is the heart of the paper.

Task memory is a stack because not all history deserves equal status

STACKPLANNER’s task memory is described as a lightweight stack. New task execution information is pushed onto it. When the memory becomes too verbose, the coordinator can condense a segment into a shorter representation. When the coordinator detects unproductive or erroneous exploration, it can prune selected entries while retaining a concise record of the failure cause.

This is more specific than ordinary summarization.

A normal summarization layer says: “The context is long; compress it.”

STACKPLANNER’s memory control says: “This part is useful but too verbose; condense it. This part is misleading; remove it. This failed attempt is not evidence, but the reason it failed should be retained so we do not repeat it.”

That distinction matters for enterprise workflows. In compliance research, a wrong source should not be summarized into the same memory state as a verified regulation. In financial analysis, a preliminary screening result should not remain equally salient after later evidence contradicts it. In customer-support escalation, an early misunderstanding should not continue shaping the response after the user clarifies the issue.

Bad memory is not neutral. It is instruction by residue.

STACKPLANNER’s mechanism can be read as a simple operating discipline:

1. Preserve task-relevant progress.
2. Compress completed stages.
3. Remove misleading branches.
4. Keep short failure notes so the system does not loop.
5. Delegate execution without letting execution artifacts overwhelm coordination.

This is the paper’s most business-relevant idea. Not “agents can remember.” Everyone is already trying that. The point is that agents need memory governance.

Experience memory is different from task memory, and confusing them is expensive

The second memory layer is experience memory. This is not the short-term stack used during one task. It is a structured store of reusable information across tasks.

The paper divides experience memory into three components:

This separation is quietly important. Many “memory-enabled” agent systems blend these categories into one vague store. That creates practical problems. A user preference is not the same kind of object as a verified fact. A reusable workflow is not the same as one historical transcript. An SOP should generalize; a task trace should usually expire.

STACKPLANNER’s experience memory module lets an Experience Search agent retrieve relevant prior entries and inject them into the current task memory. The intended benefit is cross-task generalization. Instead of starting every new task from zero, the coordinator can reuse past strategies, factual knowledge, and procedural patterns.

The business interpretation is straightforward but should not be exaggerated. This is not a magical “corporate brain.” It is closer to a structured operating memory for agent workflows. It can help when prior tasks contain reusable patterns. It can hurt if the memory store is poorly curated, outdated, over-personalized, or full of synthetic experience that does not transfer.

The paper itself acknowledges a cold-start problem in long-term memory. Experience memory is useful only after there is enough relevant experience to retrieve. Until then, the system still needs strong defaults, careful retrieval controls, and human supervision. Yes, the memory needs memory. No one said this would be elegant.

Reinforcement learning is used to train coordination, not just answer generation

The paper also trains the coordinator with reinforcement learning. This part is easy to misread.

The paper is not merely saying: “We used RL, therefore the agent is smarter.” The more specific claim is that planning, retrieval, and memory operations can be treated as part of a learnable decision process. The policy generates a trajectory of actions while using an external search engine and a structured memory stack. It is optimized with Group Relative Policy Optimization, applying action-level rewards through token-level updates.

For a business reader, the implementation detail matters less than the design implication: the coordinator is trained to choose coordination actions, not just to produce final text. That includes when to plan, when to delegate, when to revise memory, and when to finish.

This is the difference between training an employee to write a good answer and training a manager to run the work process that produces the answer. The latter is harder to evaluate, harder to debug, and often more valuable.

It also changes how we should read the benchmark results. If STACKPLANNER improves performance, the likely reason is not one isolated component. The gain comes from a bundle: hierarchical decomposition, active task memory, structured experience memory, retrieval, and RL-trained coordination. The ablation table helps separate some of that bundle, but not every engineering contribution is independently isolated.

The main results support the mechanism, but the absolute scores stay modest

The paper evaluates STACKPLANNER on four benchmark settings: 2WikiMultiHopQA, MuSiQue, GAIA, and FRAMES. It compares against naive baselines, single-agent methods, multi-agent systems, and agentic-RL baselines using Qwen2.5-3B and Qwen2.5-7B backbones.

The main table reports F1 scores. STACKPLANNER is strongest across the reported columns. The results are not subtle, but they require careful interpretation.

The strongest reading is that STACKPLANNER improves benchmark performance across several retrieval-heavy, multi-step tasks. The more disciplined reading is that the improvement does not mean the system is production-ready. GAIA remains difficult: 7.71% F1 for Qwen2.5-3B and 9.45% for Qwen2.5-7B are not numbers one would casually deploy into a mission-critical workflow unless one enjoys receiving legal emails.

This is not a criticism of the paper. It is the correct reading of the evidence. The paper shows that explicit memory control helps relative to baselines. It does not show that autonomous multi-agent systems can now reliably handle broad real-world work without guardrails.

The ablation table is the paper’s clearest evidence for the memory thesis

The main table says STACKPLANNER performs better. The ablation table explains why the memory story is plausible.

Using Qwen2.5-3B, the paper removes task memory, experience memory, and both memory components. The performance drops across all four datasets.

The largest drops come when both memory components are removed. That supports the paper’s central claim: task memory and experience memory are complementary.

The more interesting detail is that the two memory types matter differently across datasets. Removing experience memory is especially damaging on FRAMES, where F1 falls from 16.23 to 7.69. Removing task memory is especially damaging on MuSiQue, where F1 falls from 16.48 to 10.76. The paper does not turn this into a separate theory, and we should not overfit a few benchmark columns. Still, the pattern is intuitive.

Task memory helps when reasoning steps need to be kept clean inside a single task. Experience memory helps when reusable factual or procedural patterns improve coordination across tasks. Their combined removal produces the worst performance because the coordinator loses both local state control and reusable guidance.

That is the result business teams should notice. Memory is not one feature. It is at least two operational layers: the live workspace and the institutional playbook.

The case studies show behavior, not proof

The appendix includes two case studies. These are not main evidence in the same sense as the benchmark tables. Their likely purpose is qualitative illustration: they show how the system behaves during a task.

The first case is a medical multi-step question-answering example. The system begins with a broad retrieval query about cerebrospinal fluid pressure and receives irrelevant information about hydrocephalus. Instead of carrying the irrelevant result forward, the coordinator reflects, removes the bad search result, issues a more specific search, summarizes the relevant evidence, and delegates final answering to a report agent.

This is a clean illustration of memory pruning. The coordinator does not merely “try again.” It repairs the task state before trying again.

The second case is a deep research and report generation example about multi-agent system frameworks capable of report generation. The figure shows an output report with sections such as key takeaways, framework comparison, workflow, technical challenges, and future outlook. Its likely purpose is to demonstrate long-horizon report synthesis with active memory management and long-term memory usage.

But this case should be read carefully. It does not independently validate the industry claims inside the generated report. It shows that STACKPLANNER can produce a structured report-like artifact over a longer task. That is useful. It is not the same as proving factual reliability in live enterprise research.

This distinction matters because agent papers often include impressive-looking case outputs. A polished report is not automatically a correct report. The business question is not whether the agent can generate a structured document. It is whether the workflow preserves source quality, handles contradictions, cites evidence, and avoids carrying forward bad assumptions. STACKPLANNER’s memory-control mechanism is relevant to that question, but the case study alone does not settle it.

What businesses should take from STACKPLANNER

The practical lesson is not “use this exact architecture tomorrow.” The paper is early research, benchmark-based, and built around a specific experimental setup. The better lesson is architectural.

If a company is building agent workflows for research, compliance, due diligence, market intelligence, internal reporting, or operations analysis, STACKPLANNER suggests a useful design principle:

Treat the supervisor’s memory as a governed workspace, not a transcript.

That principle leads to several concrete design choices.

The ROI relevance is also narrower than many vendors would prefer. STACKPLANNER is not mainly about cheaper inference, although cleaner memory may reduce wasted context. It is about reducing coordination waste: repeated searches, polluted state, redundant delegation, and final answers built on stale intermediate assumptions.

In a production workflow, that can matter more than raw model quality. A stronger model with chaotic memory may still fail a long task. A smaller model with disciplined memory may produce a more controllable process. The paper’s use of Qwen2.5-3B and Qwen2.5-7B reinforces that point: coordination architecture can extract more from relatively small backbones. It does not prove small models are sufficient for every enterprise task. It does suggest that process design deserves more attention than it usually gets.

Where the evidence stops

The paper is valuable, but its boundaries are clear.

First, the evaluation is benchmark-based. The authors test on multi-hop QA and agentic benchmarks, including 2Wiki, MuSiQue, GAIA, and FRAMES. These are useful stress tests, especially for retrieval and multi-step reasoning. They are not the same as messy production environments with ambiguous goals, private data, changing policies, incomplete permissions, and human escalation.

Second, GAIA is evaluated using 127 text-only validation questions. GAIA as a benchmark includes multi-modal and web-interaction demands, but this paper’s selected evaluation slice is narrower. That does not invalidate the result. It limits what it can claim.

Third, the paper acknowledges limited support for multi-turn interactions. The task-level memory is primarily designed for single-turn tasks and does not explicitly model multi-turn conversational dependencies. That matters for enterprise systems because many valuable workflows are not one-shot. A client changes requirements. A manager asks follow-up questions. A compliance officer challenges an assumption. The memory model has to survive not only long tasks, but shifting conversations.

Fourth, experience memory has a cold-start problem. If there is little prior experience, there is little useful experience to retrieve. Simulated users may help initialize memory, but the paper notes that such initialized experiences may generalize poorly to real or diverse user behaviors.

Fifth, the reported computational setup is non-trivial. The experiments used a machine with eight NVIDIA GeForce RTX 3090 GPUs, and the paper reports training time of roughly 45,713 seconds, with inference taking 40 to 300 seconds per sample depending on task complexity. That does not make the approach impractical, but it does mean teams should not confuse the architecture with a lightweight prompt trick.

These limitations point to the next engineering questions: Can memory actions be audited? Can pruning preserve enough provenance? Can experience memory age, expire, and be corrected? Can the system support multi-turn enterprise workflows without turning every conversation into a historical landfill? Charming problem. Very “agentic.”

The deeper shift: from context accumulation to state management

STACKPLANNER is part of a broader shift in how agent systems need to be judged. The first generation of agent demos often emphasized tool use: the agent can search, browse, call APIs, write reports, and coordinate sub-agents. The next stage is less glamorous and more important: state management.

A long-horizon agent is only as good as the state it carries forward. If the state is polluted, every later step becomes suspect. If the state is too thin, the system repeats itself. If the state is too verbose, the model gets lost. If the state confuses user preference with factual evidence, the agent starts treating taste like truth. That is how workflows quietly become unreliable.

STACKPLANNER’s contribution is to make this problem explicit. It proposes a coordinator that can revise memory, not merely consume it. It separates task memory from experience memory. It trains coordination actions through reinforcement learning. Its experiments show consistent relative gains across reported benchmarks, while also leaving enough low absolute scores and stated limitations to prevent anyone serious from declaring victory.

That is a useful kind of paper. Not because it gives enterprises a finished deployment blueprint. It does not. Because it points to the boring control layer that agent systems will need if they are going to do real work.

For Cognaptus-style automation, the message is simple: do not build agent workflows as giant conversations with tool calls attached. Build them as managed processes with state, memory policy, revision rights, and evidence discipline.

The future of agents may depend less on whether they can remember everything and more on whether they can forget the right things.

Cognaptus: Automate the Present, Incubate the Future.