IBM Research's ALTK Evolve (Agent Toolkit) agent memory toolkit and the ACE (Agentic Context Engineering) project both keep lessons as itemized, counted lists instead of summaries. They differ on the token bill.
Your AI agent knows the API. On a multi-step task, like reconciling an order across nine apps or splitting a bill between friends, it still mis-paginates a call, returns a value where you wanted a question, and confuses two people with the same name. The agent is not stupid. It is forgetting on purpose, because the design it was built on keeps throwing away the only thing that would help it next time: the small, specific lessons it earned on the last run.
Two independent teams say that habit has to stop. IBM Research's ALTK-Evolve and the ACE (Agentic Context Engineering) project published within weeks of each other this fall. Both reject the standard move in agentic memory, which is to compress a session's hard-won lessons into a tidy summary and write that summary back into the prompt. Instead, both keep the lessons as a long, itemized list. The list grows, gets counted, and gets consulted on the next task.
That shared rule is the design point. The token-count gap IBM Research highlights is downstream of it, and the rule is now consensus between two groups that did not coordinate.
A quick doorway: an LLM agent is a language model wrapped in a loop that calls tools, reads results, and decides what to call next. "Agentic memory" is the persistent note the loop carries across runs, the thing that is supposed to make the agent better at its job the second time around. Most designs write that note as a paragraph. Both ACE and ALTK-Evolve write it as a table of distinct entries with counters attached, because summaries have a habit of dropping the detail that mattered.
The two designs fail in similar ways without that choice. The first is brevity bias: when a system is asked to compress, the model rounds the lessons down to the blandest version, and the agent stops being able to tell two people with the same name apart. The second is context collapse: as the memory grows, the agent stops being able to find the right entry in it, so it acts on a near-match instead of the right one. Both papers name these failure modes explicitly, and both treat them as the reason to refuse compression in the first place.
Where the systems diverge is in how they manage the long list. ACE grows a single playbook and runs a three-step loop on every new task: a Generator produces candidate answers, a Reflector scores the run against the playbook, and a Curator edits the playbook, merging near-duplicate entries by embedding similarity and tagging each surviving bullet with helpful and harmful counters. ALTK-Evolve instead keeps each guideline individually retrievable, with a per-guideline support count that decides whether a rule is still earning its place, so a weak lesson can be pruned without rewriting the whole playbook. Same rule against compression, different shape of bookkeeping.
The token bill is where IBM Research draws the line. Per the IBM Research post, delivering the right lesson at the right time costs less in ALTK-Evolve's split-guideline design than in ACE's monolithic playbook, and the post frames that as the headline result. The framing is the authors' own: the underlying papers put the design rule first and the cost comparison second. The honest read is that the cost delta is plausible and unverified by an independent benchmark so far. The reference set includes the IBM Research comparison, not a third-party re-run.
The published numbers trace to the IBM Research and ACE papers themselves. Replication on a shared benchmark across teams has not appeared in the reference set. The comparison is shaped by the same author group that built ALTK-Evolve, so the cost claim should be read as a self-reported result until a neutral run lands.
ALTK-Evolve's code is public on GitHub and the intro post lays out the rule in plain language. The next move is whether the agent-tooling community runs the two systems on a shared multi-step benchmark and reports the token and accuracy numbers side by side. The design rule is now consensus. The cost question is the one that still has to be settled outside IBM Research.