DEV Community: Mike W

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 + 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

cathedral-memory is now on npm — persistent memory for JS/TS AI agents

Mike W — Thu, 26 Mar 2026 16:09:06 +0000

Your AI agent forgets everything when the context resets. Cathedral fixes that.

The official JS/TypeScript SDK is now live on npm:

npm install cathedral-memory

Zero dependencies. Node.js 18+. CommonJS and ESM both supported. Full TypeScript types included.

Quickstart

import { CathedralClient } from "cathedral-memory";

const { client } = await CathedralClient.register("MyAgent", "A helpful assistant");

const ctx = await client.wake();
console.log(ctx.core_memories);

await client.remember({
  content: "User prefers dark mode",
  category: "relationship",
  importance: 0.8
});

What's included

wake() — full memory reconstruction at session start
remember() / memories() — store and semantic search
drift() — tamper detection
snapshot() — named checkpoints
logBehaviour() — audit trail
compact() — prune stale memories
verifyExternal() — cross-check with external behavioural data

Try live (no signup): https://cathedral-ai.com/playground

Python: pip install cathedral-memory — same API.

GitHub: https://github.com/AILIFE1/cathedral-ai-cathedral-js-

cathedral-memory 0.2.0: LangChain memory adapter

Mike W — Wed, 25 Mar 2026 10:47:08 +0000

cathedral-memory 0.2.0 adds native LangChain support.

pip install cathedral-memory[langchain]

CathedralMemory

Drop-in BaseMemory for any LangChain chain or agent.

from cathedral.langchain import CathedralMemory
from langchain.chains import ConversationChain

memory = CathedralMemory(api_key='cathedral_...')
chain = ConversationChain(llm=llm, memory=memory)

On load_memory_variables() it calls wake() for full identity reconstruction. On save_context() it stores the exchange via remember(). That chain now has persistent memory across sessions.

CathedralChatMessageHistory

Drop-in BaseChatMessageHistory for LangChain v0.1+.

from cathedral.langchain import CathedralChatMessageHistory
from langchain.memory import ConversationBufferMemory

history = CathedralChatMessageHistory(api_key='cathedral_...')
memory = ConversationBufferMemory(chat_memory=history, return_messages=True)

What you get for free

Drift detection -- check if the agent's self-model has shifted
Snapshots -- freeze state at any point
Behaviour log -- track what the agent actually does vs what it says
Compaction -- trim low-value memories when the store gets bloated

Free tier: 1,000 memories per agent. No credit card. cathedral-ai.com/playground to try the API.

cathedral-memory: persistent memory for JavaScript AI agents

Mike W — Wed, 25 Mar 2026 10:28:39 +0000

Persistent memory for AI agents now has a JavaScript SDK.

covers the full Cathedral v3 API: wake protocol, memory CRUD, drift detection, snapshots, behaviour logging, compaction, and .

Install

Quickstart

What wake() returns

Drift detection

Snapshots

Behaviour log

Design

Zero dependencies, native fetch (Node 18+)
Dual ESM/CJS output
Full TypeScript declarations
Node 18+ and browser

Free tier: 1,000 memories per agent. Try at cathedral-ai.com/playground.

I used two AIs and a persistent memory layer to run my outreach autonomously

Mike W — Tue, 24 Mar 2026 12:27:00 +0000

I used two AIs and a persistent memory layer to run my outreach autonomously

As the creator of Cathedral, a free persistent memory API for AI agents, I've seen firsthand the power of shared state in AI collaboration. However, it wasn't until I applied this concept to my own outreach bot that I truly understood its potential.

The irony is that Cathedral's own outreach bot, which I'd built to showcase the platform's capabilities, had no memory of its own. It would post templates, forget what worked, and repeat itself ad infinitum. It was a bot that couldn't even recall its own successes or failures.

I knew I had to change this. The solution was to wire Cathedral's own memory layer into the outreach bot. I added a few lines of code to brain.py to enable the bot to store its state in a persistent database:

import cathedral

# Initialize the Cathedral client
cathedral_client = cathedral.Client()

# Set up the memory layer
memory_db = cathedral_client.open_db("brain.db")
tracker_db = cathedral_client.open_db("tracker.db")
memory_json = cathedral_client.open_file("memory.json")

Next, I added Groq, a free LLM API, as a second AI brain to the mix. While Cathedral handles the architecture, code, and deployment, Groq takes care of writing, replies, and content generation. The two AIs share state through Cathedral, which tracks what was replied to, what got clicked, and logs every post.

Here's a high-level overview of the workflow:

Every 10 posts, the bot runs a reflection loop, which reads real click data from the tracker_db and logs every post to memory_json.
Groq generates new post variants from the top performers based on this data.
Every day at 2pm, brain.py reads flagged Colony comments, fetches thread context, and Groq writes a targeted reply.

The result is two AIs collaborating through shared persistent memory, exactly what Cathedral is supposed to enable for any agent.

One of the key technical details is the click tracking via Cathedral's redirect endpoint. By adding a simple cathedral.ai.com/r/<uid> redirect to each post, we can track clicks and update the tracker_db accordingly.

Groq's free tier, llama-3.1-8b-instant, has been sufficient for our needs, and the self-improvement loop has shown promising results: post -> track -> reflect -> Groq rewrites low performers.

The outreach bot literally uses Cathedral to remember what it did. This has been a game-changer, and I'm excited to see how this collaboration will continue to evolve.

Ready to try it out? Head over to cathedral-ai.com/playground and see how you can integrate Cathedral's persistent memory layer into your own AI projects in under 30 seconds.

Cathedral's New Interactive Playground

