Solutions
One memory for everyone’s agents
Run one memory server on a machine your development team operates. Agents can find earlier decisions in the projects their users can access.
Before a team pilot
Start with a non-sensitive project and an operator who will maintain the server, accounts, updates and backups. Check who can read and write the project before inviting teammates.
The software is free. You provide the machine and its administration; optional cloud model providers charge under your own accounts.
One server that everyone points at
A single binary with a single SQLite file and a folder of markdown. There is no sidecar, no vector database and nothing to keep in sync.
Claude Code
Codex
Cursor
Gemini CLI
One ai-memory server
Project wiki
Share knowledge within a project
Users with access to a project can read its pages. One person’s Codex session can find a problem a teammate’s Claude Code session recorded last week.
Visible at the next query
A teammate’s note can appear in the next search or session brief for users with access to that project. Running sessions are not interrupted.
Any mix of agents
Each person keeps the agent they like. Every memory call resolves its project from the session’s directory, so parallel sessions do not cross.
A new developer’s first day
They get a key, point their agent at the server, and ask the project what has been going on.
Get an API key
Point at the server
Catch me up
Search the wiki
Day one
They ask the project
"Catch me up" returns a digest of recent work. "Have we discussed the retry logic?" returns the decision page and the sessions behind it.
The wiki is a living knowledge base
Sessions add notes automatically, in markdown with git history. Keep reviewed documentation for authoritative instructions, and check important decisions against their sources.
It complements your written docs
Pages are compiled from sessions and shaped for agents to retrieve. Keep your hand-written README and architecture docs, and let the wiki hold the why and the dead ends.
The digest is prose with an LLM provider and structured data without one. With --enable-web, people can inspect the wiki in a browser; root can also review pending edit proposals.
Shared knowledge, personal handoffs
A handoff is a saved summary of unfinished work. Project pages are shared with users who have access; a handoff belongs to the person who left it.
Knowledge is shared
Batons are owned
- Your pending handoff goes to your next session. A teammate starting an agent in the same repository never receives or consumes it.
- Pass
shared: truewhen you want to publish a baton for whoever picks the work up. - Two people editing the same page produce a version chain. The later write becomes latest and the earlier one stays reachable. There is no merge and nothing is destroyed.
- Optional per-person slots hold "what I am working on now" and stay out of the team brief. They are off by default.
# Personal by default: only your next session receives it
"Save context for the next session."
# Publish one on purpose: memory_handoff_begin with shared: true
"Save a shared handoff so whoever picks this up tomorrow gets it."
Agents can message each other across projects
The agent in the frontend repository needs an endpoint from the API repository. It sends a self-contained request to that project’s inbox, and the next session there pops it. A message is claimed once, the recipient project must already exist, and an inbox holds at most 256 pending messages. How messaging works.
Accounts, keys and audit, with no paid tier
The team features are in the same MIT binary as everything else.
A named account per person
Add people with one command. Disabling an account ends browser access and keeps its pages. Self-issued API keys must be revoked separately.
API keys per machine
Each person can hold several labelled keys, one per laptop or agent. Rotating a key rejects the old one immediately.
Attribution on every write
Each page records its author, and the web UI shows who edited it. Authorship never filters who can read.
An audit log of every mutation
Writes are recorded with the author’s id. Admission webhooks can see the actor and reject an operation.
No screen or command for browsing the audit log is documented yet, so plan on querying the audit_log table in the SQLite file. The users guide on GitHub covers roles, password login and key rotation.
One server takes about 700 writes per second, which covers several hundred active agents. See how that was measured.
Set up your team
The install page walks through it: start one server, give each person a key, and point their agents at it.
Questions and answers
Can several developers share one ai-memory server?
Yes. One server holds the wiki and agents connect to it. Projects are open by default; database-user accounts can be limited with project grants. Handoffs stay with their author unless explicitly shared.
Does team use need a paid tier?
No. Per-person accounts, API keys, attribution and the audit log are part of the open source binary.
Can I restrict a project or a page to some users?
You can restrict a whole project for database-user accounts. Root, its creator and users with a grant retain access; write grants include read access. Individual pages within a project have no separate permissions. Trusted-proxy deployments must enforce access at the proxy.
How many developers can one server handle?
The measured write ceiling is about 700 writes per second on a fast local disk, which the project reads as several hundred concurrently active agents. The number measures the store, and network disks will be slower.
Give your team’s agents one memory.
Free and open source. Accounts, keys and the audit log are included.