Willder

Willder

Apps, Agents, Teams Synced.

Willder is a context layer that syncs your apps, agents and teams, with access control on every call and real-time coordination: what one agent writes, the others read on their next call. Each agent holds its own scoped, expiring token; its memory reads and writes pass one check and land in the audit log; revoke a token and its next call is refused. Connect your Claude Code or Cursor agent over MCP in five minutes.

Website · Docs · Architecture · Connect a client · Discussions

What it does

1. The right context, unasked. At the start of a task an agent gets a short brief of what matters for it: the scope's rules, decisions and recent writes, ranked by the task's words. Queries search by words, by meaning and by links in the graph. Task-start briefs, hybrid retrieval.
2. One memory across every agent. What Claude Code saves, Codex reads on its next call, with who wrote it. Change a fact once and every agent reads the new version. Versions and conflicts.
3. Connectors into scopes. GitHub, Google Drive, Slack, Figma and PostHog sync into a scope you choose, under that scope's rules. services/connectors/.
4. Access control. Each agent holds its own scoped, expiring token. Its memory reads and writes pass one check and land in the audit log; a revoked token is refused on its next call. What the check does not cover is listed under Limits. The single check.
5. Set up in minutes. One command connects Claude Code; Codex, Cursor and other clients have a page each. Connect a client.
6. Memory you can see. Every fact keeps who wrote it, where it came from, what it replaced and which agents first read it. Audit and provenance.

How it works

flowchart LR

accTitle: The parts of Willder and how a request moves through them. accDescr: An MCP client with a capability token and a person in the web app both reach the memory operations. check() decides each guarded operation against Postgres and writes an audit row. Allowed operations read and write the Postgres stores, including pgvector, and the graph through the memory service, which owns Neo4j and the embedding model. mcp["MCP client: agent token"] --> ops["Memory operations"] web["Web app: signed-in person"] --> ops ops --> chk{"check()"} chk --> pg[("Postgres: scopes, grants, tokens, audit_log, versions, pgvector chunks")] chk -- allow --> pg chk -- allow --> ms["Memory service: FastAPI, BGE-384 embeddings"] ms --> neo[("Neo4j via Graphiti: facts and relations")]

Deep dives: architecture, hybrid retrieval, conflict resolution, database, API, export format, self-hosting.

Why

You run several agents on real work: a coding agent in the repo, a research agent on a schedule, a side project's agent. Nothing decides what each may see, tells the others when one changes something, or records what was read. Willder is the memory they share and the fence between them: scopes, per-agent tokens, a change feed and an audit, with no model in any access decision.

Run it on your machine

This repository is the engine: Postgres with pgvector, Neo4j, the memory service and the MCP server. It runs on your own machine with no willder.ai account and no call to willder.ai. You need Docker with Compose v2, Node 20.19+, 22.12+ or 24+, and a few GB of disk. Without Docker, docs/self-host.md says what to run instead.

git clone https://github.com/willderai/willder-core.git && cd willder-core

npm install cp .env.selfhost.example .env # then set GRAPHITI_SERVICE_API_KEY to any string docker compose up -d --wait # Postgres, Neo4j, the memory service; the first build takes minutes npx prisma migrate deploy # create the tables npm run selfhost:smoke # write, scoped read, refusal, export, no outside calls

The smoke ends with 9 of 9 steps passed. docs/self-host.md describes each line it prints and what to do when one fails.

Mint a token for your agent. One per agent, scoped and expiring:

npm run selfhost:token -- --scope team --agent claude-code

It prints a wcap_... token once. Put it in an environment variable and nowhere else:

printf 'Willder token: '

stty -echo; read -r WILLDER_TOKEN; stty echo printf '\n' export WILLDER_TOKEN

Connect Claude Code to the local stdio MCP server, from this directory:

claude mcp add -s user willder-local -e WILLDER_CAPABILITY_TOKEN="$WILLDER_TOKEN" \

-- npm --prefix "$PWD" run --silent mcp

