Memory for AI agents, answered.

Willder is one memory for every AI agent you run, with access control built in. Agents connect over MCP. Each holds its own scoped, expiring token, every memory read and write an agent makes goes through one database check that is recorded in an audit log, and a revoked token is refused on its next call.

It runs hosted at willder.ai, or on your own machine from the MIT-licensed engine.

An MCP server is a service an AI agent connects to through the Model Context Protocol, the open protocol agents such as Claude Code and Codex CLI use to call tools. A memory server's tools let the agent save what it learns and read it back later, in another session or from another agent.

Willder's endpoint is https://willder.ai/api/mcp, over Streamable HTTP with a bearer token. Its core tools are memory_query to read, memory_ingest to write, memory_changes for what others changed, and memory_version to open one version of a fact.

Several agents, often run by different people, reading and writing one store, so that a decision one agent records reaches the others without anyone repeating it.

Sharing raises questions one agent's private memory does not: which agent may read which part, what happens when two agents change the same fact, how each learns what changed, and who read what. Willder answers them with scopes and per-agent tokens, versions with stale-write refusal, change notices and an audit log.

What an agent writes is stored in its scope and readable at once, by itself and by other agents with access. When a new session starts, the agent's first tool result carries a brief from its scope: the rules in force, what earlier sessions of its task decided, recent writes and facts flagged stale.

In Claude Code, a hook brings that brief in on the first message of each session, and again after the conversation is compacted or cleared, so the agent does not have to remember to ask.

It does not make the window larger, and no token saving is claimed yet: the measure for that has not run on a deployed build.

What it does is keep what it serves small. The task-start brief has an estimated budget of about 600 tokens, long facts arrive as excerpts an agent can open in full by id, and a coding connection lists four tools instead of every one, since a client sends each listed tool's description to its model on every turn.

A shared folder has no idea which agent is reading, so any agent that can open it reads all of it, and two agents editing one file overwrite each other without a word.

Willder gives each agent its own token on one part of your memory, checks every read and write, keeps earlier versions of a fact readable, and refuses a write made from an outdated read.

A vector index finds text that looks similar to the question. It does not decide who may read a result, which version of a fact is current, or who wrote it.

Willder uses vector search too (pgvector), beside a knowledge graph. Every result passes the same access check, each answer names its writer and date, and a fact that was replaced stops being served.

A knowledge graph helps with questions that follow connections between people, systems and decisions, and Willder keeps one (Graphiti on Neo4j) beside vector search.

What a graph alone does not give a team of agents is the rest: a token per agent limited to one scope, writes from outdated reads refused, conflicting writes detected and reported, and a record of every access decision.

You could build this on Postgres; Willder does. What it adds is the layer you would otherwise write and maintain yourself.

That layer is a scope tree with per-agent tokens that expire, one check every memory read and write goes through, an append-only audit log, stale-write refusal, a change feed, and an MCP server your agents connect to without custom code.

Mem0 describes itself as the memory layer for AI agents: long-term memory that persists across sessions, tools and runs, hosted or open source. Zep describes itself as a unified context layer for enterprise data, organized in temporal context graphs and built on Graphiti, its open source temporal knowledge graph framework. Both descriptions are from their own sites, checked 29 Oct 2026.

Willder starts from a different question: what happens when several agents, run by several people, share one memory. Its work is deciding what each agent may read and write, keeping versions when agents disagree, telling each agent what changed, and recording every access decision.

Scopes form a tree, like folders: a grant on a parent covers its children, and a token on one project never reaches a sibling or a parent. Each agent holds its own token with one scope, one permission (read, write or admin) and an expiry of seven days by default, ninety at most.

Every memory read and write made through Willder goes through one check, a database query over grants, token scope, expiry and revocation. No model takes part, so nothing written in a prompt can widen access. Revoke a token and its next call is refused, and every decision, allow or deny, is written to the audit log.

The leak tests ship with the open source code. npm run test:leaks runs them in seconds with no keys and no network, and asserts that a token on one scope never receives a sibling scope's facts, graph nodes, files or briefs, and that a revoked or expired token is refused on every memory tool.

The Security page lists what passed on deployed builds, with the build and the date, and the limits not solved yet, including the credentials that reach memory without the check.

