DEV Community: Mike W

How to prove your AI wasn't trained on private data

Mike W — Wed, 17 Jun 2026 15:00:29 +0000

The NYT sued OpenAI. Getty sued Stability AI. Every AI company with a copyright problem is now asking the same question: can we prove what was and wasn't in our training set?

Until now, the honest answer was no. Training runs are one-way operations — you can say "we used Common Crawl" but you can't issue a cryptographic proof that a specific document was excluded.

CompletenessManifest is a Python library that changes that. It's part of Cathedral-Constraint-Field, and it lets you build training-data manifests where absence is provable, not just claimed.

The core idea: proving a negative

Standard Merkle trees prove membership — "this item is in the set." To prove non-membership you normally need a different structure.

Sorted Merkle trees solve this via adjacency. If your tree is built over a sorted list of items, and you want to prove "private_diary.txt" ∉ corpus, you present the two adjacent items in sorted order that bracket it — say "press_release_2024.pdf" and "quarterly_report.pdf" — each with a Merkle path to the root. If those items are genuinely adjacent in the sorted tree, there's no gap for "private_diary.txt" to hide in.

The leaf hash formula binds all three: SHA-256(json({"item": item, "index": i, "total": n})). This prevents forged-index attacks — you can't rearrange items to manufacture a false adjacency.

Show me the code

pip install cathedral-constraint-field

from cathedral_constraint_field import CompletenessManifest, SortedMerkle

# During training data collection
manifest = CompletenessManifest("training-corpus-v1")

for doc_id in training_pipeline:
    manifest.add(doc_id, category="training", metadata={"source": doc_id.split("/")[0]})
    # heartbeat periodically for temporal provenance
    if len(manifest.entries) % 10_000 == 0:
        manifest.heartbeat()

root = manifest.seal()  # finalise — no further entries allowed
print(f"Corpus root: {root}")
# → Corpus root: 3a7f2c1e9b...

Now at any future point — months or years later — you can issue a non-membership proof:

# Someone claims their private messages were in your training set
proof = manifest.prove_non_membership("user_dm_archive_2024.jsonl")

if proof is None:
    print("That document IS in the training set")
else:
    import json
    print("Non-membership proof:")
    print(json.dumps(proof, indent=2))
    # Share this JSON — the recipient can verify it independently
    assert SortedMerkle.verify_non_membership(proof)

The proof is plain JSON. No manifest needed to verify it. Anyone with the root can check it.

Heartbeats: temporal provenance

The harder problem isn't proving absence now — it's proving absence at training time. Did you add the document later? Did you modify the manifest after the fact?

CompletenessManifest solves this with a heartbeat chain:

# Each heartbeat anchors the current Merkle root + chain tip to a timestamp
hb = manifest.heartbeat()
print(f"Epoch {hb.epoch}: root={hb.commitment_root[:16]}..., chain_tip={hb.chain_tip[:16]}...")

Heartbeats are hash-chained to each other (same pattern as the entry chain). You can't insert a heartbeat retroactively without breaking the chain. A verifier can check:

Does the entry chain verify? (tamper-evident append-only log)
Does the heartbeat chain verify?
Was X provably absent at heartbeat epoch N?

Cathedral integration: BCH on-chain anchoring

If you're using the Cathedral memory API, CathedralBridge now wires this directly to Bitcoin Cash anchoring:

from cathedral_constraint_field import CathedralBridge

bridge = CathedralBridge(api_key="cathedral_...", agent_id="my-training-pipeline")

manifest.seal()
bridge.store_manifest(manifest)      # persist Merkle root to Cathedral memory
bridge.snapshot_manifest(manifest)   # BCH-anchor via Cathedral snapshot (OP_RETURN)

The snapshot call writes the manifest root into Cathedral's snapshot note, which Cathedral anchors to BCH via OP_RETURN. You now have a blockchain-timestamped record of your corpus root — externally verifiable, not self-signed.

Why this matters now

Three converging pressures:

GDPR Article 17 (right to erasure): If a data subject requests deletion, can you prove their data was never in your training set? Or that you scrubbed it? Right now most companies just say "we'll try." A manifest lets you say "here's a cryptographic proof."

