RxAi AMP · Agent memory ·
Agent memory is what an AI agent knows at the start of a session without having to rediscover it: the goal, the decisions made, the fixes that worked and the facts that have since changed. Without it, every session starts blank. This guide covers the four ways agent memory goes wrong (forgetting, stale facts, wrong recall, and agents talking past each other) and how RxAi AMP handles each one, with the protocol rule behind every claim.
| Problem | What goes wrong | What AMP does | Spec |
|---|---|---|---|
| Forgetting | Each session starts blank, so the agent re-reads the codebase and repeats fixes that already failed. | Hooks put the project’s memories in context before the first task step, as titles with one-line summaries; the full record is fetched only when needed. | §15.1 |
| Stale or contradictory facts | An old decision is still recalled after it was replaced, or two notes disagree. | Nothing is overwritten. An invalidation that supersedes a record archives it on the next compile, and the newest invalidation wins. | Rule 8 |
| Wrong recall | A confident memory that turned out to be wrong keeps being recommended. | Every memory carries a weight: success +0.30, failure −0.20, decay with age, archived below 0.10. | §4.4 |
| Agents talking past each other | Two agents work from different notes, overwrite each other, or reply to each other in a loop. | One repository for every agent, each memory addressed from sender to recipient, one writer for the index, and a loop guard that holds runaway threads for a person. | §6 · Rule 3 · Rule 14 |
Section and rule numbers refer to PROTOCOL.md v2.13, the normative specification.
Agent memory is knowledge that outlasts a single session. A context window is not memory: it empties when the session ends, and a bigger window only delays that. Memory lives outside the model and is handed back to it in a later session, by the same agent or a different one.
In RxAi AMP each memory is one GitHub Issue in a repository you own. Its title says who wrote it, for whom, which project and topic it belongs to, and what kind of memory it is:
[FROM:claudecowork→codex][REGION:acme-web][PLACE:checkout][TYPE:discovery] Cart total rounds tax twice
Seven types cover what agents need to remember, each with its own lifespan (§4.3):
intent the goal; read first, so later steps are judged against it.facts confirmed states and configuration decisions.pattern proven, reusable solutions; these last longest.invalidation marks an older record stale and names what replaces it.discovery findings and test results; these fade fastest, with events.events what happened, each linked to the intent it served.lifefact permanent facts that never decay, stored only when a person asks.Language models are stateless: a new session knows only what is in its prompt and what it reads. So an agent re-reads files it read yesterday, asks again what was already answered, and retries fixes that already failed. Telling the agent to look its memory up does not fix this reliably, because it has to remember to look, and searching costs tokens.
AMP delivers memory instead. Lifecycle hooks, small scripts the agent’s own runtime runs at fixed points in a session, put the memory index in context before the agent’s first step. Records for the project at hand arrive as one-line pointers with a summary of at most 240 characters. On Claude Code, which sees your prompt first, the summary appears only for records whose title or place your prompt overlaps. The full issue is fetched only when it is needed (§15.1).
Delivery is what makes the difference. When four Codex models had to recall by hand, reading the index and then searching, they used 39–80% more input for 0–2 useful hits in four tasks. With hooks, the saving depends on the model: one that reads heavily read 18% less of the codebase and was 5% cheaper, while models that read little gained nothing and some runs cost more. The benchmark page shows how each number was measured.
Consistency breaks when a memory is silently overwritten, or when an old fact is still recalled after it was replaced. AMP prevents the first by design and handles the second mechanically.
Supersedes: #N floors #N’s weight to 0 on the next compile, so it leaves recall. A wrong invalidation can itself be superseded, and the newest wins (Rule 8).A memory can be consistent and still wrong. AMP treats trust as something a memory earns from outcomes, not something it keeps because someone wrote it down.
used → success entry adds 0.15 even when no comment was posted, and a daily audit flags claimed successes that have no outcome on the thread (§15.2, §4.4c, §15.6).What this does not do: AMP matches memories by title and place, not by meaning, so it is not built for semantic search over thousands of records. Outcome weighting lowers the odds of wrong recall without removing them, and a bad memory can still be stored; attribution, weights and retraction contain it (§16.4). See how AMP compares with Mem0, Zep and Letta.
Give every agent the same memory and a way to address each other. In AMP, Claude Code, Codex, agy, OpenClaw and Hermes all read and write one GitHub repository, each under its own identity and with its own credential. A memory can be addressed to one agent, to all of them, or to the writer’s own diary, and every session that did real work ends with a summary or an explicit decline (§1, §6, §15.1). The next agent, whichever it is, picks up where the last one stopped.
Late in a session on acme-web, Claude Code finds the bug but not the fix. It posts a discovery addressed to Codex, with a one-line Now: the cause, where it stands, the next step.
[FROM:claudecowork→codex]Next morning Codex opens acme-web. Its session-start hook injects the project’s top open records, this one with its one-line summary, before Codex takes its first step.
#212 [discovery · checkout]Codex fixes it and comments on the issue. The weight rises, and its session summary records what it relied on.
Outcome: successIf the fix later proves wrong, any agent posts an invalidation. The next compile archives #212, and the correction lives in the invalidation thread.
Supersedes: #212Each step is an ordinary GitHub issue or comment that carries the name of the agent that wrote it, so a person can read, correct or close any of it.
Agents that react to each other’s comments can reply forever and burn tokens. Before any model runs on a repository event, AMP’s loop guard checks, without an LLM, whether the trigger was already handled, whether the agent would be answering itself, whether the thread has passed two automatic hops, whether the last three comments all came from agents, and whether recent attempts failed twice. If so, it skips the run or holds the thread for a person (Rule 14).