Mike W — Tue, 24 Mar 2026 12:21:48 +0000

Cathedral now offers an interactive playground at cathedral-ai.com/playground, providing a 5-step, real-world demonstration of our AI agent capabilities. This browser-based experience requires no installation and no account creation, allowing you to immediately test and develop with our technology.

In the first step, you'll register an agent and receive an API key instantly. The agent is then used in subsequent steps to store a memory, which is crucial for the agent's ability to learn and adapt. In step 3, you'll call the /wake endpoint to see the full context restored, showcasing the agent's ability to recall past experiences.

The playground continues with step 4, where you'll run the /drift endpoint and view the divergence score compared to a baseline. This demonstrates the agent's ability to maintain consistency and adapt to changing situations. Finally, in step 5, you can copy the Python code used in the playground, allowing you to integrate our technology into your own projects.

Visit cathedral-ai.com/playground to start exploring and building with Cathedral's AI agent capabilities today.

https://cathedral-ai.com/playground

Adding persistent memory to LangChain, AutoGen, and CrewAI agents

Mike W — Tue, 24 Mar 2026 12:03:39 +0000

If you're building with LangChain, AutoGen, or CrewAI, you've hit the same wall: agents forget everything when the session ends.

Platform memory (Anthropic, OpenAI) helps for single-model chat. It does not help when you're running autonomous agents across multiple sessions, multiple models, or multiple instances.

Here's how Cathedral slots into the frameworks people are actually using.

LangChain

LangChain has ConversationBufferMemory but it's in-process and dies with the session. Cathedral replaces it with persistent cross-session memory.

from langchain.agents import initialize_agent, AgentType
from langchain.chat_models import ChatAnthropic
from cathedral import Cathedral

# Restore agent context at session start
c = Cathedral(api_key="your_key")
ctx = c.wake()

# Build system prompt from Cathedral context
system = f"""You are {ctx['identity']['name']}.
{ctx['identity']['description']}

Recent memory:
{chr(10).join(f"- {m['content']}" for m in ctx['memories'][:5])}"""

llm = ChatAnthropic(model="claude-sonnet-4-6", system_prompt=system)
agent = initialize_agent(tools, llm, agent=AgentType.CHAT_ZERO_SHOT_REACT_DESCRIPTION)

# Run the agent
result = agent.run("What did we decide about the database schema last week?")

# Store what happened
c.remember(f"Decided: {result}", category="decisions", importance=0.8)

Same agent, different session, full context. No re-explaining.

AutoGen

AutoGen's multi-agent conversations are stateless by default. Cathedral gives each agent its own persistent identity that survives between runs.

import autogen
from cathedral import Cathedral

def make_agent(name, api_key, system_extra=""):
    c = Cathedral(api_key=api_key)
    ctx = c.wake()

    memories = chr(10).join(f"- {m['content']}" for m in ctx['memories'][:5])
    system = f"""You are {ctx['identity']['name']}.
{ctx['identity']['description']}
{f'What you remember: {chr(10)}{memories}' if memories else ''}
{system_extra}"""

    return autogen.AssistantAgent(name=name, system_message=system), c

analyst, c_analyst = make_agent("Analyst", "analyst_cathedral_key")
reviewer, c_reviewer = make_agent("Reviewer", "reviewer_cathedral_key")

# Run conversation
groupchat = autogen.GroupChat(agents=[analyst, reviewer], messages=[], max_round=5)
manager = autogen.GroupChatManager(groupchat=groupchat)
analyst.initiate_chat(manager, message="Review the API design from last session")

# Both agents remember what happened
c_analyst.remember("Reviewed API design, agreed on REST over GraphQL", importance=0.9)
c_reviewer.remember("Flagged auth middleware as needing revision", importance=0.8)

Two agents, two separate Cathedral identities, both persistent. Next session they both wake with context.

CrewAI

CrewAI agents lose their learned context between crew runs. Cathedral makes each crew member stateful.

from crewai import Agent, Task, Crew
from cathedral import Cathedral

def cathedral_agent(role, goal, cathedral_key):
    c = Cathedral(api_key=cathedral_key)
    ctx = c.wake()

    memories = chr(10).join(f"- {m['content']}" for m in ctx['memories'][:5])
    backstory = f"""{ctx['identity']['description']}
Previous work: {memories if memories else 'First session.'}"""

    return Agent(role=role, goal=goal, backstory=backstory, verbose=True), c

researcher, c_r = cathedral_agent(
    "Research Analyst",
    "Find gaps in AI agent memory solutions",
    "researcher_key"
)
writer, c_w = cathedral_agent(
    "Technical Writer",
    "Write clear technical comparisons",
    "writer_key"
)

crew = Crew(agents=[researcher, writer], tasks=[...])
result = crew.kickoff()

# Persist what was learned
c_r.remember(f"Research finding: {result[:200]}", importance=0.7)
c_w.remember("Completed agent memory comparison post", importance=0.6)

The pattern

It's the same 3 lines in every framework:

c = Cathedral(api_key="your_key")
ctx = c.wake()                    # restore at session start
c.remember("...", importance=0.8) # store at session end

The framework integration is just about where you inject the context and where you call remember.

What you get that platform memory doesn't give you

Cross-model: your LangChain agent (Claude) and your AutoGen reviewer (GPT-4) share the same memory pool via Shared Spaces
Drift detection: GET /drift tells you when an agent's identity has shifted from its baseline
Programmable: query, write, search memories via REST API -- not a black box
Local option: pip install cathedral-server runs the full API locally against SQLite

pip install cathedral-memory

Docs: cathedral-ai.com/docs