Solutions
One memory for everyone’s agents
Run one server on a homelab box or any LAN host. Every developer points their agents at it, and what one session figures out is there for the next person who asks.
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.
What one session learns, every agent can retrieve
A page written in a project is readable by everyone on the server. One person’s Codex session finds the gotcha a teammate’s Claude Code session hit last week.
Visible at the next query
A teammate’s note shows up in anyone’s next search or next session brief. A session that is already running is 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.
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
Concepts, decisions and gotchas are written as the work happens, in markdown, with git history. Nobody has to remember to update it.
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 when the server has an LLM provider and structured data when it has none. With --enable-web, the same wiki is browsable in a read-only web UI.
Knowledge is shared, batons are owned
Pages belong to the project. A handoff belongs to the person who left it.
- 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. The agent messaging guide on GitHub has the tools.
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. Disable someone and their access stops, while their pages stay.
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 everyone points their agents at it. Pages are shared by everyone on the server. Handoffs stay with the person who created them unless they publish one with shared: true.
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?
No. Accounts are not a tenancy boundary. Every authenticated user sees every page in every project on that server. Run one server per team.
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.