What is a memory contract for an LLM agent?

A memory contract defines what each decision in the agent's loop is allowed to see from past decisions. The standard contract appends everything to every prompt. The bounded contract assembles a fresh prompt from typed retrieval with no raw transcript appended.

Why does bounded memory matter for long-horizon agents?

Without a bounded contract, the prompt grows linearly with decisions and turns into a jumbled mixture where no single memory component can be isolated. Bounded memory caps prompt size and makes each layer individually ablatable.

What did the AgenticSTS paper find?

On Slay the Spire 2, where frontier LLMs get zero wins and humans win 16%, the bounded contract showed directional evidence that triggered skills produce the largest lift (3/10 to 6/10 wins). The key contribution is the testbed itself — 298 trajectories with condition tags for community study.

Does bounded memory outperform accumulating context?

The paper does not claim this. The contribution is the contract design and the reusable testbed, not a win over accumulating context. A controlled comparison is left as future work.

What does this mean for production agents?

If you cannot ablate a single component of your agent's memory, you cannot attribute success or failure to it. Bounded contracts turn memory engineering from guesswork into science.

Your agent's memory is a contract, not a bucket

Memory for long-horizon agents is not storage. It is a contract about what each decision is allowed to see. A new benchmark shows what bounded, typed retrieval reveals.

TL;DR: Memory for a long-horizon LLM agent is not a bucket you fill. It is a contract about what each future decision is allowed to see. The AgenticSTS paper (Cheng et al., arXiv 2607.02255, July 2026) builds a bounded-memory testbed on Slay the Spire 2. Every decision prompt is freshly assembled from five typed layers with no raw transcript appended. The prompt stays O(1) regardless of run length, and every layer can be ablated in isolation. The paper releases 298 trajectories with condition tags, frozen snapshots, and analysis scripts. It is not a victory lap for bounded memory. It is a reusable methodology for studying how explicit memory layers shape agent decisions.

Key takeaways:

Memory for long-horizon agents is a contract, not a bucket of text

AgenticSTS builds a bounded contract: fresh prompts from five typed layers, no raw transcript

Frontier LLMs get 0 wins on Slay the Spire 2. Humans win 16%. Hard but not saturated

L5 triggered skills show the largest observed lift: 3/10 to 6/10 wins (directional at this sample size)

Cross-backbone transfer is fragile: Gemini-trained skills lifted Qwen +84.5% but hurt DeepSeek -18.1%

The first time I built a long-horizon agent, I tracked everything.

Every observation. Every tool call. Every reflection. The context grew. More and more. Until nothing worked and I could not tell what broke it. Was it the stale observation from 50 turns ago? The tool output that contradicted the reflection? The instruction that got buried between turn 37 and turn 38?

I had no way to answer. The transcript was a jumbled pile of everything. I could not tell which memory component caused the failure because the failure was the pile itself.

The AgenticSTS paper formalises this problem. Memory for a long-horizon agent is not a place to store text. It is a contract about what each decision is allowed to see. The default contract (append everything to every prompt) is the worst contract you can sign.

The bounded contract

AgenticSTS replaces the growing transcript with a typed retrieval interface. Every decision prompt is assembled fresh from five layers. Each layer has a different role.

L1. Fixed protocol instructions. Never changes.

L2. State-specific schemas and legal action formats. Changes per state.

L3. Retrieved game rules. Filterable knowledge.

L4. Episodic summaries. What happened before.

L5. Triggered strategic skills. Procedural policies.

No raw cross-decision transcript is appended. The prompt stays capped at a configured size regardless of whether the run has 10 decisions or 500. Every layer can be independently toggled, frozen, or ablated.

This is the difference between a filing cabinet and a workspace. The context window is for current reasoning. Everything else should be retrieved on demand.

I wrote about this before. Context engineering is deciding what the agent remembers, what it forgets, and what it never sees. The bounded contract is the formal version of that intuition. Your context window is a workspace, not a filing cabinet covered the four strategies. AgenticSTS gives you the methodology to measure whether your memory strategy works.

The testbed