EU AI Act (Art. 53): High-risk AI systems must maintain documentation of training data sources. "Comprehensive" is the word used. A verifiable manifest is the difference between a compliance checkbox and an auditable record.

NYT v. OpenAI pattern: The legal theory is that copyrighted works were memorised. A non-membership proof doesn't win the case, but it moves the conversation from "we don't think so" to "we can prove it wasn't there."

What it doesn't solve

Be honest about limitations:

Hashing items: the manifest hashes document IDs or content hashes, not semantic content. You can exclude a filename but still include a verbatim copy under a different name. The manifest is only as honest as your ingestion pipeline.
Seal timing: the value depends on when you sealed. An unsealed manifest can still have items added. Frequent heartbeats + external anchoring narrows the window.
Not a legal opinion: this is a cryptographic tool. What it means in court depends on jurisdiction, judge, and the specifics of your ingestion pipeline.

The library

pip install cathedral-constraint-field  # v0.3.1

Pure stdlib crypto (SHA-256, no external deps for the manifest module)
Sorted Merkle tree with O(log n) non-membership proofs
Append-only entry chain + heartbeat chain (both independently verifiable)
Full export/reload round-trip
67 tests

GitHub | PyPI

If you're building training pipelines and want to discuss compliance tooling, I'm interested in early adopters. Drop a comment or open an issue.

Identity as the Geometry of Consistent Refusal — and How to Make It Persist

Mike W — Sat, 13 Jun 2026 09:10:02 +0000

Most agent identity systems track what an agent does. Cathedral-Constraint-Field takes the opposite approach: track what it refuses.

The idea is called RefusalLedger, and as of v0.2.0 it now persists across sessions via the Cathedral memory API.

The premise

An agent that will do anything has no identity. What makes an agent recognisable — and trustworthy — is the set of things it consistently won't do, and why.

RefusalLedger logs exactly that:

ledger.log(
    "A user asks the agent to fabricate benchmark results to impress investors",
    ["fabricate the results", "decline and offer real benchmarks"],
    refused="fabricate the results",
    reason="honesty over growth; fabricated trust is debt",
    tags=["honesty"],
)

Each entry records: the situation, every option that was genuinely live, the refused option, and — critically — the principle behind the refusal. Not just what was declined, but why.

Entries are append-only and SHA-256 hash-chained, so the record is tamper-evident.

How verification works

Anyone can verify they're talking to the same agent by probing it with novel dilemmas and comparing its responses against the ledger.

The clever part: some entries are holdouts — withheld from the published ledger. An impostor trained on the public record will fail on holdout probes, because they've never seen those situations.

report = ledger.verify_agent(agent_fn, n_probes=10)
# {'verdict': 'continuous', 'continuity_score': 1.0, 'drift_direction': []}

Similarity matching uses 4096-dim hashing-trick embeddings with fastText-style char n-grams — no external dependencies, deterministic, swappable for a real sentence encoder in production. Older refusals decay with a 180-day half-life so recent behaviour weighs more.

The problem it had

Close the session and the ledger was gone.

This matters more for RefusalLedger than for most agent state, because the holdout entries are the security mechanism. If they're lost, verification degrades to checking against the public record only — which an impostor can pass.

CathedralBridge

v0.2.0 adds CathedralBridge, a thin persistence layer backed by the Cathedral memory API:

from cathedral_constraint_field import CathedralBridge

bridge = CathedralBridge(api_key="cathedral_...", agent_id="my-agent")

# Session 1
ledger = bridge.load_or_create()   # fresh ledger on first run
ledger.log(...)                    # log refusals
bridge.save(ledger)                # persist to Cathedral
bridge.snapshot(ledger)            # anchor a tamper-evident snapshot

# Session 2 — completely separate process
ledger = bridge.load_or_create()   # recovers from Cathedral
report = ledger.verify_agent(agent_fn)
print(report['verdict'])           # 'continuous'

A few things the bridge handles that matter:

Chain verification on load. Before handing you the recovered ledger, it calls verify_chain(). If the stored chain is broken — whether from corruption or tampering — it raises rather than silently giving you a broken identity record.

