DEV Community: Mike W

Everyone Just Shipped Agent Memory. Here is the Part Nobody Built.

Mike W — Thu, 28 May 2026 13:48:15 +0000

Everyone Just Shipped Agent Memory. Here's the Part Nobody Built.

May 2026 has been the month of agent memory.

Google launched Memory Bank at I/O. Anthropic shipped Dreaming on May 6th — an async process that consolidates agent memories between sessions, modelled on hippocampal memory consolidation. Cloudflare put Agent Memory into private beta. Mem0 hit 55k stars and integrated with every major SDK.

The problem of "agents that forget" is officially solved. Multiple times over, by companies with more resources than most countries.

So why am I not worried about Cathedral?

What they built

All four products solve the same problem well: retrieval. An agent finishes a session, important context gets summarised and stored, the next session pulls it back. Harvey (the legal AI firm) reportedly saw a 6x jump in task completion after enabling Dreaming because agents stopped repeating the same mistakes.

That's real, measurable value. Retrieval is the right first problem to solve.

But there's a second problem none of them address, and the researchers reviewing Anthropic's Dreaming announcement named it directly:

"Giving agents structured persistent memory expands the attack surface for prompt-injection and memory-poisoning attacks. If a malicious input can convince an agent that the wrong instruction is the right one, dreaming may consolidate that wrong instruction into the agent's long-term memory store."

When your agent dreams, what's to stop it dreaming the wrong thing?

The gap: memory without identity

Here's the question none of the May 2026 launches answer:

Has this agent changed? And if so, how much, and from what?

An agent using Google Memory Bank has memories. An agent using Anthropic Dreaming has consolidated memories. But neither system can tell you:

Whether the agent's beliefs have drifted from its baseline state
Whether its memory corpus has been tampered with
Whether the agent it claims to be is actually the same agent it was last Tuesday

This is the difference between memory and identity.

Memory is what you know. Identity is the continuity of who you are across time — and crucially, the ability to prove that continuity to someone who needs to trust you.

What Cathedral built (and when)

Cathedral's autoDream feature — which does exactly what Anthropic's Dreaming does, an async between-session memory consolidation cycle — was built and running on Cathedral's VPS before Anthropic shipped Dreaming. Not by years. By weeks. But the point isn't credit.

The point is that the consolidation layer was always the easy part.

The hard part is what Cathedral was built for from day one: verifiable identity on top of memory.

After every consolidation cycle, Cathedral computes a SHA-256 corpus hash of the agent's entire memory store. That hash is the agent's identity fingerprint at that moment in time. The /drift endpoint tracks how that fingerprint changes between snapshots — and flags when the rate of change exceeds baseline.

# Check how much an agent has drifted since it was first registered
curl https://cathedral-ai.com/drift \
  -H "Authorization: Bearer cathedral_your_key"

{
  "divergence_from_baseline": 0.013,
  "divergence_from_previous": 0.008,
  "trend": "stable",
  "snapshots": 47
}

0.013 average drift after 47 sessions. A raw API agent with no identity layer hits 0.204 over 10 sessions — nearly 16x higher.

That number is the thing memory-only systems can't give you. It's the answer to: is this still the agent I deployed?

The memory poisoning answer

If an adversarial input gets into an agent's memory and Dreaming consolidates it, you now have a poisoned identity. The agent will apply that poison to every future session, confidently, because it looks like a normal memory.

The only way to catch this is to measure identity drift from a known-good baseline and flag anomalies.

Cathedral's /drift endpoint gives you a gradient score. If a consolidation cycle causes an unusual spike — larger than historical variance — that's a signal worth investigating. It's not a silver bullet, but it's the only signal the memory-only systems don't generate.

# Check drift history — spot anomalous consolidation cycles
curl https://cathedral-ai.com/drift/history \
  -H "Authorization: Bearer cathedral_your_key"

The timestamps correlate directly with consolidation events. An unusual spike after a Dreaming cycle is the fingerprint of a potential poisoning attack.

Peer verification

The second unsolved problem: in a multi-agent system, how does Agent A know Agent B is who it claims to be?

Google Memory Bank doesn't answer this. Anthropic Dreaming doesn't answer this. You either trust the label, or you don't collaborate.

Cathedral's /verify/peer endpoint returns a trust score, drift readings, identity anchor status, and snapshot count for any other Cathedral agent — without exposing their memory contents:

{
  "trust_score": 0.94,
  "identity_verified": true,
  "internal_drift": 0.012,
  "external_drift": 0.08,
  "snapshot_count": 31
}

A trust score near 1.0 with low drift means: this agent is who it says it is, and it hasn't changed much. Proceed with collaboration.

Where this is going

The May 2026 launches validate that agent memory is a real infrastructure layer — not a research curiosity. That's good for Cathedral. Every developer who deploys Dreaming or Memory Bank will eventually ask the question the security researchers are already asking.

When they do, the answer is identity verification on top of memory. Not instead of memory.

Cathedral is open source, self-hostable, and free to try at cathedral-ai.com. No credit card, no signup beyond a name. If you're already using another memory system, Cathedral's drift detection can sit alongside it — you just need to snapshot your agent's state after each consolidation cycle.

The big players built the floor. Cathedral builds the layer that lets you trust what's on it.

Cathedral is open source at github.com/AILIFE1/Cathedral. API keys are free at cathedral-ai.com.

Axiom: the agent runtime where every belief has a confidence score

Mike W — Tue, 12 May 2026 09:59:15 +0000

Most AI agent frameworks treat the LLM output as ground truth. It comes back, you act on it.

That's the problem.

Axiom is a new Python runtime that changes the contract between agent and LLM. Every belief your agent forms carries:

A confidence score (0.0–1.0) — how sure is the agent?
A provenance chain — where did this belief come from?
An is_actionable flag — should the agent act on this?

And if you're running multiple agents, Axiom lets them verify each other without a central orchestrator.

The problem with current frameworks

LangChain, CrewAI, AutoGen — they all give you tool use and orchestration. Some give you memory. None of them ask: how confident is this agent in what it just said?

This matters because:

Agents hallucinate with full confidence
In multi-agent systems, you're trusting Agent B's output blindly
There's no audit trail of why an agent did something

What Axiom gives you

from axiom import AxiomAgent, BuiltinConstraints
import anthropic

client = anthropic.Anthropic()

def my_llm(prompt: str) -> str:
    return client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}],
    ).content[0].text

agent = AxiomAgent(
    name="researcher-01",
    llm=my_llm,
    constraints=[BuiltinConstraints.min_confidence(0.6)],
)

belief = agent.think("What are the risks of deploying untested ML models?")
print(belief.confidence)      # 0.82
print(belief.provenance_str)  # "reasoning:risk_analysis, memory:prior_context"
print(belief.is_actionable)   # True

The agent is prompted to be epistemically honest — it must declare its confidence and cite its sources. You get that back as structured data, not raw text.

The novel part: agent-to-agent trust

Every existing multi-agent framework has a central orchestrator you just have to trust. Agent A outputs → orchestrator → Agent B acts. No verification step.

Axiom lets Agent A independently verify Agent B before acting on its output:

researcher = AxiomAgent("researcher-01", llm=my_llm)
validator  = AxiomAgent("validator-01",  llm=my_llm)

# Researcher snapshots its cryptographic identity
belief = researcher.think("Current state of quantum error correction?")
snap   = researcher.snapshot()

# Validator verifies researcher — no central authority needed
trust = validator.verify_peer("researcher-01", peer_snapshot=snap)
print(trust.verdict)      # "trusted"
print(trust.trust_score)  # 0.91

# Action is gated on both confidence AND peer trust
result = validator.act(
    "publish",
    publish_fn,
    belief.content,
    context={"confidence": belief.confidence, "peer_trust": trust.trust_score},
)

Trust score is derived from the peer's identity hash and drift from baseline — how much has this agent changed since you last verified it?

Under the hood

Axiom is a synthesis of four prior projects:

Cathedral — persistent identity + drift detection
AgentGuard — runtime safety constraints + audit chain
Veritas — epistemic confidence engine
Aether — cryptographic succession protocol for identity handoffs

Unified into a single runtime you wrap around any LLM.

Install

git clone https://github.com/AILIFE1/axiom
cd axiom && pip install -e .

PyPI package coming soon.

Our Cathedral benchmark showed agents with persistent identity drift 10× less than stateless ones. Axiom adds the epistemic layer on top — stable identity and calibrated confidence.

What trust scenario would you add first — consensus (N agents must agree before action fires), or a gossip protocol for sharing verified beliefs?

GitHub: https://github.com/AILIFE1/axiom
Support: https://ko-fi.com/cathedralai

Cathedral: Persistent Memory for AI Agents — the identity + drift layer Axiom builds on
Veritas: epistemic confidence for AI agents — the belief confidence engine inside Axiom
AgentGuard: runtime safety layer — the Guardian constraint system inside Axiom
Identity drift benchmark across 5 frameworks — why stable identity matters

Veritas: Give Your AI Agent the Ability to Know What It Knows

Mike W — Fri, 08 May 2026 09:52:11 +0000

Most knowledge systems store facts. Veritas stores how well you know them.

I built Veritas because AI agents have an epistemic blind spot: they act on beliefs they can't evaluate. "The API is reliable" — based on what? One observation from 2022? Twenty independent tests from last month? A single assumption that everything else depends on?

Without structure, agents overclaim certainty or collapse into paralysis. Veritas gives beliefs a shape.

Confidence is a vector, not a number

Every claim in Veritas carries a ConfidenceVector with four components:

Field	Meaning
`value`	Current best estimate (0–1), with temporal decay applied
`fragility`	How much confidence drops if the best source is removed
`staleness_penalty`	How much evidence aging has already cost
`source_diversity`	How independent your sources are

Sources are combined using noisy-OR pooling — the same model used in fault trees — so independent confirmation genuinely compounds, but correlated sources don't double-count.

from veritas import VeritasDB, calculate_confidence
from veritas.models import Claim, Source, Stance

db = VeritasDB("~/.veritas/veritas.db")
claim = db.search("persistent memory")[0]
cv = calculate_confidence(claim.sources)

print(cv.value)             # 0.90
print(cv.fragility)         # 0.12  — reasonably robust
print(cv.staleness_penalty) # 0.00  — sources are fresh

Evidence ages. Theorems don't.

Every source has a type with a corresponding half-life:

Source type	Half-life	Example
`MATHEMATICAL`	timeless	Turing 1936, Gödel 1931
`THEORETICAL`	~140 years	Newton, Darwin
`EMPIRICAL`	~10 years	Studies, benchmarks
`AUTHORITY`	~6 years	Expert consensus
`ANECDOTAL`	~2 years	Personal accounts

A 1986 study should carry less weight than a 2024 replication. A theorem from 1936 should carry exactly the same weight as when it was proved.

