AgentKits Memory Bets on One Local SQLite File While the Agent-Memory Market Bets on the Cloud

The Problem Nobody Disputes

Every AI coding assistant has the same blind spot: it forgets everything the moment the session ends. Tell it today that the project uses JWT with refresh tokens, and tomorrow it will happily suggest session cookies instead — not because it’s wrong about auth, but because it never knew. Multiply that by every decision, every bug fix, every “we tried that and it didn’t work” across a project’s lifetime, and the tax adds up.

By 2026 this has stopped being a niche complaint and become its own category. A survey of the space counts 21 memory frameworks and 20 vector stores now competing to solve it, split across three distinct hosting models: managed cloud, open-source self-hosted, and local MCP. Mem0 extracts facts from conversations behind a hosted API. Zep attaches expiry dates to facts so old context ages out. Letta treats memory like an operating system, with the agent itself deciding what moves between core context, recall, and archival storage. Cognee builds a self-hosted knowledge graph. LangMem plugs into LangGraph pipelines. It’s a genuinely crowded field, and most of the well-known names default to a server somewhere.

AgentKits Memory, the memory layer we maintain alongside the AgentKits marketing and engineering kits, made a narrower bet: everything lives in one local SQLite file, and nothing leaves the machine.

What “Everything Local” Actually Means Here

It’s a specific set of engineering choices, not a slogan. The database is a single better-sqlite3 file at .claude/memory/memory.db — one artifact that holds memories, sessions, observations, and embeddings together, so a backup is a file copy and there’s no fleet of markdown files to keep in sync or merge-conflict over. Semantic search runs through sqlite-vec, an embedded vector extension for SQLite, paired with a local ONNX embedding model (multilingual-e5-small) that covers more than 100 languages without a single API call to an embeddings provider. Setup is one npx command that also downloads that model to disk. There’s no account, no API key, and — per the project’s own design notes — no cloud dependency to be a dependency on in the first place.

This puts AgentKits Memory in the same “local MCP” lane the market survey identified, alongside newer entrants like MemPalace (MIT-licensed, verbatim local storage, no API calls) and Basic Memory (an AGPL local MCP server that stores plain Markdown). It’s worth being precise about the competitive picture rather than overselling it: Mem0 itself now ships OpenMemory, a local-first MCP-compatible memory server that works with Claude Desktop, Cursor, Windsurf, and VS Code — so “runs locally over MCP” is a lane other serious players are also building in, not a gap AgentKits Memory has to itself. What differs is the specific combination underneath: single-file storage, an embedded vector index, and a fully offline embedding model, rather than a local server that still assumes a broader hosted product around it.

Why the Retrieval Design Matters More Than the Storage Choice

Local-only storage solves a privacy problem, but it doesn’t automatically solve a token-budget problem. A naive memory tool can still be local and still burn a five-figure token count by dumping every stored file into context on every query.

AgentKits Memory’s answer is a three-layer, progressive-disclosure search: memory_search first returns a lightweight index — IDs, titles, tags, and a match score at roughly 50 tokens per result — so the agent can see what exists before committing context budget to any of it. memory_timeline is an optional second step that pulls the ±30-minute window of session activity around a promising result, useful when a decision only makes sense next to what triggered it. Only memory_details fetches the full content, and only for the IDs the agent actually selected. The project’s own accounting puts this at roughly a 70% token reduction versus fetching everything up front — 1,500 tokens for a ten-result search instead of 5,000. Whether that ratio holds for every workload is workload-dependent, but the shape of the design — index first, fetch narrowly, pay for exactly what you use — is the right instinct for a tool meant to run inside every session rather than alongside it.

Capture is designed to require nothing from the developer: hooks record decisions, tool usage, and session summaries automatically as work happens, rather than depending on someone remembering to call memory_save. Background workers handle AI enrichment, embedding generation, and old-session compression asynchronously, and are deliberately built not to linger — they self-terminate after five minutes, use PID-based lock files with stale-lock cleanup, and shut down cleanly on SIGTERM/SIGINT. For a process that’s meant to run quietly in the background of every coding session, “doesn’t leave zombie processes behind” is a mundane but load-bearing requirement.

The Actual Case for Local, Not Just the Comfortable One

It would be easy to wave at “privacy” and move on, but the pressure behind local-first tooling in 2026 is more concrete than that. In large enterprises specifically, a widely cited share of developers — 61% at companies over 1,000 employees, per recent survey data — say they’re concerned about exposure of sensitive company or customer data through AI tools, and separate analysis found a meaningful fraction of organizations adopted their primary AI coding tool without reviewing its data-handling terms first, only to discover a violation of internal policy later. None of that is hypothetical: engineers pasting proprietary source into a cloud chat interface is exactly the kind of leak that got generative AI tools banned outright at more than one large company in recent memory. A memory layer that watches every file you touch and every decision you make is, if it’s cloud-hosted, precisely the kind of surface that turns an isolated mistake into a standing policy problem — every session’s context is now also every session’s export.

That’s the trade AgentKits Memory is making a bet on: a coding agent’s memory is disproportionately sensitive data — architecture decisions, credentials mentioned in passing, customer-specific context — and the safest way to handle disproportionately sensitive data is to not centralize it anywhere in the first place. The local-first movement isn’t limited to AI tooling either; it’s broad enough in 2026 that FOSDEM has run a dedicated developer room on local-first software and CRDTs, and products like Linear and Figma have already shown the pattern scales to real usage outside of niche tools. AgentKits Memory is a narrower, more specific application of the same principle to one specific problem: an AI assistant that needs to remember your project without needing to know your project on someone else’s server.

What This Doesn’t Claim

Local-first isn’t automatically better for every team — a distributed team that wants shared memory across engineers, not just across sessions on one machine, is a real use case that a single local SQLite file doesn’t serve, and that’s a legitimate reason to pick a hosted option instead. AgentKits Memory is honest about being one option in a fast-moving field rather than the definitive one; the market survey’s framing of three real hosting models, not one right answer, is the accurate way to read this space. What the design does establish is that “local” doesn’t have to mean “unsophisticated” — the progressive-disclosure search and structured observation capture are doing real engineering work, not just avoiding a server.

For teams whose main objection to AI memory tools is “where does our code actually go,” that’s the specific question AgentKits Memory is built to answer plainly: nowhere but the SQLite file already sitting in the project’s own .claude/ directory.