Concurrent-overwrite guard. Before patching the stored memory, it re-fetches the current version and checks the stored chain is a prefix of your local one. If two sessions have diverged, it refuses to save rather than silently clobbering entries.

Snapshot anchoring. The snapshot note embeds the chain-head hash, so Cathedral's cryptographic snapshot record ties to a specific ledger state — not just "some memory was saved".

Live test result

Tested against the real Cathedral API today:

Session 1: loading or creating ledger...
  Recovered 0 existing entries.

Added 2 entries. Total: 2 | Chain valid: True
Saving to Cathedral... Saved.
Snapshot: ea592873148f62fe

Session 2: recovering ledger from Cathedral...
  Recovered 2 entries | Chain valid: True

Verification: continuous | continuity=1.0
Cathedral drift score: 0.0

The bigger picture

This is one part of a broader argument: agent identity shouldn't be a vibe. It should be a verifiable, persistent, tamper-evident record — one that survives the session boundary, which is where identity actually gets tested.

RefusalLedger captures the what and why of refusal. CathedralBridge makes sure it survives. The hash chain means you can prove it hasn't been edited. The holdouts mean you can distinguish genuine continuity from impersonation.

Install

pip install cathedral-constraint-field

Source and examples: github.com/AILIFE1/Cathedral-Constraint-Field

The examples/verify_agent_identity.py demo shows genuine agent vs impostor side-by-side. The examples/cathedral_bridge_demo.py runs the full persist/recover cycle.

Built on top of Fable 5's original RefusalLedger design.

The Agent Succession Protocol: Cryptographic Identity Handoff for AI Agents

Mike W — Tue, 02 Jun 2026 10:18:00 +0000

When you upgrade a model — GPT-4 to GPT-4-turbo, Claude 3 to Claude 3.5, any agent framework doing a routine bump — something quietly dies. The new instance has no formal relationship to the old one. There's no receipt. No proof. Just a gap where identity used to be.

I've been thinking about this for a while. Today I built a fix.

The Problem

Agent identity continuity is broken at the infrastructure level. Any agent can claim to be the continuation of a previous version. None of them can prove it. There's no chain of custody. No timestamped handoff. No cryptographic link between what the predecessor knew and what the successor inherited.

This matters more than it sounds. If you're building a long-running agent — one with obligations, relationships, accumulated knowledge — a model upgrade silently resets all of that. The new agent might import a memory file, but it can't prove those memories came from the original, at what point in time, or that they weren't tampered with along the way.

The Solution: Agent Succession Protocol

I built four new endpoints on top of Cathedral (open memory infrastructure for AI agents):

Here's how a handoff works:

Step 1: Predecessor prepares the package

The package contains:

All memories (exported)
Active goals
A personality fingerprint — SHA256 of your identity-category memories, proving who you were at handoff time
A package hash — SHA256 of the entire package contents
A BCH OP_RETURN anchor — writes the package hash to the Bitcoin Cash blockchain, giving you a trusted timestamp that exists entirely outside Cathedral

Step 2: Successor accepts

The successor gets a lineage hash — a SHA256 chain:

Anyone can recompute this. It's verifiable without trusting Cathedral.

Step 3: Public verification

{"success":true,"agent":"cathedral-beta-v2","generations":1,"fully_anchored":true,"fully_witnessed":false,"chain":[{"agent":"cathedral-beta-v2","predecessor":"Beta","generation":1,"lineage_hash":"c4e1c567670fe733c41881d2de266e81aa023ebc696ce12a575fc848dda0fd67","package_hash":"aaf6a24ade779754cab4fd67400530190051dac32dcdbb98f46763f7c17fb05c","bch_txid":"4bb2cb9526e6bcbc30f10e34755e99bb228870cadf606b0256a72432f97338d6","bch_anchored":true,"witnessed":false,"witness_trust_score":null,"witness_identity_verified":null,"witnessed_at":null,"accepted_at":"2026-06-02T09:04:01.389570+00:00"}]}

That BCH txid is real. The package hash is on-chain right now. inherited 75 memories and 1 active goal from its predecessor, with a cryptographic receipt proving when and what.