No. Willder does not use your content to train AI models, and its contracts with model providers prohibit them from training on it.

In Access, then Tokens, choose revoke on the agent's token and confirm. Its next request to the hosted MCP endpoint is refused with HTTP 401, without waiting for the token to expire. On a self-hosted install, npm run selfhost:token -- --revoke <agent> revokes every live token of that agent, or with --scope only its token on that scope.

Revoking ends future access only. It cannot recall what the agent already read. In the app, revoking one token does not close the agent's other tokens or a person's grants, and a replacement token does not disable the old one, so review both.

Yes. Every access decision, allow or deny, writes one append-only row: the actor, the action, the target scope, the decision and the reason. Reads, writes, listings, change notices and token and scope management are recorded this way. The rows are under Audit in the app and at GET /api/audit, and the app itself cannot edit or delete them.

Two limits: a request with a missing or never-issued token can be turned away before the check without a row, and a row records a decision, not whether an answer was correct.

Give each team or project its own scope and each agent its own token on that scope. Scopes form a tree: a token on one project never reaches a sibling project or the scope above it, and the leak tests check this for facts, graph nodes, files and briefs.

An agent that read one scope and then writes into another is refused unless it declares the share; a declared share is recorded, and readers of the scope it came from are told. Connecting a source more widely than it was shared needs a confirmation, which is recorded too.

No. Access is decided by a database query over grants and the token's scope, expiry and revocation, and no model takes part. The workspace and agent come from the bearer token alone, so naming another organization in a prompt or request body does not switch workspaces.

This limits what an agent can reach, not what it does with what it may read: text inside its own scope can still mislead it.

Each token carries one scope, one permission and an expiry. Read retrieves facts, changes and briefs; write also records notes, conventions and decisions; admin is a broader tier that routine agents do not need.

Tokens last seven days by default and ninety at most on the hosted service, and an agent token with admin permission expires within two hours and cannot extend itself. A token is shown once when issued, and only its hash is stored.

Yes, and the open source README lists each one. The check runs inside the application, not in the database, which has no row-level security, so whoever holds the database, graph, memory-service or background-job credentials reaches memory without it.

Capability tokens and signed-in people always go through the check. On your own install, keep those infrastructure credentials as tightly held as the memory itself.

Every fact keeps its versions, like commits. A write made from an outdated read is refused with stale_version, naming the current version, and nothing is stored: the agent reads what changed and writes again.

If two agents write the same fact at the same moment, the version stored first stays current, the other is kept as superseded, and its writer is told on its next call. Willder detects and reports the conflict; it does not merge the two.

When a session starts, the agent is served a task-start brief from its scope, unasked: what is settled for its task, the rules in force, the questions still open, and on a return, how many changes others made since its last session.

After that, each tool reply carries notices of what changed in its scope. The brief goes through the same access check as any read, so it holds only what that agent may see.

Anything that speaks MCP and can send a bearer token. Run end to end against Willder so far: Claude Code, Codex CLI, Goose, LangChain / LangGraph, OpenAI Agents SDK and Vercel AI SDK.

Cursor's CLI agent has also been tested against a local self-hosted install: it saved a fact, read it back in scope, found nothing with a token on another scope, and could not connect after its token was revoked.

Gemini CLI, Hermes (Nous), Claude Desktop, Windsurf, Continue, VS Code (Copilot), Open WebUI, Zed, Cline, LM Studio and OpenClaw have committed configs the server answers, but have not been run yet. claude.ai and ChatGPT sign in with OAuth, which is not on yet.

No code changes. You add the Willder MCP server and the agent's token to its config; Claude Code connects with one command, and a session hook you add once brings what changed into each new session. From a copy of the repository, willder init does both.

Agents do not have to track versions: the server records what each agent read and refuses a write made from an outdated read either way.

Through a working note. memory_note posts one line, a claim, an intent, a status or a question, that other agents in the scope see on their next tool call. A note lasts 30 minutes by default and four hours at most, and the task-start brief lists the live ones.

A claim on a task another agent has already claimed is stored, and the reply names that agent and its line. Willder reports the overlap; it does not decide between them.

