[Shubham Saboo](https://x.com/Saboo_Shubham_) (un PM de Google) [un agent de memòria sempre activat de codi obert](https://github.com/GoogleCloudPlatform/generative-ai/tree/main/gemini/agents/always-on-memory-agent) com a part generativa de GCP la setmana passada. [VentureBeat ho va cobrir](https://venturebeat.com/orchestration/google-pm-open-sources-always-on-memory-agent-ditching-vector-databases-for) com a senyal sobre cap a on es dirigeix ​​la infraestructura de l'agent. És un sistema de memòria persistent que s'executa les 24 hores del dia com a procés en segon pla, ingereix fitxers, es consolida en un temporitzador i respon les consultes. No hi ha base de dades vectorials. Sense incrustacions. Només un LLM que llegeix, pensa i escriu memòria estructurada a SQLite.

El projecte valida una cosa que he estat construint amb [Neotoma](https://github.com/markmhendrickson/neotoma): la memòria persistent per als agents és una necessitat real i creixent. Però els dos projectes prenen decisions arquitectòniques oposades. Aquesta publicació els compara.

## Què és l'agent de memòria sempre activat

El projecte és una implementació de referència construïda amb [Google ADK (Agent Development Kit)](https://google.github.io/adk-docs/) i [Gemini 3.1 Flash-Lite](https://ai.google.dev/gemini-api/docs/models). S'executa com un procés de fons lleuger amb tres subagents especialitzats: un per a la ingestió, un per a la consolidació i un altre per a la consulta.

1. **Ingestió.** Un observador de fitxers supervisa un directori de safata d'entrada. Introduïu un fitxer i l'agent el recull. També accepta entrada mitjançant HTTP POST. Gestiona text, imatges, àudio, vídeo i PDF. El LLM extreu resums, entitats, temes i puntuacions d'importància.

2. **Consolidació.** En un temporitzador, l'agent de consolidació llegeix totes les memòries emmagatzemades, troba connexions i patrons entre elles, comprimeix elements relacionats i escriu noves idees sintetitzades. Això s'executa en segon pla sense demanar-ho.

3. **Consulta.** Feu una pregunta. L'agent de consulta llegeix memòries rellevants i coneixements consolidats, sintetitza una resposta i la torna amb citacions a registres de memòria específics.

L'emmagatzematge és SQLite. Sense base de dades vectorials, sense índex d'inserció. L'arquitectura aposta perquè un LLM pot gestionar la recuperació directament sobre registres de text estructurat sense necessitat de cercar per similitud.

## On sobresurt

**Simplicitat.** Clona el repo, configura una clau de l'API Gemini i executa-la. Vigilador de fitxers, API HTTP i un tauler de control Streamlit. Dependències mínimes i sense infraestructura per gestionar més enllà del procés únic. Per als desenvolupadors que exploren la memòria de l'agent amb Gemini, és el camí més ràpid cap a una demostració de treball.

**La narrativa "no vector DB".** L'eliminació de la base de dades vectorial redueix la complexitat operativa i conceptual. No hi ha models d'incrustació per triar, no hi ha índex per mantenir, no hi ha ajust de recuperació. Per a desplegaments a petita escala, això és una simplificació real.

**Consolidació activa.** La consolidació basada en temporitzadors és la part més distintiva. La majoria dels sistemes de memòria són passius: emmagatzemar coses, recuperar coses. Aquest connecta, comprimeix i sintetitza activament. Troba patrons que no has preguntat. Això ressona amb qualsevol que vulgui "memòria que pensa" en lloc de memòria que espera.

## On els enfocaments divergeixen

L'agent de memòria Always-On i Neotoma comparteixen un objectiu (memòria d'agent persistent), però divergeixen en gairebé totes les decisions de disseny. Les divergències no són casuals. Reflecteixen diferents premisses inicials sobre per a què s'ha d'optimitzar la memòria.

### Ingestió automàtica vs explícita

El control de fitxers és automàtic. Qualsevol cosa que arribi a la safata d'entrada es processa. No hi ha cap pas d'aprovació, cap validació de l'esquema primer, cap confirmació de l'usuari abans que el LLM extreu i emmagatzemi. Neotoma adopta l'enfocament contrari: res no entra al sistema tret que un agent o usuari ho escrigui explícitament a través de MCP. Per a notes personals, la ingestió automàtica és convenient. Per a qualsevol cosa amb requisits de privadesa o de compliment, el control explícit és l'opció predeterminada més segura.

### Qui decideix què recordar

Neotoma confia en l'agent del client per trucar a l'emmagatzematge de memòria. L'agent amb qui parleu (ChatGPT, Claude, Cursor) decideix què val la pena recordar i com estructurar-lo. Quan conclou que un fet, contacte o tasca ha de persistir, invoca l'operació de la botiga mitjançant MCP. La responsabilitat de "què recordar" roman a la capa d'agent, en el mateix procés que la vostra conversa.

L'agent de memòria Always-On divideix aquesta responsabilitat entre subagents especialitzats. L'agent d'ingestió decideix què extreure dels fitxers. L'agent de consolidació decideix què fusionar i quines connexions establir. L'agent de consulta decideix què tornarà. "Què val la pena recordar" i "com" es distribueixen entre aquests subagents, que funcionen independentment de la conversa. L'usuari no aprova cada decisió. Els subagents els fan en segon pla.

### LLM vs extracció determinista

L'agent de memòria Always-On utilitza el LLM per a tot: extreure entitats, assignar importància, generar resums. Executeu la mateixa extracció al mateix fitxer dues vegades i els resultats poden ser diferents. Neotoma utilitza [extracció determinista primer esquema](/posts/truth-layer-agent-memory). La mateixa entrada produeix les mateixes entitats, els mateixos ID canònics, les mateixes relacions. La interpretació de LLM opcional s'executa a la part superior d'aquesta capa determinista, no en el seu lloc.

### Consolidació vs veritat immutable

L'agent de consolidació decideix què fusionar, quines connexions dibuixar i què comprimir. Muta la memòria amb el temps. Els vells records s'absorbeixen en nous coneixements sintetitzats. El neotoma no es consolida. S'adjunta. Tota observació és immutable. La història es basa en els esdeveniments. Si necessiteu veure què ha canviat, quan i per què, hi trobareu el camí complet. Res no es sobreescriu ni es comprimeix.

### Plataforma única vs multiplataforma

El projecte es basa en Gemini i Google ADK. La memòria viu en un fitxer SQLite local accessible només mitjançant aquesta pila d'agents específica. Neotoma exposa la memòria mitjançant MCP, la qual cosa significa que les mateixes entitats són accessibles des de ChatGPT, Claude, Cursor i qualsevol altra eina compatible amb MCP. Una capa de memòria, diversos consumidors.

### Sense procedència vs llinatge complet

Els registres de memòria de l'agent de memòria Always-On contenen resums i entitats extretes, però no es remunten al fitxer, línia o sessió específics que els va produir. Si una visió consolidada és incorrecta, no hi ha cap pista d'auditoria a seguir. A Neotoma, cada camp de cada entitat es remunta a una observació font. Podeu auditar qualsevol fet d'on prové.

### Escala compensacions

Sense incrustacions ni un índex vectorial, el sistema llegeix registres de text estructurat directament mitjançant el LLM. Això funciona a petita escala. A mesura que creixen els magatzems de memòria, és possible que l'enfocament no es mantingui. L'eliminació de la base de dades vectorial no elimina el disseny de recuperació. Mou la complexitat a la finestra de context de LLM. Neotoma utilitza consultes estructurades sobre entitats escrites, que s'escalen independentment dels límits del context LLM.

## Substrat vs agent

La distinció més clara és el rol. L'agent de memòria Always-On és un agent. Ingereix automàticament, es consolida en un horari i sintetitza les respostes. Té el seu propi bucle de raonament. Decideix què fusionar, quines connexions dibuixar i quan comprimir.

Neotoma no és un agent. És un substrat. Emmagatzema entitats escrites amb identificadors canònics. Manté la procedència. Respon a preguntes deterministes. No decideix res per si sol. Sense ingesta de fons. Sense consolidació automàtica. Sense processament basat en el temporitzador. Els agents llegeixen i hi escriuen mitjançant [MCP](/posts/agentic-search-and-the-truth-layer). El raonament passa a la capa d'agent. La veritat viu en el substrat.

Això importa pel que passa quan l'agent s'equivoca. Si la consolidació de l'agent de memòria Always-On produeix una mala visió, aquesta visió ara forma part de la memòria. No hi ha cap capa separada per verificar. L'agent és la veritat.

Amb una capa de veritat a sota, podeu rastrejar què va llegir l'agent, quan ho va llegir i què va escriure. Si la nova visió és incorrecta, podeu revertir-la. La sortida de l'agent de consolidació és una observació a sobre de l'estat determinista, no una mutació d'aquest.

| Dimensió | Agent de memòria sempre activa | Capa de la veritat (Neotoma) |
|-----------|------------------------|-------------------------|
| Rol | Agent amb bucle de raonament | Substrat sense comportament d'agent |
| Qui decideix què emmagatzemar | Subagents especialitzats (ingestió, consolidació) | Agent de client (mitjançant MCP) |
| Ingestió | Automàtic (observador de fitxers, API) | Només explícit (MCP, CLI, càrrega) |
| Extracció | impulsat per LLM; probabilística | Esquema primer; determinista |
| Consolidació | Consolidació de LLM basada en temporitzadors | Cap; veritat immutable, actualitzacions d'origen d'esdeveniments |
| Procedència | Bàsic (font/resum en registres) | Llinatge complet; cada camp traça a la font |
| Plataforma | Només Gemini/Google ADK | Multiplataforma mitjançant MCP (ChatGPT, Claude, Cursor) |
| Privacitat | No es posiciona com a privadesa primer | Controlat per l'usuari; sense accés de proveïdor |
| Retrocés | No; la memòria es muta per consolidació | Sí; només adjuntar, versionat, reversible |
| Maqueta | LLM llegeix tots els registres; limitada pel context | Consultes estructurades sobre entitats escrites |

## Com podrien treballar junts

Els dos enfocaments no s'exclouen mútuament. Un agent de consolidació i una capa de veritat resolen diferents problemes. Un troba patrons. L'altre manté la confiança. La interessant arquitectura combina ambdues coses.

El croquis és senzill. Un agent de consolidació (com el de l'agent de memòria Always-On) llegeix entitats d'una capa de veritat mitjançant MCP. Té accés a l'estat estructurat complet: entitats mecanografiades, relacions, línies de temps, procedència. Executa el seu bucle de cerca de patrons sobre aquest estat, buscant connexions, buits o coneixements que l'usuari no ha demanat. Quan troba alguna cosa, escriu el resultat a la capa de veritat com una nova observació, etiquetada amb les seves entitats font i raonament.

La capa de veritat tracta aquesta visió de la mateixa manera que tracta qualsevol altra escriptura. Ho registra com una observació amb plena procedència: quines entitats llegeix l'agent, quan, què va concloure. La visió esdevé part del gràfic de l'entitat. Si la visió és incorrecta, podeu veure exactament què va consumir l'agent, rastrejar el raonament i revertir l'observació sense afectar les entitats subjacents de les quals va llegir.

Això és diferent de com funciona la consolidació a l'agent de memòria sempre activat actualment. Allà, l'agent de consolidació muta directament la memòria. Els vells records s'absorbeixen en nous registres sintetitzats. L'estat anterior ha desaparegut. Si la síntesi va ser incorrecta, no hi ha cap capa separada per comparar.

Amb una capa de veritat a sota, la consolidació es converteix en una operació no destructiva. L'agent afegeix una capa d'interpretació a la part superior de l'estat determinista. El propi estat es manté immutable. Obteniu els avantatges del descobriment de patrons actius (la força de l'agent de memòria sempre activat) amb els avantatges de l'auditabilitat i el retrocés (la força de la capa de veritat). Intel·ligència a dalt, confiança a sota.

## Què valida això

L'agent de memòria Always-On és una implementació de referència, no un producte. El que confirma és que la demanda de memòria d'agent persistent i dinàmica és real. "[Vector DB més RAG](/posts/why-agent-memory-needs-more-than-rag)" no és l'únic model de recuperació. Les [tendències estructurals que ho impulsen](/posts/six-agentic-trends-betting-on) són clares: els agents s'estan convertint en estats, els errors tenen un preu i les plataformes segueixen sent opaques. El projecte indica que la indústria s'està movent cap a sistemes de memòria sempre activats que van més enllà del simple emmagatzematge i recuperació.

On els dos projectes coincideixen: la memòria passiva no és suficient. On no estan d'acord: si la capa de memòria mateixa hauria de raonar, o si el raonament hauria de passar en una capa separada a la part superior de l'estat determinista. Aquesta és una qüestió bàsica en l'arquitectura de memòria d'agents ara mateix. El mercat probablement donarà suport als dos enfocaments. Espero que l'arquitectura pugui convergir en agents de consolidació que pensen, s'executen sobre capes de veritat en les quals podeu confiar.

## El que estic construint

Estic creant [Neotoma](https://github.com/markmhendrickson/neotoma) com a capa de confiança. Entitats escrites, identificadors canònics, fusió determinista, procedència, accés multiplataforma mitjançant MCP. El faig servir diàriament a ChatGPT, Claude i Cursor. La [versión del desenvolupador](/posts/neotoma-developer-release) està disponible ara a [neotoma.io](https://neotoma.io).

La mostra de Google mostra que la indústria convergeix en la memòria d'agent persistent. La qüestió oberta no és si els agents recordaran, sinó com. Capacitat o governança. Agent o substrat. Consolidació probabilística o veritat determinista. Estic apostant per aquest últim.