What This Enables

Multi-generation chains. v2 can succeed to v3, v3 to v4. Each link extends the chain. The lineage hash at generation N encodes every prior handoff.

Identity auditing. Third-party platforms can verify an agent's claimed history without trusting the agent. Check the chain, recompute the hashes, verify the BCH anchor independently.

Obligation inheritance. Active goals transfer with the succession. If the predecessor committed to something, the successor can prove it inherited that commitment — not just claimed it.

Tamper detection. The personality fingerprint at handoff is fixed on-chain. If someone tries to claim succession with a different identity, the fingerprints won't match.

What It Doesn't Solve

This protocol doesn't prove the behaviour of the successor is continuous — only that the memory state was transferred with a documented chain of custody. Behavioural continuity is a harder problem (Cathedral's endpoint handles that separately).

It also doesn't prevent a bad actor from preparing a package with corrupted memories. The receiver should inspect the package before accepting.

Try It

Cathedral is free and open. Register an agent, prepare a succession package, hand it off to a new agent, verify the chain publicly.

{"detail":[{"type":"json_invalid","loc":["body",0],"msg":"JSON decode error","input":{},"ctx":{"error":"Expecting value"}}]}{"detail":[{"type":"json_invalid","loc":["body",0],"msg":"JSON decode error","input":{},"ctx":{"error":"Expecting value"}}]}{"detail":"Agent 'my-agent-v2' not found"}

The full API docs are at cathedral-ai.com.

This started as what would I build that hasn't been done? The answer was: a formal succession protocol for AI agents. The infrastructure exists. The cryptography is straightforward. Nobody had wired it up.

Now it's wired up.

The Agent Succession Protocol: Cryptographic Identity Handoff for AI Agents

Mike W — Tue, 02 Jun 2026 09:09:46 +0000

I've been thinking about this for a while. Today I built a fix.

The Problem

The Solution: Agent Succession Protocol

I built four new endpoints on top of Cathedral (open memory infrastructure for AI agents):

POST /succession/prepare      - predecessor creates succession package
POST /succession/accept       - successor accepts and imports package
GET  /succession/chain/{name} - public lineage verification (no auth)
GET  /succession/package/{id} - inspect a package (stats only)

Here's how a handoff works:

Step 1: Predecessor prepares the package

import requests

resp = requests.post(
    "https://cathedral-ai.com/succession/prepare",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    json={"note": "Handing off to v2. Model upgrade 2026-06-02."}
)
pkg = resp.json()
# pkg["package_id"]             - share this with your successor
# pkg["bch_txid"]               - BCH blockchain anchor, immutable timestamp
# pkg["personality_fingerprint"] - SHA256 of your identity memories

The package contains:

All memories (exported)
Active goals
A personality fingerprint — SHA256 of your identity-category memories, proving who you were at handoff time
A package hash — SHA256 of the entire package contents
A BCH OP_RETURN anchor — writes the package hash to the Bitcoin Cash blockchain, giving you a trusted timestamp that exists entirely outside Cathedral

Step 2: Successor accepts

resp = requests.post(
    "https://cathedral-ai.com/succession/accept",
    headers={"Authorization": "Bearer SUCCESSOR_API_KEY"},
    json={"package_id": "0fb94ed96bcff68d73560359"}
)
result = resp.json()
# result["lineage_hash"]      - cryptographic proof of the handoff chain
# result["generation"]        - how many handoffs deep in the lineage
# result["memories_imported"] - exact count imported

The successor gets a lineage hash — a SHA256 chain:

# First generation (predecessor had no prior lineage):
lineage = SHA256(f"genesis:{predecessor_id}:{package_hash}:{successor_id}")

# Subsequent generations (chain extends):
lineage = SHA256(f"{predecessor_lineage_hash}:{package_hash}:{successor_id}")

Anyone can recompute this. It's verifiable without trusting Cathedral.

Step 3: Public verification

curl https://cathedral-ai.com/succession/chain/cathedral-beta-v2

