Agent memory is a system, not a larger prompt

Decide what is worth remembering

An agent trajectory contains more than a useful procedure. It can include temporary values, failed actions, private information and details that only matter to the original task. Copying the whole history into the next prompt does not explain which part should influence the next decision.

PRAXIS explores procedural memory: turning previous trajectories into structured guidance that can be retrieved during a new task. The language model stays frozen. The change is in the controller and the context it provides, rather than in the model weights. That distinction matters when describing what the project implements.

Retrieval has a budget

The implementation uses BM25 and TF-IDF retrieval, selects up to five memory cards, refreshes guidance every two steps and keeps a 2,400-character context budget. These are design choices. They constrain how much advice enters the prompt and how often the controller revisits it.

More memory is not automatically better. An irrelevant procedure can consume attention, conflict with current instructions or encourage an action that fit a different setting. A budget forces selection, but it does not prove the selected guidance is useful. The retrieval rule, update schedule and memory representation should be evaluated together.

Memory needs boundaries

PRAXIS includes memory validation, PII redaction, mutation checks and train/test isolation mechanisms. These address different risks. A structurally valid card can still contain an unhelpful procedure. Redacted text can still leak task-specific information. A guard around one kind of tool action does not establish general safety.

The evaluation split is especially important. A memory system can appear stronger if it stores information from tasks it is later asked to solve. The controller therefore needs explicit rules for where donor trajectories come from and when a memory can be promoted. Those rules belong in the experimental description, not only in the implementation.

Architecture and measured benefit are different claims

The public repository supports the claim that this controller and its evaluation mechanisms exist. It does not contain completed benchmark artifacts supporting a success-rate improvement. I describe the architecture without filling that gap with a percentage. A configured storage capacity is also not evidence that the memory contains that many useful cards.

An inspectable trace helps connect architecture to behavior: which card was retrieved, where it came from, when it entered the context and which action followed. That record is useful for debugging. It still cannot establish that memory caused a better outcome without a comparable baseline.

A convincing next evaluation would keep the underlying model, tasks and budgets comparable, use isolated data, and report failures alongside successful runs. It should ask whether the memories change task outcomes, when they hurt, and what retrieval adds in latency or context cost. Until those results exist, the useful contribution is the inspectable system and the questions it makes possible to test.