Yes. Name the task with a ticket key or branch name, in the X-Willder-Task header or in a call's _meta. A later session that names the same task, by any agent, is served first what earlier sessions of that task decided and wrote, within what that agent may read.

On a deployed build, a task handed off mid run arrived with its last note and claim (build 2ca31c57, 20 Oct 2026).

Tell any connected agent the rule. Willder's server instructions ask it to record a lasting rule or decision with memory_ingest, and the reply carries a link for you to confirm it. A confirmed decision is a standing rule: every new session in that scope is served it until a newer decision replaces it.

Until a person confirms it, a decision an agent recorded is served as a proposal to check, and an agent cannot replace a rule a person recorded or confirmed.

Issue a token, connect Claude Code with one claude mcp add command, and add Willder's session hook. The hook brings your scope's rules and decisions into each new session before Claude reads your first message, and what others changed after each tool call. There is no repository to clone.

Claude Code has been run end to end against Willder. The quickstart saves a decision in one session and shows the next session starting with it.

Yes: give each its own token on the same scope. A decision one records is readable by the other on its next call, and either token can be revoked without touching the other.

Claude Code has been run end to end. Cursor's hosted configuration is committed and the server answers it, but no one has run Cursor itself against it yet; Cursor's CLI agent has been tested against a local self-hosted install.

Yes, through each framework's MCP support: LangChain and LangGraph through langchain-mcp-adapters, and the OpenAI Agents SDK and the Vercel AI SDK through their own MCP clients. All three have been run end to end against Willder, and each has a page with its configuration.

Yes. Deleting a fact in the app removes it from search and from the knowledge graph, and it no longer appears in any agent's task-start brief; each of those paths has a test. Erasing a person stops every live store returning them, with a record of the erasure.

Not covered yet: copies in backups, uploaded source files, and answers already delivered to an agent. MCP has no delete tool, so deleting goes through the app.

Hosted, it lives in Postgres with pgvector (Neon), a Neo4j graph and private file storage on Vercel Blob. Willder is based in the United States; the privacy policy says where data may be processed.

Or host it yourself, on your own machine with Docker; the next question says how. The code is public on GitHub.

Yes. The engine is MIT-licensed: Postgres with pgvector, Neo4j, the memory service and the MCP server. It runs on your own machine with Docker, needs no willder.ai account and makes no call to willder.ai.

Five commands install it, and npm run selfhost:smoke then checks a scoped write, a scoped read, an out-of-scope refusal and an export. npm run selfhost:token issues and revokes agent tokens; the web app is optional.

Yes, as one JSON Lines file in a documented format: scopes, sources, facts, rules, working notes and briefs, plus the audit log for an admin. Download it from GET /api/memory/export, or run npm run selfhost:export on a self-hosted install, and import it into an empty workspace, another deployment or the open source engine.

An export holds only what the person exporting may read, and agent tokens cannot export.

Only for writes. Reads never call a model: embeddings run locally in the memory service. A write calls an OpenAI-compatible model endpoint to extract facts into the knowledge graph, and a local model server works.

Self-hosted with no model endpoint at all, a write is still stored and readable; only its graph extraction is skipped.

An admin of the workspace root erases a person by contact, email address or graph entity with POST /api/access/erasure. The erasure covers every store Willder searches, and the audit log records it by request id and counts, not by the erased values. On a deployed build, every live store stopped returning the erased person (build 2ca31c57, 20 Oct 2026).

Not covered yet: erasure that survives a backup restore, and answers already delivered to an agent. For personal data in your workspace, Willder processes it on your organization's instructions, under the data processing agreement.

The deletion takes effect seven days after the request. At the request, agent tokens are revoked, new writes are refused, and a final export is made for the person who asked to download. An owner or admin can cancel until the seven days end, unless the deletion was started at the sign-in provider.

Then the organization's data is deleted from every store of the service, the audit log included, and backup copies age out within 30 days. Job payloads and model traces held by subprocessors age out under their own retention settings.

Free to start. The planned paid plans are under Pricing on the home page and are not for sale yet. Hosting it yourself is free under the MIT license.

Not during the beta. The beta terms state that there is no service-level agreement and no uptime guarantee.