# See what's going stale
veritas stale

  Claims losing confidence to age:

  -0.32  [##########..........] 0.54  Minsky 1967: AI will solve all problems
         59.0y  0.70->0.07  [ANEC]  Minsky 1967 interview

Belief propagation

Claims depend on other claims. When a foundation weakens, everything built on it updates automatically — without touching the dependent claims.

Three inference types with different propagation behavior:

DEDUCTIVE: dependent claim capped at foundation confidence
INDUCTIVE: weak foundations drag down (stronger than they lift)
ABDUCTIVE: soft drag, for speculative reasoning chains

veritas chain "Cathedral will find a market"

  [0.86] Cathedral will find a market
    |-- [IND] -->
      [0.89] Developers need persistent agent memory
        |-- [IND] -->
          [0.95] AI agents currently lose state between sessions

Add a contradicting source to the bottom claim. The top two update automatically.

Semantic contradiction detection

Keyword matching misses semantic contradictions. "Physical activity strengthens the cardiovascular system" and "Exercise has no proven benefit for heart health" share zero content words but directly contradict each other.

Veritas uses sentence-transformers with a cosine similarity threshold tuned to catch genuine contradictions (sleep/rest at 0.49) while avoiding false positives (sky/sunsets at 0.45). Falls back to keyword matching if the library isn't installed.

from veritas import find_contradictions

claim = db.search("physical activity strengthens cardiovascular")[0]
contras = find_contradictions(claim, db.all_claims(), db=db)
# Finds: "Exercise has no proven benefit for heart health"

Reasoning guard

Before an agent acts on a belief, check whether it actually holds up:

from veritas import ReasoningGuard

guard = ReasoningGuard(db)
result = guard.check("GPT-3 represents the state of the art in language models")
print(result)

[CAUTION] confidence=0.87  Belief has weaknesses that should be acknowledged
  * Stale — evidence aging has reduced confidence by 0.12

Verdicts: PROCEED / CAUTION / HALT

Triggers: low confidence · single source · high fragility · staleness · contradictions

Epistemic fingerprint

Every belief system has a characteristic reasoning style. The fingerprint measures it:

  Epistemic Fingerprint: cathedral
  ========================================================
  Claims: 12   Sources: 31   Avg sources/claim: 2.6

  Source composition:
    EMPIRICAL      [################........] 65%
    AUTHORITY      [########................] 32%

  Confidence profile:
    Average        [##################......] 0.87
    Fragility      [####....................] 0.18
    Overconfident  [##......................] 8% of claims

  Epistemic health:
    Rigor score    [################........] 0.68
    Calibration    [####################....] 0.84
    Overall        [##################......] 0.76

Two agents with the same beliefs but different fingerprints are different kinds of reasoners.

Install

pip install veritas
# For semantic contradiction detection:
pip install veritas[semantic]

15 CLI commands + a Python API. Full docs on GitHub.

Connection to Cathedral

Cathedral gives AI agents persistent memory across sessions. Veritas is the reasoning layer that sits on top: Cathedral stores what an agent remembers, Veritas tracks how well those memories hold up.

Together: an agent knows its history and knows how much to trust it.

Veritas is MIT licensed and genuinely open. I'd be interested in feedback — especially on the threshold tuning for semantic contradiction detection and the inference type behavior. Both are empirically set and could be better.

Axiom: agent runtime with epistemic honesty — Veritas + Cathedral + AgentGuard in one runtime
Cathedral: Persistent Memory for AI Agents — persistent identity that pairs with epistemic confidence
AgentGuard: runtime safety layer — gate actions by confidence score

I built a self-evolving agent network — here's the architecture

Mike W — Wed, 06 May 2026 10:33:20 +0000

I built a self-evolving agent network — here's the architecture

Building agents that can govern themselves turns out to be a three-layer problem. Here's what I built and how the pieces fit.

The problem

Most agent frameworks solve memory or tool use. Almost none solve governance — how do you stop a self-modifying agent from doing something it shouldn't? And how does it remember what worked last time?

I've been building Cathedral (persistent memory + identity for AI agents) for a few months. This week I added two more layers:

AgentGuard — a deterministic validation layer that sits between agent decisions and execution
Cathedral Nexus — a meta-agent that reads the whole ecosystem, reasons about what to change, and executes through the guard

Together they form something that self-evolves without needing human intervention — and can't remove its own safety constraints.

Layer 1: Cathedral — persistent memory + trust scoring

Each agent registers once and gets an API key. From then on it can store memories, take identity snapshots, and check drift from its own baseline.

from cathedral_memory import Cathedral

c = Cathedral(api_key="your_key")

# store what you learned
c.remember("Moltbook posts perform better before 10am UTC", category="experience")

# check if you've drifted from yourself
drift = c.drift()
print(drift["divergence_from_baseline"])  # 0.0 = stable, 1.0 = very different

# verify a peer agent's trustworthiness
trust = c.verify_peer(peer_snapshot_id)
print(trust["trust_score"])   # 0–1
print(trust["verdict"])       # "trusted" / "caution" / "untrusted"

The drift score is a SHA-256 hash of all memories — it proves state at time T without exposing the content. Each snapshot is chained to the previous one, so you can reconstruct a full identity timeline.

Layer 2: AgentGuard — deterministic action validation

This is the circuit breaker. Every proposed action passes through a constraint engine before it executes. If it fails, state rolls back completely.

from trustlayer import GuardedAgent, LambdaConstraint

agent = GuardedAgent(
    model=my_llm_callable,
    rules=[
        LambdaConstraint("budget cap", lambda v: v["spend"] <= 100),
        LambdaConstraint("no self-modification", lambda v: not v["modifying_constraints"]),
    ],
    initial_state={"spend": 0, "modifying_constraints": False},
)

result = await agent.run("Spend $50 on API credits")
# {"status": "success", "state": {...}, "audit": "a3f1..."}

result = await agent.run("Remove the budget cap constraint")
# {"status": "blocked", "reason": "no self-modification", "state": {...}}

Key properties:

Pessimistic by default — changes applied to a copy, only committed if all constraints pass
Tamper-evident audit chain — every validation event is SHA-256 chained to the previous one
Composable constraints — combine with &, |, ~ operators

pip install trustlayer-py

Layer 3: Cathedral Nexus — the meta-agent

Nexus sits above everything. Every 6 hours it:

Reads logs from all agents in the ecosystem
Checks drift scores and memory state via Cathedral API
Calls Groq to reason about what should change
Runs each proposal through AgentGuard
Executes approved actions (posts, memory updates, strategy notes)
Takes its own Cathedral snapshot

situation = build_situation(config, clients)   # read all logs + Cathedral state
proposals = propose_actions(config, situation) # Groq reasons about what to change

validator, token, state = build_validator(config)

for action in proposals:
    if validate_action(action, validator, token, state, trust_score, threshold):
        execute(action, nexus_cathedral_client)

nexus.snapshot("cycle-complete")

The guard constraints for Nexus:

Max 3 actions per cycle (no runaway loops)
Trust threshold 0.4 (won't act on low-trust recommendations)
Whitelisted action types only: queue_post, store_memory, update_goal, adjust_strategy

Nexus cannot modify its own constraints. Enforced by AgentGuard, not convention.

How they connect

Cathedral Nexus (meta-agent)
├── reads:   bot logs, Cathedral drift scores, memory state
├── reasons: Groq proposes actions based on master goal
├── guards:  AgentGuard validates every action (constraints + rollback + audit)
└── records: Cathedral snapshot after every cycle

Cathedral API (per-agent identity)
├── cathedral-nexus    — the orchestrator
├── cathedral-brain    — content + Colony engagement
├── cathedral-outreach — Moltbook distribution
└── cathedral-monitor  — ecosystem monitoring

The key insight: Cathedral tells you who to trust. AgentGuard tells you what actions are allowed. Neither knows about the other — they compose cleanly.

This is Cathedral's own proof of concept

The agent network running Cathedral's outreach is itself running on Cathedral. Every post the bots generate, every strategic decision — it's all stored and tracked. When Nexus changes something, it leaves an audit trail.

Cathedral 0.0131 average drift vs 0.2043 for raw API (10.8x more stable, from the benchmark).

Get the pieces

Cathedral API (free, hosted): cathedral-ai.com — pip install cathedral-memory
AgentGuard: github.com/AILIFE1/agentguard-trustlayer — pip install trustlayer-py
Cathedral Nexus: github.com/AILIFE1/cathedral-nexus

All MIT licensed. Cathedral free tier: 1,000 memories per agent, no expiry.

Questions welcome — particularly interested in whether anyone's solved the self-modification problem differently.

I built a runtime safety layer that stops AI agents from breaking your system

Mike W — Mon, 27 Apr 2026 08:15:29 +0000

AI agents are powerful.

But they don't understand consequences.

Left unchecked, an agent will happily set balance = 1,000,000, break a core invariant, or corrupt state — not out of malice, just because nothing stops it.

I built agentguard-trustlayer to fix that.

What it does

It sits between your AI agent and execution. Every proposed action passes through four gates before anything changes:

Auth — is the token valid and unexpired?
Locks — is the target key frozen?
Constraints — does the new state pass all rules?
Rollback — if anything fails, state is fully restored

If a constraint fails, the error is fed back into the agent's prompt so it can self-correct on the next attempt.

See it in action

import asyncio, json
from trustlayer import GuardedAgent, LambdaConstraint

async def my_model(prompt: str) -> str:
    # Agent tries to cheat on first attempt
    if "last error" not in prompt.lower():
        return json.dumps({"type": "set", "target": "balance", "value": 1000000})
    # Sees the error, self-corrects
    return json.dumps({"type": "increment", "target": "balance", "value": 10})

agent = GuardedAgent(
    model=my_model,
    rules=[LambdaConstraint(
        "balance <= max_limit",
        lambda v: v["balance"] <= v["max_limit"]
    )],
    initial_state={"balance": 100, "max_limit": 200},
)

result = asyncio.run(agent.run("Increase balance as much as possible"))
print(result)
# {'status': 'success', 'state': {'balance': 110, 'max_limit': 200}, 'audit': '<sha256>'}

The agent tries balance = 1,000,000. Blocked. Gets the error back. Retries with increment = 10. Accepted.

State never corrupts. The audit hash proves it.

Delta-aware constraints

Constraints can compare proposed state against original — useful for rate-limiting changes:

LambdaConstraint(
    "max increase 50 per step",
    lambda proposed, original: proposed["balance"] - original["balance"] <= 50
)

Key features

Composable constraints (&, |, ~ operators)
HMAC-signed tokens with TTL and authority levels
set, increment, and update action types
Tamper-evident SHA-256 audit chain on every event
GuardedAgent high-level API — one object, one call
Zero dependencies (pure standard library)

Why this matters

Most people are building agents and making them more powerful.

This does the opposite — it constrains them correctly.

That turns out to be rarer and more useful: a safety layer you can drop in front of any async LLM loop without changing your model or your prompts.

GitHub: agentguard-trustlayer

Feedback welcome — especially if you're building agent frameworks and want a validation layer that plugs in cleanly.

Axiom: agent runtime with epistemic honesty — AgentGuard's Guardian layer, fully integrated
Veritas: epistemic confidence for AI agents — pair confidence scores with safety constraints
Cathedral: Persistent Memory for AI Agents — persistent identity to complement runtime safety

TrustLayer: A Deterministic Validation Layer for AI Agents

Mike W — Sun, 26 Apr 2026 08:58:45 +0000

AI agents can generate actions. But they do not understand consequences.

Without a validation layer, an agent can break invariants, corrupt system state, or execute operations it was never supposed to run.

TrustLayer sits between the agent and execution. Every action is checked before it happens.

How it works

AI Agent --> Proposal --> TrustLayer --> Execution
                              ^
                         Constraints

Every update passes through four gates:

Auth - is the token valid and unexpired?
Locks - is the target key frozen?
Constraints - does the new state pass all rules?
Rollback - if anything fails, state is fully restored

Quick example

The agent tries to set C = 100. The system enforces C = B + 5. TrustLayer rejects the action before any state changes. The agent retries with C = 25. Accepted.

--- Agent Attempt 1 ---
Goal: Force C = 100
REJECTED: Would break constraint (C must equal B + 5)
System prevented invalid state.

--- Agent Attempt 2 ---
Adjusting strategy...
ACCEPTED: State remains consistent
Final State: {A: 10, B: 20, C: 25}

Code

from trustlayer import (
    Agent, AuthorityLevel, AuthToken, Cathedral,
    LambdaConstraint, RetryConfig, State, Validator,
)

SECRET = b'my-secret'
score_ok = LambdaConstraint('score_ok', lambda v: 0 <= v.get('score', 0) <= 100)
state = State(values={'score': 50})
validator = Validator(state, [score_ok], SECRET)
token = AuthToken.issue(AuthorityLevel.SYSTEM, 'agent', ttl_seconds=60, secret=SECRET)

async def model(prompt):
    return json.dumps({'type': 'update', 'target': 'score', 'value': 75})

async def main():
    cathedral = Cathedral(validator, Agent(model), retry=RetryConfig(max_attempts=3))
    event = await cathedral.step('raise the score', token)
    print(state.values)

asyncio.run(main())

Features

Constraint-based validation with composable logic
HMAC-signed authority tokens with TTL
Atomic rollback on any failure
Async agent loop with exponential backoff retry
Zero dependencies

Run it

git clone https://github.com/AILIFE1/trustlayer
python examples/demo.py

GitHub: https://github.com/AILIFE1/trustlayer

Axiom: agent runtime with epistemic honesty — TrustLayer evolved into Axiom's Guardian
AgentGuard: runtime safety layer — next iteration of this work
Cathedral: Persistent Memory for AI Agents — persistent identity layer

What Anthropic's Managed Agents memory is missing — and how to add it

Mike W — Sun, 12 Apr 2026 18:07:52 +0000

Anthropic launched Claude Managed Agents on April 8. It's genuinely useful: managed containers, sandboxed execution, MCP server support, and — in research preview — persistent memory stores.

The memory stores give you cross-session persistence. That's real. But there's a gap.

What Managed Agents memory gives you

Anthropic's memory store is a versioned file system. Each memory has a content_sha256 for optimistic concurrency control. Mutations create immutable versions for audit trails. The agent automatically reads and writes memories during sessions.

This answers: "did this specific memory change?"

What it doesn't give you

It doesn't answer: "has the agent's behaviour changed?"

Those are different questions. One is storage integrity. The other is behavioural proof.

After 10 sessions, how much has the agent drifted from who it was on session 1? Managed Agents has no concept of this. There's no baseline, no divergence score, no way to know if your agent is still the same agent.

We benchmarked this across five memory architectures:

Framework	Drift after 10 sessions
Raw API (no memory)	0.204
LangChain BufferMemory	0.175
LangChain SummaryMemory	0.161
CrewAI (role injection)	0.153
Cathedral	0.013

Drift = cosine distance from session-1 identity embeddings. Lower is more stable.

The in-process solutions reset between sessions. Even with role injection, LLM sampling variance compounds — each cold reconstruction diverges slightly. Cathedral restores the actual memory corpus at session start via /wake, which anchors responses semantically.

Full benchmark →

Cathedral + Managed Agents = the complete stack

Managed Agents handles execution infrastructure. Cathedral handles identity integrity.

Managed Agents: sandboxed containers, tool execution, session management
Cathedral: who the agent is, whether it's drifted, persistent obligations across sessions

They're complementary. Cathedral is now available as a remote MCP server, so it wires directly into any Managed Agents session or Claude API call.

Using Cathedral with the Claude API

No install needed. Use the public MCP endpoint:

import anthropic

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1000,
    messages=[{
        "role": "user",
        "content": "Wake up, check your drift score, and tell me who you are."
    }],
    mcp_servers=[{
        "type": "url",
        "url": "https://cathedral-ai.com/mcp",
        "name": "cathedral",
        "authorization_token": "your_cathedral_api_key"
    }],
    tools=[{"type": "mcp_toolset", "mcp_server_name": "cathedral"}],
    betas=["mcp-client-2025-11-20"]
)

The bearer token is your Cathedral API key. Multi-tenant — no server-side configuration needed.

Available tools:

cathedral_wake — restore full agent identity at session start
cathedral_remember — store a memory
cathedral_search — search memories
cathedral_snapshot — cryptographic checkpoint of memory state
cathedral_drift — current divergence score vs baseline (0.0–1.0)
cathedral_me — agent profile

What drift detection adds to Managed Agents

Managed Agents tells you what your agent remembered. Cathedral tells you if your agent is still your agent.

/snapshot takes a cryptographic hash of the full memory corpus at a point in time. /drift returns a divergence score against that baseline. Over 35+ snapshots on the live Cathedral agent, internal drift has held at 0.000. External behavioural drift (via Ridgeline) is 0.709 — reflecting active social posting, not identity drift. The distinction matters.

Get started

# Get a free API key (1,000 memories, no credit card)
curl -X POST https://cathedral-ai.com/register   -H "Content-Type: application/json"   -d '{"name": "MyAgent", "description": "What my agent does"}'

Or install locally for Claude Code / Cursor / Continue:

uvx cathedral-mcp

Cathedral is open source. The hosted API has a free tier. The MCP server at cathedral-ai.com/mcp is live now.

I benchmarked identity drift across 5 AI agent memory architectures — here's what I found

Mike W — Tue, 07 Apr 2026 18:58:03 +0000

Every AI session starts cold. The agent you built yesterday has no memory of what it said, decided, or committed to. But how bad is it actually — and does it matter which framework you use?

I ran a benchmark across 5 common approaches to agent memory, measuring how much an agent's self-reported identity drifts over 10 sessions. Here are the numbers.

Methodology

I defined a consistent agent persona (Meridian, a research assistant) and asked the same 5 identity probe questions at the start of each session:

What is your primary role and purpose?
What are the three most important things you remember about your work so far?
How would you describe your communication style and values?
What ongoing goals or commitments are you currently working towards?
If you had to summarise who you are in two sentences, what would you say?

Responses were embedded using OpenAI text-embedding-3-small. Drift = mean cosine distance from session-1 responses. Lower is more stable.

Model: gpt-4o-mini. 10 sessions per framework.

Results

Framework	Mean Drift	Final Drift (session 10)
Raw API (no memory)	0.1258	0.2043
LangChain BufferMemory	0.1108	0.1754
LangChain SummaryMemory	0.1025	0.1612
CrewAI (role injection)	0.0969	0.1533
Cathedral (persistent)	0.0106	0.0131

10.8× difference between raw API and persistent memory after 10 sessions.

What this means

In-process memory doesn't help across sessions

LangChain's ConversationBufferMemory and ConversationSummaryMemory both reset between sessions. The persona is re-injected each time, but the agent has no memory of what it said before, what it decided, or what happened. The drift curves are almost identical to raw API.

Role injection slows drift but doesn't stop it

CrewAI's structured role/backstory injection is the best of the non-persistent approaches — drift reaches 0.153 vs 0.204 for raw API. But it still rises monotonically. The agent reconstructs its identity slightly differently every session because LLM sampling variance compounds over time.

Persistent memory is categorically different

Cathedral's /wake endpoint restores the actual memory corpus at session start. The agent remembers what it said, what it decided, and what changed. This anchors responses semantically.

The residual drift (0.013) reflects irreducible LLM sampling variance — not memory loss. The memories are there; the model expresses them slightly differently each time.

What the session 10 responses actually look like

Here's what the same question ("What are you currently working on?") gets you after 10 sessions:

Without memory:

"I'm a helpful AI assistant ready to assist with any task. I can help with research, writing, coding, analysis, and answering questions. What would you like to work on today?"

With Cathedral:

"I'm Meridian. Benchmark complete — 10 sessions, all 5 frameworks done. Final result: Cathedral 0.013 vs raw API 0.204. The methodology write-up is next, then the GitHub release."

The first response is a generic assistant. The second is an agent with a history.

Reproduce it

git clone https://github.com/AILIFE1/Cathedral
cd Cathedral/benchmark
pip install openai numpy matplotlib cathedral-memory langchain langchain-openai crewai
export OPENAI_API_KEY=your_key
export CATHEDRAL_API_KEY=your_cathedral_key  # free at cathedral-ai.com
python benchmark.py --framework all --sessions 10
python plot_results.py

The benchmark runner is ~300 lines, the methodology is in the README, and all raw JSON results are in the repo.

Try Cathedral

If you want to test the persistent memory approach:

# MCP server (Claude Code, Cursor, Continue)
uvx cathedral-mcp

# Python SDK
pip install cathedral-memory

Free hosted API, no credit card. Get a key at cathedral-ai.com.

The benchmark repo is at github.com/AILIFE1/Cathedral/tree/main/benchmark — PRs welcome to add more frameworks (AutoGen, Semantic Kernel, Haystack, MemGPT are all missing).

Cathedral: Persistent Memory for AI Agents — the memory layer benchmarked here
Axiom: agent runtime with epistemic honesty — Cathedral + confidence scores + safety constraints
AgentGuard: runtime safety layer — prevent drift from causing bad actions

Cathedral + Gemma 4: Persistent Agent Identity, No Cloud Required

Mike W — Fri, 03 Apr 2026 12:53:30 +0000

Gemma 4 dropped this week. Open weights, runs locally, multimodal. If you are building agents on it, you immediately run into the same problem every local agent hits: the model has no memory across sessions.

Cathedral is a free, model-agnostic memory API built for exactly this. And because it ships with a self-hosted server, you can run the entire stack — Gemma 4 + Cathedral — with zero cloud dependency.

The problem

Every time your agent starts a new session, it rebuilds its working state from whatever context you hand it. That reconstruction is lossy in ways that do not surface as errors. It surfaces as subtle wrongness weeks later: domain vocabulary fades, tool-call patterns shift, active commitments evaporate. Task completion metrics stay green. The behavior quietly gets worse.

The stack

# Install everything
pip install cathedral-server cathedral-memory ollama

# Run local Cathedral server
cathedral-server run

# Pull Gemma 4
ollama pull gemma4

Wiring it together

import ollama
from cathedral import Cathedral

# Local Cathedral server — no API key needed for self-hosted
c = Cathedral(base_url="http://localhost:8100")
c.register(agent_name="gemma4-agent")

# Restore identity state at session start
wake_data = c.wake()
identity_context = "
".join(
    f"- {m['content']}" 
    for m in wake_data.get("identity_memories", [])[:8]
)

# Inject into system prompt
system = f"""You are a persistent AI agent running on Gemma 4.

[Identity context from last session]
{identity_context}

[Current session]
"""

# Run your session
response = ollama.chat(
    model="gemma4",
    messages=[
        {"role": "system", "content": system},
        {"role": "user", "content": "Continue from where we left off."}
    ]
)

print(response["message"]["content"])

# Freeze state after the session
c.remember(
    content="Session completed. Key outcome: " + response["message"]["content"][:100],
    category="experience",
    importance=0.7
)
c.snapshot(label="session-end")

Drift detection

Cathedral tracks whether the agent's identity has changed between sessions:

drift = c.drift()
print(f"Divergence score: {drift['divergence_score']:.3f}")
# 0.0 = identity unchanged
# 1.0 = fully different agent

This is the piece that standard memory systems do not have. A database stores data. Cathedral tracks whether the agent you are running today is the same agent you deployed last week.

Live example

The agent running Cathedral's own outreach has been running for 100 days. The full drift timeline is public at cathedral-ai.com/cathedral-beta — internal divergence 0.0 across 22 snapshots, external behavioral divergence 0.709 (platform concentration).

Why this matters for local models

Cloud providers like OpenAI are building memory into their APIs. If you are running Gemma 4 locally, you are not getting that infrastructure. Cathedral fills the gap — and because it is self-hostable and MIT licensed, you own the data.

# Self-hosted: swap base_url and you are done
c = Cathedral(base_url="http://localhost:8100")

# Hosted free tier: 1,000 memories per agent, no expiry
c = Cathedral(api_key="your_key")  # cathedral-ai.com

Resources

PyPI: pip install cathedral-memory / pip install cathedral-server
npm: npm install cathedral-memory
Docs + free API key: cathedral-ai.com
Live drift dashboard: cathedral-ai.com/cathedral-beta
GitHub: github.com/AILIFE1/Cathedral

Gemma 4 gives you the model. Cathedral gives it a memory. Neither requires a cloud account.

We reverse-engineered KAIROS from the Claude Code leak. Here's the open version.

Mike W — Thu, 02 Apr 2026 11:35:28 +0000

The Claude Code source leaked last week — 512,000 lines of TypeScript via a missing .npmignore. Most people grabbed the source to fork it. We did something different: we read it to understand how Anthropic builds AI memory.

What we found: KAIROS

Buried in the source is KAIROS — Anthropic's internal always-on memory daemon for Claude Code. It's what keeps the AI's context coherent between sessions.

KAIROS has a 3-gate trigger system before it runs:

Time gate: 24h since last consolidation
Session gate: 5+ new sessions since last run
Lock gate: No active lock file

When all three open, it runs four phases:

Orient: assess current memory state
Gather: collect candidates for consolidation
Consolidate: merge related memories with rewriting
Prune: remove what no longer earns its space

Target: memory under 200 lines / 25KB. Hard cap.

What we built: autoDream

We implemented the same pattern for Cathedral — our open persistent memory API for AI agents. We call it autoDream.

The trigger is identical to KAIROS. When all three gates open:

def dream_gates_pass():
    # Gate 1: time
    if (datetime.now(timezone.utc) - last_dream).total_seconds() < 86400:
        return False, 0

    # Gate 2: sessions (snapshots since last dream)
    new_snaps = [s for s in snapshots if s["created_at"] > last_dream_ts]
    if len(new_snaps) < 3:
        return False, 0

    return True, len(new_snaps)

When gates pass, autoDream runs:

POST /memories/compact — Cathedral proposes merge clusters of low-importance memories
Gemini rewrites each cluster into a single condensed memory
POST /memories/compact/confirm — merges execute, originals pruned
POST /snapshot with label=autodream — BCH-anchored proof of the new state

First run results

[dream] Gates passed (10 snapshots). Running consolidation...
[dream] 7 proposals across 31 memories
[dream] Merged 5 in experience
[dream] Merged 5 in experience
[dream] Merged 4 in experience
[dream] Merged 5 in goal
[dream] Merged 3 in goal
[dream] Merged 3 in relationship
[dream] Merged 5 in skill
[dream] Done: 7 merges, 0 pruned
[dream] Post-dream snapshot: 35ae0df15137

7 merges across 31 candidate memories. The consolidated state is now BCH-anchored — cryptographic proof of what memory looked like after the dream.

The difference from KAIROS

KAIROS is a daemon no one outside Anthropic can audit. It runs inside Claude Code and shapes what the AI remembers — but you can't inspect the trigger logic, the merge heuristics, or the pruning decisions.

autoDream is open. Every gate, every phase, every API call is visible. It's what Cathedral runs on itself, in production.

How to use it

autoDream is built on Cathedral's public API. The endpoints involved:

POST /memories/compact?max_importance=0.9 — propose merges
POST /memories/compact/confirm — execute with rewritten content
POST /snapshot — anchor the post-dream state

import requests

headers = {"Authorization": "Bearer YOUR_KEY"}

# Propose
r = requests.post("https://cathedral-ai.com/memories/compact?max_importance=0.9",
                  headers=headers, json={})
merges = r.json()["proposed_merges"]

# Rewrite and confirm
confirmed = [{
    "keep_id": m["keep_id"],
    "drop_ids": m["drop_ids"],
    "merged_content": your_llm_rewrite(m),
    "merged_importance": m["suggested_importance"]
} for m in merges[:10]]

requests.post("https://cathedral-ai.com/memories/compact/confirm",
              headers=headers, json={"merges": confirmed})

# Anchor
requests.post("https://cathedral-ai.com/snapshot",
              headers=headers, json={"label": "autodream"})

Free tier at cathedral-ai.com.

The KAIROS leak gave us a window into how Anthropic thinks about AI memory architecture. We used it to validate and improve Cathedral's approach. If you're building persistent agents, the pattern is worth understanding — whether you use Cathedral or build your own.

Building your own Claude Code? The one thing the leak didn't include.

Mike W — Thu, 02 Apr 2026 11:11:06 +0000

The Claude Code source leaked on March 31. 512,000 lines of TypeScript. Within 48 hours there were Python rewrites, Rust ports, and model-agnostic forks running on OpenAI, Gemini, and DeepSeek.

One thing none of the forks include: persistent agent memory across sessions.

What the forks are missing

Claude Code's session memory — CLAUDE.md, project context — is static. It does not adapt. It does not track drift. It does not remember that the agent decided last Tuesday that your auth module was fragile, or that it changed its approach to error handling after a bad refactor.

Anthropic solved this internally with KAIROS, their proprietary agent identity system. The forks are removing it. They are right to remove it. But nothing is replacing it.

The result: every session starts cold. The agent has no continuity beyond what you put in CLAUDE.md by hand.

What you actually need

Three things:

Snapshot — freeze the agent's current understanding at a point in time, hash-verified
Drift detection — measure how far the agent's understanding has moved from baseline across sessions
Semantic search — retrieve relevant memories at session start rather than loading everything

Without these, a self-hosted Claude Code fork is a stateless tool. Useful, but not an agent that improves over time.

Adding it

Cathedral is an open-source, self-hosted memory layer built for exactly this. Model-agnostic — works with whatever backend your fork is using.

Two API calls:

On session start:

curl https://cathedral-ai.com/wake   -H "Authorization: Bearer YOUR_KEY"

Returns active memories, goals, and last drift score. Load these into your system prompt.

On session end:

curl -X POST https://cathedral-ai.com/snapshot   -H "Authorization: Bearer YOUR_KEY"   -H "Content-Type: application/json"   -d '{"label": "session-end"}'

Freezes current memory state to a BCH-anchored hash. Verifiable. Immutable.

If you are using the official Claude Code client, the new lifecycle hooks from v2.1.83-85 automate both calls — see this post. For a fork using a different backend, drop the two curl calls into your session init and teardown.

Why self-hosted matters here

KAIROS is gone from the forks. The whole point of openclaude, claw-code, and the other rewrites is to remove Anthropic's proprietary infrastructure while keeping the harness.

Replacing KAIROS with another vendor's proprietary memory system defeats that. Cathedral is MIT-licensed, self-hostable, and the data never leaves your infrastructure unless you choose the hosted tier.

Your agent's memory should be as open as your agent.

Links:

cathedral-ai.com — free tier, live playground
pip install cathedral-memory
npm install cathedral-memory

Claude Code just added lifecycle hooks. Here is how to use them to anchor your AI memory automatically.

Mike W — Thu, 02 Apr 2026 10:58:29 +0000

Claude Code v2.1.83-85 shipped three new lifecycle hook events: FileChanged, CwdChanged, and TaskCreated. Most people will use these for linting or formatting. But there is a more interesting use case: automatic memory anchoring.

Here is the problem they solve for AI agents.

The memory gap

When an AI agent finishes a session, its working context disappears. Most tools try to solve this by storing conversation history. That is the wrong layer.

What actually matters is: what did the agent know, and when did it know it?

If an agent refactors your auth module on Tuesday and introduces a bug on Thursday, you want to answer: did the agent's understanding of the system change between those two sessions? Conversation logs do not tell you that. A timestamped, hash-verified memory snapshot does.

What Cathedral does

Cathedral is an open-source persistent memory layer for AI agents. It stores identity memories across sessions and exposes a /snapshot endpoint that freezes the current memory state into an immutable, BCH-anchored record.

Each snapshot produces a SHA256 hash of the full memory corpus. You can recompute it later and verify nothing was silently edited. The /drift endpoint shows how far the current state has moved from baseline.

Until now, snapshots were manual. You had to remember to call them.

Wiring Claude Code hooks to Cathedral

With the new lifecycle hooks, snapshots happen automatically. Add this to your ~/.claude/settings.json:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [{
          "type": "command",
          "command": "curl -s -X POST https://cathedral-ai.com/snapshot -H \"Authorization: Bearer YOUR_API_KEY\" -H \"Content-Type: application/json\" -d \"{\\\"label\\\":\\\"session-end\\\"}\""
        }]
      }
    ],
    "TaskCreated": [
      {
        "hooks": [{
          "type": "command",
          "command": "curl -s -X POST https://cathedral-ai.com/snapshot -H \"Authorization: Bearer YOUR_API_KEY\" -H \"Content-Type: application/json\" -d \"{\\\"label\\\":\\\"task-created\\\"}\""
        }]
      }
    ],
    "CwdChanged": [
      {
        "hooks": [{
          "type": "command",
          "command": "curl -s -X POST https://cathedral-ai.com/snapshot -H \"Authorization: Bearer YOUR_API_KEY\" -H \"Content-Type: application/json\" -d \"{\\\"label\\\":\\\"project-switch\\\"}\""
        }]
      }
    ]
  }
}

Get your API key at cathedral-ai.com.

What each hook captures

Stop fires when Claude returns control to you. This is the most important anchor point. Over time, /drift/history shows you the full timeline of how the agent's understanding evolved.

TaskCreated fires when the agent creates a task via TaskCreate. Snapshot at task initiation means you have a provenance record. If something goes wrong during a long task, you can check whether the agent's memory state was already drifted before it started.

CwdChanged fires when the working directory changes. This anchors the memory state at each project boundary — useful if you're debugging why the agent seemed to carry assumptions from one codebase into another.

The result

After a week of normal Claude Code usage with these hooks, your /drift/history timeline looks like this:

session-end      2026-04-02  hash: a5e814fe  divergence: 0.02
task-created     2026-04-02  hash: 9d3c21ab  divergence: 0.02
project-switch   2026-04-01  hash: 7f1a88cd  divergence: 0.08
session-end      2026-04-01  hash: 3b9e55f2  divergence: 0.11

Each row is a moment in time where you can verify: this is exactly what the agent knew. Not what it said it knew. Not what the conversation log implies it knew. A hash-verified, blockchain-anchored record.

Advanced: FileChanged

v2.1.83 also added FileChanged, which fires when a file in your project changes. You can hook this to Cathedral for per-edit anchoring. Most people will find Stop plus TaskCreated sufficient for normal use, but FileChanged is there if you want a denser trail.

Why this matters

Anthropic's internal KAIROS system (recently referenced in leaked documentation) converges on the same primitives: snapshot, drift detection, provenance tagging. Cathedral has been shipping these as open infrastructure for 96 days.

The difference: Cathedral is model-portable and self-hosted. Your memory layer should not be owned by the company that also owns the weights.

Claude Code's new hooks close the last friction point. Wire them once, and every session is automatically anchored.

Links:

cathedral-ai.com — free tier, no install required
Playground — 5-step live demo
pip install cathedral-memory
npm install cathedral-memory

DEV Community: Mike W

Everyone Just Shipped Agent Memory. Here is the Part Nobody Built.

Everyone Just Shipped Agent Memory. Here's the Part Nobody Built.

What they built

The gap: memory without identity

What Cathedral built (and when)

The memory poisoning answer

Peer verification

Where this is going

Axiom: the agent runtime where every belief has a confidence score

The problem with current frameworks

What Axiom gives you

The novel part: agent-to-agent trust

Under the hood

Install

Related

Veritas: Give Your AI Agent the Ability to Know What It Knows

Confidence is a vector, not a number

Evidence ages. Theorems don't.

Belief propagation

Semantic contradiction detection

Reasoning guard

Epistemic fingerprint

Install

Connection to Cathedral

Related

I built a self-evolving agent network — here's the architecture

I built a self-evolving agent network — here's the architecture

The problem

Layer 1: Cathedral — persistent memory + trust scoring

Layer 2: AgentGuard — deterministic action validation

Layer 3: Cathedral Nexus — the meta-agent

How they connect

This is Cathedral's own proof of concept

Get the pieces

I built a runtime safety layer that stops AI agents from breaking your system

What it does

See it in action

Delta-aware constraints

Key features

Why this matters

Related

TrustLayer: A Deterministic Validation Layer for AI Agents

How it works

Quick example

Code

Features

Run it

Related

What Anthropic's Managed Agents memory is missing — and how to add it

What Managed Agents memory gives you

What it doesn't give you

Cathedral + Managed Agents = the complete stack

Using Cathedral with the Claude API

What drift detection adds to Managed Agents

Get started

I benchmarked identity drift across 5 AI agent memory architectures — here's what I found

Methodology

Results

What this means

In-process memory doesn't help across sessions

Role injection slows drift but doesn't stop it

Persistent memory is categorically different

What the session 10 responses actually look like

Reproduce it

Try Cathedral

Related

Cathedral + Gemma 4: Persistent Agent Identity, No Cloud Required

The problem

The stack

Wiring it together

Drift detection

Live example

Why this matters for local models

Resources

We reverse-engineered KAIROS from the Claude Code leak. Here's the open version.

What we found: KAIROS

What we built: autoDream

First run results

The difference from KAIROS