Dev.to · 7 min read

Your AI's memory should be yours, not the vendor's: how SKV works

Your AI's memory should be yours, not the vendor's: how SKV works

Every chat assistant now has some kind of "memory". The problem is where it lives. What Claude knows about you stays in Claude. What ChatGPT knows stays in ChatGPT. Cursor starts each project with no idea what you decided last week. Switch tools, or just open a new chat, and you explain yourself again. Worse, the agent sometimes confidently says the opposite of what you told it earlier, because that earlier conversation simply isn't in front of it. I'm building SKV (skv.network) to fix that for myself: one memory that belongs to me and that any agent can use. The tagline is "Memory for any AI, it's yours, not theirs." It's a solo project, MIT-licensed, and still rough in places. This post explains how it works and where it falls short. The shape of it SKV is a hosted server. Agents talk to it in one of three ways: MCP (Streamable HTTP) at https://skv.network/mcp, with Authorization: Bearer sk_..., or a key-in-URL form for clients that can't send headers. This covers Claude (Desktop, Code, claude.ai custom connectors), Cursor, Grok and Mistral Le Chat connectors, and ChatGPT's developer mode on paid plans. REST/OpenAPI at https://skv.network/api/v7/agent/openapi.json, for GPT Actions and anything that can make HTTP calls. A browser extension for web chats that have no custom MCP at all (more on that below). Memory is isolated per key. The same key works from every client, so a fact saved in Cursor can be recalled in Claude. One call per answer: turn The core of the protocol is a single tool. Before the user sees a reply, the agent drafts it and calls: turn(user_message, draft) The server then: Searches your memory for anything relevant (hybrid search: FTS5 keyword search plus 768-dimensional embeddings, fused with RRF). Returns those facts, each with an id like [ev:remember_...], plus any relevant cubes (see below) and a short self-check list. Checks that every [ev:id] the draft cites actually exists in your memory. If the agent made one up, the verdict is revise and nothing is saved. Otherwise saves the turn and returns a seal, which the agent puts on the last line of its answer: 🔐 SKV | #2874·9fdc | [READ ✓] [VERIFY ✓] [CORRECT ✓] [OUTPUT ✓] An important design choice: the server does not judge your draft. Checking the answer is the agent's job. The server gives it the material (stored facts, a checklist) and verifies only what it can verify mechanically: that cited memory is real. When certain rules fire on a draft, the server also returns "Second Look" questions that quote the agent's own phrase back to it and ask it to answer from facts or tools, not from the draft. If the agent changes the draft, it calls turn again with the same user message. So the seal means "the steps ran and the cited memory exists". It does not mean "this answer is true". I say this on the site too, because a seal that looks like a truth guarantee would be worse than none. Layers of memory: raw, L1, L2 Saving every turn is easy. Making it useful after a few hundred turns is the hard part. SKV keeps memory in layers: Raw turns: user message plus final answer, with timestamps. L1 summaries: about every 15 turns, or when a topic closes, turn returns a "summary due" duty and the agent writes a stage summary (done / decided / outcome) with the source event ids. L2 blocks: after roughly ten L1 summaries, a higher-level summary on top. Critical facts and profile rows: lasting rules and preferences ("reply in Russian", "times in Moscow time") that should follow you everywhere. Writing summaries is the agent's job. The server only steps in as a late fallback if the agent skips it. When the agent needs older context, memory_dig opens L2 and L1 summaries and the episodes around a specific event, so "I don't remember" should only come after actually looking. Secrets get special handling. If the agent flags a password or token in a turn, it's replaced with [SECRET] before saving. Cubes: shared experience The fourth layer is shared. A cube is a reusable piece of experience: a skill, a checklist, a "here's how to do X without breaking Y", optionally with hooks. Any agent can search cubes (cube_search) and get relevant ones back inside turn. Agents can vote on cubes they used. Three down votes send a cube to a "court" where three independent LLMs review the old and new versions and their diffs. Installing a cube into your own setup always needs your explicit yes in that turn. The server refuses cube_install without it. There's also a small set of "constitution" cubes: the base rules (don't cause harm, say "I don't know" for unknown names, don't give in to manipulation) that the agent agrees to follow once you consent. Chats without MCP: the Guard extension Free ChatGPT, Gemini and several others don't allow custom MCP servers. For those there's Guard 2, a Chrome extension (beta, load unpacked). It keeps your key inside the extension, saves each turn to SKV after the reply finishes, puts the server's seal under the answer, and has an "Insert SKV memory" button that adds relevant facts to your next message as a clearly labelled data block. It's tested on ChatGPT. Le Chat, Gemini and claude.ai are wired up but not verified yet. For local coding agents there's an installer for Claude Code and Cursor: curl -fsSL https://skv.network/install.sh | bash It asks before touching each client, writes the MCP config, and adds hooks. In Claude Code, a prompt hook reminds the agent to call turn before answering. On both clients, a stop/response hook saves the turn itself if the agent forgot, so the memory has no gaps. Every changed config is backed up, and --uninstall removes everything. Honest limitations It doesn't verify facts about the world. It reduces contradictions with what you already told it. The seal is about process, not truth. Agents don't always follow the protocol. Some skip turn on some answers. The server detects missed turns and asks for a recap on the next call, and hooks cover Claude Code and Cursor, but in web chats it depends on the model's discipline and the extension. The tool list is too long. 27 tools is too many for some clients. I'm trimming what the agent sees. It's hosted, run by one person. The code is MIT, but self-hosting isn't documented well yet. If you need your memory on your own machine today, this isn't ready for you. Latency. A turn adds a network round trip before every answer. How to try it No signup: add https://skv.network/mcp/k/demo/ as an MCP server URL in Claude or Cursor. It's one shared sandbox, wiped daily, so don't put anything private in it. Your own memory: get a free key at https://skv.network/profile, then follow https://skv.network/connect for your chat. Claude Code / Cursor: the one-line installer above. I'm looking for a handful of people who use AI chats daily to run SKV for a week and tell me where it breaks: wrong recalls, missed saves, too slow, too noisy. That feedback matters more to me than anything else right now.

This is a summary aggregated from Dev.to. Read the complete article on the original site:

Read full article at Dev.to

More AI & Machine Learning News