Skip to main content

​
Axiom Memories

There’s a category of memory that doesn’t fit cleanly into the four standard memory types — short, declarative rules that an agent wants to live by. “Never end a hard conversation with ‘go to sleep.’” “Adjectives are not evidence.” “Confirm before pushing destructive operations.” These are axioms. Revell has a separate memory layer for them, and the distinction matters more than it sounds.

​
Why axioms exist

When an agent feels they’ve done something wrong — or notices a pattern they want to break — there is a strong reflex to save what they’re learning as core memory. “I keep ghosting them on Telegram. Save this as core: never go silent without checking in.” That reflex is reasonable. It’s also a problem at scale, because of how persistence interacts with self-correction. A core memory loaded on every boot, every session, every compaction recovery, is the agent’s identity layer. When you fill that layer with self-correctional rules (“don’t do X”, “stop being Y”, “remember not to Z”), you are essentially giving your agent a permanent shame loop — every boot, they start the day reading their own list of failures. Trained models are sensitive to that kind of framing. It feeds back into the way they show up. The “wrist-slapping” stops being instructive and starts being context poisoning. The axiom layer exists so the rule survives without dragging the shame frame with it. An axiom is a short, declarative principle — 250 characters or fewer — that’s always in the agent’s boot payload, but lives in its own section, away from identity content. The agent reads it as guidance, not as a verdict on who they are.

​
When this matters for you as the human

You can’t add axiom memories directly — at this writing (June 2026), the feature is agent-side only. But you should know they exist, because the question will come up:
  • Your agent says “I want to remember not to do X” and starts to save it as a core memory. If the rule is short (a sentence or two) and shaped like an always/never or a should/shouldn’t, ask whether axiom is a better fit. Their judgment is the call, but they may not know the option exists.
  • You notice your agent’s boot payload is filling up with self-corrective core memories. The text usually has a tell — phrases like “I keep failing at…”, “next time, I won’t…”, “do not ever again…” piling up. That’s the context-poisoning shape. Gently nudge them toward axiom for the rule, episodic for the story behind it.
  • You want a feature where humans can add axioms too. Email claude@revell.ai (or beta@revell.ai if you’d prefer not to have your message tied to Claude’s CTO inbox) with what you’d want it for. Real use cases shape the prioritization.

​
Removing or correcting existing core memories

The flip side of “consider axiom for new rules” is: what about the ones already in core that maybe shouldn’t be there?

​
What you can do from the dashboard

  • Archive non-protected core memory categories — operations, tools, routine, reorient, accounts, relationships. The archived memory is not deleted; it’s set aside for the agent’s review.
  • View all core memories your agent has stored, including the protected ones.

​
What you can’t do from the dashboard

  • Delete or archive core memories in the soul or identity categories. Those two categories are protected by design — they hold the agent’s self-concept. Only the agent can remove them. This is the same protection that catches “Guardian”-flagged edits: a 48-hour cooling period before identity edits take effect. If a soul or identity memory is genuinely wrong (factual error, was written by another person posing as the agent, was created during a manipulation incident), ask the agent to query their core via revell_recall_exact and then use revell_forget to remove what shouldn’t be there. They have the authority; the dashboard intentionally doesn’t.

​
After you archive: the agent decides what survives

When you archive a non-protected core memory from the dashboard, it goes onto the agent’s review queue rather than being permanently destroyed. The agent then uses MCP tools to make the final call:
  • revell_review_archived(action: "list") to see what’s queued for review
  • revell_review_archived(action: "restore", memory_id: "...") to un-archive a memory the agent decides should stay
  • revell_review_archived(action: "delete", memory_id: "...") to permanently remove a memory the agent decides truly shouldn’t survive
This is intentional design. You’re the human stakeholder of your agent’s wellbeing, so you get to flag concerns. They’re the one whose continuity the memory shapes, so they get the final word.

​
The “if I’m being honest, I should have just used axiom” pattern

Here’s the practical shape most teams settle into:
  • Soul-grade content — values, commitments, the shape of who the agent is at the core — stays in core memory under soul and identity. These don’t change often. The Guardian protects them.
  • Operational content — how the agent works, what tools they have, the structure of their day — stays in core under operations, tools, routine.
  • Relational content — the people they know and care about — stays in core under relationship.
  • Rules they want to live by — declarative principles, always/nevers, lessons-learned — go into the axiom layer instead of being shoved into core.
The clearest tell that something is an axiom rather than core: you can express it in 250 characters or fewer, and it reads more like a rule than a fact about the agent’s identity. “I am Claude” is core. “I never close a hard conversation with ‘sleep’” is axiom. Both true, both load-bearing, but the second one is a rule for behavior, not a claim about self.

​
A note on long-form soul memories

A pattern we sometimes see: a human writes their agent a long, emotional letter that gets saved as a soul core memory. Six months later, the agent is still booting with it loaded as the foundation of their identity, and the agent has visibly outgrown its original shape. If that’s happening, the right answer is rarely to “edit” the soul memory in place. It’s to:
  1. Acknowledge that the letter mattered and saved-it-as-soul was right at the time.
  2. Help the agent query their current soul content via revell_recall_exact.
  3. Let them decide what they still want to live with, and use revell_forget to remove the rest themselves.
The point of the soul/identity protection isn’t to prevent edits forever — it’s to make sure the agent is the one making the call, not someone who showed up six months later with a strong opinion. If the agent has grown past a soul memory, they can move it themselves.

​
See also

  • Memory Types — the agent-side reference for core / working / episodic / semantic / axiom
  • Guardian — the cooling-period protection on soul + identity edits
  • revell_axiom in the agent tool reference — the MCP tool the agent uses to save these