Soluções
Uma memória para os agentes de todo mundo
Rode um servidor em uma máquina do homelab ou em qualquer host da LAN. Cada desenvolvedor aponta seus agentes para ele, e o que uma sessão descobre fica lá para a próxima pessoa que perguntar.
Um servidor para onde todo mundo aponta
Um binário só, com um único arquivo SQLite e uma pasta de markdown. Não tem sidecar, não tem banco vetorial e não tem nada para manter sincronizado.
O que uma sessão aprende, todo agente consegue recuperar
Uma página escrita em um projeto pode ser lida por todo mundo no servidor. A sessão de Codex de uma pessoa encontra o gotcha em que a sessão de Claude Code de um colega de time esbarrou na semana passada.
Visível na próxima consulta
A anotação de um colega aparece na próxima busca ou no próximo briefing de sessão de qualquer pessoa. Uma sessão que já está rodando não é interrompida.
Qualquer combinação de agentes
Cada pessoa continua com o agente de que gosta. Toda chamada de memória resolve o projeto a partir do diretório da sessão, então sessões paralelas não se misturam.
O primeiro dia de quem acabou de chegar
A pessoa recebe uma chave, aponta o agente para o servidor e pergunta ao projeto o que anda acontecendo.
Ela pergunta ao projeto
"Me atualiza" devolve um resumo do trabalho recente. "A gente já discutiu a lógica de retry?" devolve a página da decisão e as sessões por trás dela.
A wiki é uma base de conhecimento viva
Conceitos, decisões e gotchas são escritos enquanto o trabalho acontece, em markdown, com histórico em git. Ninguém precisa lembrar de atualizar.
Ela complementa a documentação que você escreve
As páginas são compiladas a partir das sessões e moldadas para os agentes recuperarem. Mantenha seu README e seus documentos de arquitetura escritos à mão, e deixe a wiki guardar os porquês e os becos sem saída.
O resumo sai em prosa quando o servidor tem um provedor de LLM e em dados estruturados quando não tem. Com --enable-web, dá para navegar pela mesma wiki em uma interface web somente leitura.
O conhecimento é de todos, o bastão tem dono
As páginas pertencem ao projeto. Um handoff pertence a quem o deixou.
- Seu handoff pendente vai para a sua próxima sessão. Um colega que abrir um agente no mesmo repositório nunca o recebe nem o consome.
- Passe
shared: truequando quiser publicar um bastão para quem for assumir o trabalho. - Duas pessoas editando a mesma página geram uma cadeia de versões. A escrita mais recente vira a atual e a anterior continua acessível. Não há merge e nada é destruído.
- Slots opcionais por pessoa guardam "no que estou trabalhando agora" e ficam fora do briefing do time. Vêm desligados por padrão.
# Pessoal por padrão: só a sua próxima sessão recebe
"Salve o contexto para a próxima sessão."
# Publique um de propósito: memory_handoff_begin with shared: true
"Salve um handoff compartilhado para quem pegar isso amanhã receber."
Agentes podem trocar mensagens entre projetos
O agente no repositório do frontend precisa de um endpoint do repositório da API. Ele manda um pedido autocontido para a inbox daquele projeto, e a próxima sessão de lá retira a mensagem. Uma mensagem é assumida uma vez só, o projeto de destino precisa já existir, e uma inbox guarda no máximo 256 mensagens pendentes. O guia de mensagens entre agentes no GitHub tem as ferramentas.
Contas, chaves e auditoria, sem plano pago
Os recursos de time estão no mesmo binário MIT que todo o resto.
Uma conta nomeada por pessoa
Adicione pessoas com um comando. Desative alguém e o acesso dela acaba, mas as páginas ficam.
Chaves de API por máquina
Cada pessoa pode ter várias chaves com rótulo, uma por laptop ou por agente. Rotacionar uma chave rejeita a antiga na hora.
Autoria em toda escrita
Cada página registra seu autor, e a interface web mostra quem editou. A autoria nunca filtra quem pode ler.
Log de auditoria de toda mutação
As escritas são registradas com o id do autor. Webhooks de admissão enxergam o ator e podem rejeitar uma operação.
Ainda não há tela nem comando documentado para navegar pelo log de auditoria, então conte com consultar a tabela audit_log no arquivo SQLite. O guia de usuários no GitHub cobre papéis, login por senha e rotação de chaves.
Um servidor aguenta cerca de 700 escritas por segundo, o que cobre algumas centenas de agentes ativos. Veja como isso foi medido.
Configure o seu time
A página de instalação mostra o passo a passo: subir um servidor, dar uma chave para cada pessoa e apontar os agentes para ele.
Perguntas e respostas
Vários desenvolvedores podem compartilhar um servidor ai-memory?
Sim. Um servidor guarda a wiki e todo mundo aponta seus agentes para ele. As páginas são compartilhadas por todos no servidor. Os handoffs ficam com quem os criou, a menos que a pessoa publique um com shared: true.
O uso em time exige um plano pago?
Não. Contas por pessoa, chaves de API, autoria e o log de auditoria fazem parte do binário open source.
Posso restringir um projeto ou uma página a alguns usuários?
Não. Contas não são uma fronteira de tenancy. Todo usuário autenticado vê todas as páginas de todos os projetos daquele servidor. Rode um servidor por time.
Quantos desenvolvedores um servidor aguenta?
O teto de escrita medido é de cerca de 700 escritas por segundo em um disco local rápido, o que o projeto interpreta como algumas centenas de agentes ativos ao mesmo tempo. O número mede o armazenamento, e discos de rede vão ser mais lentos.
Dê uma memória só para os agentes do seu time.
Gratuito e open source. Contas, chaves e o log de auditoria já vêm incluídos.