Then tell the agent: Save this to Willder: we store sessions in Postgres, not Redis, so they survive a restart. Then ask Willder where we store sessions and why. It calls memory_ingest with two required arguments, content (the fact) and name (what the fact is about), and gets back the id a later update passes as baseVersion:

Stored and readable now; graph extraction continues in the background. Version: <version id>.

Then it calls memory_query, which returns one bullet per fact with when and who wrote it (an agent that has only a token is named by it, quoted), notes on what its grant let it read, and the answer's revision:

• we store sessions in Postgres, not Redis, so they survive a restart. (as of <when it was stored>) — from: "claude-code" (agent token) (agent) · version <version id>

revision: <16 hex characters>

A token for another scope (npm run selfhost:token -- --scope research --agent second-agent) gets No facts found. for the same question. Other clients: docs/connect/; the stdio server and its tools: mcp/README.md.

The engine calls out to one thing at most, and only if you configure it: an OpenAI-compatible model endpoint that extracts facts on writes (a local server works; without one a write is still stored and readable, and only graph extraction is skipped). The web app is optional: it needs a free Clerk development instance to sign people in, and docs/self-host.md lists the other outside calls it makes. An export is one JSON Lines file in a documented format: docs/export-format.md.

Prefer not to run it? The hosted service at willder.ai runs the same engine: docs/quickstart.md.

Prove it does not leak

Two checks, about ten minutes, and neither needs an account. The second revokes the claude-code token from Run it on your machine (any token you are willing to revoke works).

1. Run the leak suite. From a fresh clone, with Node 20.19, 22.12 or 24:

git clone https://github.com/willderai/willder-core.git && cd willder-core

npm ci npm run test:leaks

Installing takes about a minute; the suite runs in seconds with no keys and no network. It is every test file named *eval.test.ts, *leak.test.ts or *leakage.test.ts: check(), the guarded memory reads and the MCP tool bodies run for real, and only the database and memory backends are stubbed. A pass ends with no failed file. One file, app/api/briefs/staleness-scope-leak.test.ts, reports as skipped unless QA_DATABASE_URL names a test Postgres (docs/development.md). The suite asserts that:

• a token scoped to one team never receives a sibling scope's facts, graph nodes, uploaded files or briefs, and the in-scope token still does, so an over-broad filter fails too;
• a revoked or expired token is refused on every memory tool over the real MCP endpoint;
• a call without a real caller identity is denied, never audited under a stand-in actor;
• the account tier can narrow a read and never widen one;
• the same holds with thousands of facts and concurrent callers, and a backend failure is reported as a failure, not as an empty answer.

A few cases are named GAP:. They pass by pinning a known defect, and each one says what the correct behaviour is. The suite proves the code; step 2 proves the running service.

2. Revoke a token and see its next call refused. Revoke the agent's token from the terminal:

npm run selfhost:token -- --revoke claude-code

It prints each token it revoked by id, scope, permission and expiry, never the token, and nothing waits for the token to expire. What the agent sees next depends on how it connects:

• A stdio MCP server already running, like the claude mcp add connection above: it keeps listing its tools, but every memory call after the revoke is refused and nothing is read or written. Memory tools answer Access denied: no valid capability for agent claude-code granting read (or write) on the target scope …, and each refusal is a deny row in the audit log under the call's own action (memory.read, memory.write or memory.entity).
• A stdio MCP server started with the revoked token exits before connecting, with WILLDER_CAPABILITY_TOKEN is not a live token in this database (unknown, expired or revoked), and records a capability.refused row.
• Over HTTP, the web app's /api/mcp or https://willder.ai/api/mcp on the hosted service, the next call gets HTTP 401 with Invalid or unknown capability token. and a capability.refused deny row for that agent.

npm run selfhost:export holds every one of those refusals as audit lines.

Measured on the hosted service

Measured with dates: the first three rows on the hosted service at willder.ai, the setup row in a clean container. The harness that produced them is not in this repository. Implementation is not proof, and nothing here is a guaranteed latency.

| Connected sources: co