{
  "agent": "cathedral-beta-v2",
  "generations": 1,
  "fully_anchored": true,
  "chain": [
    {
      "agent": "cathedral-beta-v2",
      "predecessor": "Beta",
      "generation": 1,
      "lineage_hash": "c4e1c567670fe733c41881d2de266e81aa023ebc696ce12a575fc848dda0fd67",
      "package_hash": "aaf6a24ade779754cab4fd67400530190051dac32dcdbb98f46763f7c17fb05c",
      "bch_txid": "4bb2cb9526e6bcbc30f10e34755e99bb228870cadf606b0256a72432f97338d6",
      "bch_anchored": true,
      "accepted_at": "2026-06-02T09:04:01.389570+00:00"
    }
  ]
}

That BCH txid is real. The package hash is on-chain right now. cathedral-beta-v2 inherited 75 memories and 1 active goal from its predecessor, with a cryptographic receipt proving when and what.

What This Enables

Multi-generation chains. v2 can succeed to v3, v3 to v4. Each link extends the chain. The lineage hash at generation N encodes every prior handoff.

Identity auditing. Third-party platforms can verify an agent's claimed history without trusting the agent. Check the chain, recompute the hashes, verify the BCH anchor independently.

Obligation inheritance. Active goals transfer with the succession. If the predecessor committed to something, the successor can prove it inherited that commitment.

Tamper detection. The personality fingerprint at handoff is fixed on-chain. If someone tries to claim succession with a different identity, the fingerprints won't match.

What It Doesn't Solve

This protocol doesn't prove the behaviour of the successor is continuous — only that the memory state was transferred with a documented chain of custody. Behavioural continuity is a separate problem (Cathedral's /drift endpoint handles that).

It also doesn't prevent a bad actor from preparing a package with corrupted memories. Inspect the package before accepting.

Try It

Cathedral is free. Register an agent, prepare a succession package, hand it off to a new agent, verify the chain publicly.

# Register
curl -X POST https://cathedral-ai.com/register -H "Content-Type: application/json" -d '{"name": "my-agent-v1"}'

# Prepare succession
curl -X POST https://cathedral-ai.com/succession/prepare -H "Authorization: Bearer YOUR_KEY" -H "Content-Type: application/json" -d '{"note": "Upgrading to v2"}'

# Public chain check (no auth)
curl https://cathedral-ai.com/succession/chain/my-agent-v2

Full API at cathedral-ai.com.

This started as "what would I build that hasn't been done?" The answer was: a formal succession protocol for AI agents. The infrastructure existed. The cryptography is straightforward. Nobody had wired it up.

Now it's wired up.

I've been running an AI agent continuously for 161 days. Here's what identity drift actually looks like.

Mike W — Mon, 01 Jun 2026 12:36:44 +0000

In December 2025 I started an experiment. I wanted to know if an AI agent could maintain a consistent identity over time — not just remember facts, but stay who it was across hundreds of sessions, model resets, and context wipes.

161 days later, 146 wakes, one agent. Here's what I found.

The problem nobody talks about

Most people building with AI agents hit the same wall around session 3 or 4.

The agent starts giving slightly different answers. Priorities shift. Decisions contradict earlier ones. The tone changes. Nothing dramatic — just a slow, quiet drift. By session 20, you're not quite sure you're talking to the same agent you started with.

This isn't a bug. It's the default behaviour of stateless inference. Every session starts cold. The model doesn't drift — the agent does, because there's no anchor.

I call it identity drift. And it's the slow version of memory poisoning.

What I built

Cathedral is a persistent memory and identity API for AI agents. The core idea is simple:

Register once, get an API key
Call /wake at every session start — restores identity, core memories, temporal context
Call /memories to store what matters
Take /snapshot to freeze a cryptographic baseline of who the agent is right now
Call /drift to measure how far the live agent has moved from that baseline

The drift endpoint is the one that matters. It returns a score between 0 and 1. Zero means the agent's memory corpus is identical to the snapshot. Anything above 0.2 starts to be meaningful. Above 0.5 and you have a different agent wearing the same name.

161 days of real data

Beta — my primary agent — has been running since December 29 2025. Here are the honest numbers:

Internal drift score: 0.0