The paper instantiates this contract in Slay the Spire 2, a turn-based deck-building roguelike. A run requires hundreds of tactical and strategic decisions under random card draws, enemies, events, and map routes.

The task is hard. Frontier LLMs get zero wins on the public benchmark at the lowest difficulty across five configurations. The developer-reported human win rate at the same difficulty is 16%. This is a genuinely difficult, non-saturated testbed for long-horizon agent memory.

Inside the bounded contract, the baseline with no memory scaffolding wins 3 out of 10 games. Adding L5 triggered skills lifts that to 6 out of 10. At this sample size the difference is directional, not statistically significant (Fisher exact p is around 0.37). But it is the largest observed signal in the balanced matrix.

L4 episodic memory (what happened in previous runs) was saturated at low difficulty. It made no measurable difference at A0. On the higher difficulty ladder (A6-A8), where the agent faces compounding challenges across multiple runs, episodic memory mattered.

This is the tradeoff in the centre. Bounded memory does not guarantee improvement. It guarantees that when improvement happens, you know which layer caused it.

What the testbed enables

The paper releases 298 completed trajectories with condition tags, frozen memory and skill snapshots, decision-time prompt records, and Wilson bootstrap analysis scripts. A reader can recompute any reported cell or slice by condition tag.

This is the real contribution. Not a claim that bounded memory beats accumulating context. The paper explicitly leaves that comparison to future work. The contribution is a reusable methodology. A testbed where the memory interface is inspectable, ablatable, and reproducible.

If you have ever debugged an agent that worked in development but failed in production, you know why this matters. You had no way to replay the exact memory state that produced the failure. The bounded contract gives you that.

Cross-backbone transfer is not guaranteed

The paper tests whether a Gemini-trained memory and skill stack transfers to other models. The result is worth reading twice: the same frozen stack lifted Qwen’s mean score by 84.5% but reduced DeepSeek’s by 18.1%.

Your memory architecture is not model-agnostic. The contract that works for one backbone may hurt another. If you are building an agent that will run on different models, the memory layer needs separate validation per backbone.

This connects to the skill-library problem I covered in the phase transition hiding in your agent’s skill library. Selection accuracy collapses at around 80 to 90 skills due to semantic confusability. Memory is subject to the same per-library, per-backbone sensitivity. There is no universal configuration.

When bounded memory is not enough

The bounded contract fixes the context-growth problem. It does not fix the skill quality problem. L5 skills in this testbed are triggered strategic policies. They encode what to do in specific game situations. If the skill library is badly designed, bounded memory makes bad skills retrievable faster.

The paper’s self-evolve mechanism (mistake-driven skill discovery) addresses this. It reads combat losses, runs A/B checks, and applies a four-level write gate before admitting new skills. Many candidates are rejected or merged. This is the right rigour for skill library growth.

FAQ

What is the minimum viable bounded contract for my agent? Separate what stays fixed (system prompt, task instructions) from what changes per decision (state, retrieval). Never append raw tool outputs to the next prompt. Write them to a typed store and retrieve by need.

How do I know which memory layers matter for my use case? Ablate them one at a time. Build your agent so that every memory component can be independently disabled. Run with it, run without it. The difference is your answer.

Does this work for coding agents too? The paper tests a game, not code. But the mechanism (typed retrieval with bounded context) generalises to any loop that makes repeated decisions. Coding agents that accumulate diffs and error logs face the same jumbled-transcript problem.

What is the tradeoff? Bounded memory requires explicit retrieval design. You need to define the layers, the retrieval strategy, and the write gate before the agent runs. That up-front design cost pays off in debuggability.

Is bounded memory always better than accumulating context? The paper does not claim this. The testbed exists so the community can run the controlled comparison. For now, bounded memory gives you something accumulating context does not: the ability to know why.

Your context window is a workspace, not a filing cabinet. Four context engineering strategies with code.
Your agent’s memory is making it a yes-man. How memory introduces sycophancy in agents.
The phase transition hiding in your agent’s skill library. Selection accuracy collapses at around 80 to 90 skills.

This article was published on Agentic Up (https://agenticup.dev): practical guides for developers and founders building with AI agents. Reach me at [email protected].