Memory Has to Show Its Source

Giving an agent more remembered advice can make it look more capable while making its behavior harder to inspect. That tradeoff is worth keeping visible: memory may help with a task, but a builder still needs to know whose experience entered the prompt, when it was selected, and whether it belongs there.

The signal

Agent Memory Distillation studies a training-free memory hierarchy for smaller tool-using agents. It separates broad workflow guidance, intermediate examples, and function-level notes. The first two are supplied at the start of a task, while function notes are retrieved after a tool-call error.

Across three tool-use benchmarks, the authors report average gains for their memory approach over the evaluated baselines. They also find that the intermediate example layer contributed the largest gain and that the result depended on compatibility between the source of the memories and the agent using them. That last condition is the interesting part for governed systems. Retained context is not one generic capability.

The evidence

The paper separates memory by purpose and retrieval trigger. That makes a better experiment possible than asking whether memory, in the abstract, works. A task strategy, a worked subtask, and a reminder about a failed function call can each change a different part of an agent's behavior.

For WTK, the relevant idea is attribution before accumulation. If a memory-informed result is better, a review should be able to name the memory type, source run, selection trigger, model and tool conditions, and outcome that support that claim. If the memory is sensitive, stale, or outside its authority, the system also needs a way to keep it from silently becoming durable guidance.

The boundary

This is external research on three tool-use benchmarks and the authors' memory construction. It does not evaluate WTK memory strategies, show that imported trajectories are safe or portable, prove a benefit for every retained context layer, or establish that a memory source is trustworthy.

The reported gains are not a reason to promote generated runtime memory into a lasting WTK asset. They also do not establish that the same source will help a different agent, task, tool set, or operating condition.

The builder impact

Our take: do not call a system "memory-enabled" and stop there. State what it remembers, how it was produced, what triggers its use, what it is allowed to influence, and how a reviewer can trace a result back to it.

That discipline preserves a practical advantage of memory without letting a helpful-looking trace replace evidence. A layer that assists after a known tool-call error should be evaluated differently from a layer that steers the task from the first turn.

The WTK test

WTK can test one bounded memory layer at a time. Hold the tasks, tool permissions, model, source records, and token budget fixed. Compare a no-memory or retrieval-only baseline with one explicitly named layer, retain every planned result, and record the selection trigger and exact source provenance for each use.

The test should include rejection cases: a source that is stale, irrelevant, sensitive, or outside the layer's declared authority. That makes it possible to measure both whether the memory helps and whether its controls still hold when it should not be used.

Still unknown

We do not yet know which provenance-bound memory layer adds value under WTK conditions, how long that value lasts, or whether a useful layer survives different models and targets. The next step is a narrow controlled comparison, not a claim that WTK has validated memory distillation.