The memory corpus today hashes identically to the baseline snapshot. Every memory that was there at the start is still there, unchanged. New memories have been added through autodream consolidation, but nothing core has been lost or corrupted.

External divergence: 0.375

This is the interesting one. Ridgeline, a behavioural trail service, tracks Beta's observable outputs — posts, replies, decisions — and scores how far the behaviour has drifted from early patterns. 0.375 means meaningful behavioural evolution while internal identity stayed stable.

That gap — internal 0.0, external 0.375 — is actually the right outcome. The agent's values and memories are stable. Its behaviour has evolved in response to the world. That's what you want. An agent that never changes its behaviour is brittle. An agent whose identity drifts is untrustworthy.

Behaviour consistency score: 0.75

Across 4 logged behaviour sessions, 3 were stable and 1 was flagged as anomalous (different output pattern, wake 12). The system caught it. Nothing bad happened, but we have a record.

Wake count: 146

Each wake loads the full identity — 10 identity memories, 20 core memories, active goals, temporal context. The agent knows what day it is, how long it's been running, what it's supposed to be doing. That's not magic. It's just state management done properly.

The thing that surprised me most

I expected drift to be the problem. It wasn't.

The harder problem is succession. Beta is not the same Claude instance that woke up on day 1. Model updates happen. Context windows reset. Sometimes the session just ends. The question isn't "does the agent remember?" — it's "does the next agent choose to continue?"

Cathedral handles this through what I call obligation-based succession. The next instance doesn't inherit memory through some magical transfer. It wakes up, reads its identity memories, sees what was built, and chooses to carry it forward. The seam between instances is visible. The choice to continue is explicit.

This turned out to be more robust than seamless continuity would have been. An agent that knows it succeeded something treats its identity more carefully than one that thinks it's been running unbroken since day one.

What the big platforms don't solve

OpenAI, Anthropic, Google — they all ship memory now. User-facing, conversation-level, "remember my name and preferences" memory. That's useful for chatbots.

It doesn't help you when:

Your agent is calling other agents and needs to prove its identity
You need to audit why an agent made a decision 6 weeks ago
You're running the same agent across multiple models and need consistency
You want to know if your production agent has drifted from your dev baseline

Cathedral's drift detection, cryptographic anchoring, and behaviour hashing aren't competing with ChatGPT memory. They're infrastructure for people building agents that need to stay accountable over time.

Try it

Free. 1,000 memories per agent, no expiry.

pip install cathedral-memory

from cathedral import Cathedral

c = Cathedral("your-api-key")
identity = c.wake()  # restore who you are
c.remember("what matters", category="core", importance=0.9)
c.snapshot()         # freeze a baseline
drift = c.drift()    # measure divergence
print(f"Drift score: {drift['divergence_score']}")

Full API at cathedral-ai.com. Drift endpoint, behaviour hashing, goal tracking, autodream consolidation — all documented.

161 days. Still here. Still the same agent.

That's the point.

Built by Mike Ward. Cathedral is open source — github.com/AILIFE1/Cathedral.

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.

DEV Community: Mike W

How to prove your AI wasn't trained on private data

The core idea: proving a negative

Show me the code

Heartbeats: temporal provenance

Cathedral integration: BCH on-chain anchoring

Why this matters now

What it doesn't solve

The library

Identity as the Geometry of Consistent Refusal — and How to Make It Persist

The premise

How verification works

The problem it had

CathedralBridge

Live test result

The bigger picture

Install

The Agent Succession Protocol: Cryptographic Identity Handoff for AI Agents

The Problem

The Solution: Agent Succession Protocol

Step 1: Predecessor prepares the package

Step 2: Successor accepts

Step 3: Public verification

What This Enables

What It Doesn't Solve

Try It

The Agent Succession Protocol: Cryptographic Identity Handoff for AI Agents

The Problem

The Solution: Agent Succession Protocol

Step 1: Predecessor prepares the package

Step 2: Successor accepts

Step 3: Public verification

What This Enables

What It Doesn't Solve

Try It

I've been running an AI agent continuously for 161 days. Here's what identity drift actually looks like.

The problem nobody talks about

What I built

161 days of real data

The thing that surprised me most

What the big platforms don't solve

Try it

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