I Gave My AI the Ability to Edit Its Own Memory

There's a moment in every audit when you realize a system has a gap so obvious you can't believe nobody fixed it sooner. That moment happened to me while working with my Open Brain memory server — a Supabase-backed, AI-connected personal memory system I built following Nate's newsletter guides.

The system was working well. Every time I had a conversation with Claude, important context got saved — tasks, project notes, decisions, ideas. Claude could search and retrieve them later. It was, for the first time, an AI that actually remembered me between sessions.

But there was a problem. A fundamental one.

"The system could only add. It had no ability to update what was wrong or remove what was outdated."

In audit terms: write-only access with no remediation path. If a task was completed, it lived in the database forever as still open. If a note was wrong, it stayed wrong. The AI was working from a memory that could only accumulate — never correct itself.

So I fixed it. Here's how.

What Open Brain Is (Quick Background)

Open Brain is a personal memory layer for AI tools. It runs as an MCP (Model Context Protocol) server — which means Claude can call it as a tool, just like searching the web or reading a file. Every thought you save gets stored in a Supabase database with a vector embedding, enabling semantic search across everything you've ever told it.

Out of the box, Open Brain ships with four tools:

Notice what's missing? There's no update_thought. No delete_thought. The database has rows. Claude can read them. Claude can add to them. But Claude cannot touch what's already there.

For a personal memory system meant to track your life's ongoing projects, this is a serious gap.

The Audit Finding: Write-Only Memory Is a Control Weakness

Let me frame this the way I think about it professionally. In any data system, you need four basic operations: Create, Read, Update, Delete — CRUD. A system missing Update and Delete isn't a memory system. It's an append log.

Append logs have their place. But a personal AI memory layer isn't one of them. Your tasks get completed. Your opinions change. Your projects evolve. A memory system that can't reflect those changes will gradually drift from reality — feeding your AI increasingly stale context that it treats as current truth.

That's not a minor inconvenience. It's a reliability problem.

Building the Fix: Two New Tools

The Open Brain server runs on Deno, and the main file is index.ts. Each tool is registered using a server.registerTool() pattern with a Zod schema for input validation. Once I understood the pattern from the existing tools, adding new ones was straightforward — though there were a couple of gotchas worth knowing.

Tool 1: update_thought

This tool takes a thought ID and new content, then updates the database record — including regenerating the vector embedding so search still works correctly on the updated text.

server.registerTool("update_thought", {
  description: "Update an existing thought by ID",
  inputSchema: z.object({
    id: z.string().describe("The UUID of the thought to update"),
    content: z.string().describe("The new content to replace the existing thought")
  })
}, async ({ id, content }) => {
  // Generate new embedding for updated content
  const embedding = await generateEmbedding(content);

  const { error } = await supabase
    .from("thoughts")
    .update({ content, embedding })
    .eq("id", id);

  if (error) throw new Error(error.message);
  return { success: true, id };
});

Tool 2: delete_thought

Simpler — takes an ID, removes the row. Permanent, so Claude is instructed to confirm with the user before calling it.

server.registerTool("delete_thought", {
  description: "Permanently delete a thought by ID. Confirm with user first.",
  inputSchema: z.object({
    id: z.string().describe("The UUID of the thought to delete")
  })
}, async ({ id }) => {
  const { error } = await supabase
    .from("thoughts")
    .delete()
    .eq("id", id);

  if (error) throw new Error(error.message);
  return { success: true, deleted: id };
});

The Critical Gotcha: --no-verify-jwt

The Result: Full CRUD Memory

After deploying, my Open Brain went from four tools to six:

Claude can now do what any good system should be able to do: not just remember, but remember accurately. When a task is complete, I tell Claude and it finds the entry and marks it done or removes it. When a project changes direction, the memory reflects the new direction — not the old one.

Why This Matters Beyond the Technical Fix

There's a broader principle here that applies well beyond Open Brain. AI tools are increasingly being given persistent context — memory, history, notes. But most of that infrastructure is designed with a single direction in mind: accumulation. Add more. Save more. Remember more.

That's only half the picture. Any auditor will tell you that a system without a correction mechanism is a liability, not an asset. Stale data that looks authoritative is worse than no data at all — because your AI will act on it confidently.

Giving your AI the ability to edit its own memory isn't just a convenience feature. It's a data integrity control.

If you're running your own Open Brain instance and want to add these tools, I'm happy to share the full extended index.ts. Find me on LinkedIn or reach out through the Connect section below.