FERNme: memoria de agente que modela al usuario, no al transcript — y lo hace con cero escrituras de LLM

La mayoría de los sistemas de memoria de agentes le pagan a un modelo de lenguaje para leer todo el transcript y re-extraer lo que ya sabía. FERNme se niega. Escribe la memoria con aritmética sobre un grafo, no llama a ningún LLM en el path de escritura, y mantiene la card de prompt cerca de 25 tokens de por vida.

FERNme — la Fuzzy-Edged Recall Network — se describe en una línea: "memoria de personalización de agente que modela al usuario, no al transcript." Es un research preview v0.3 bajo Apache 2.0, Python 3.10+, respaldado por SQLite por defecto o PostgreSQL 16 en producción, y trae tres superficies que a un operador de agentes le importan: una REST API en FastAPI, un MCP server, y una web UI glass-box donde el usuario puede ver y editar cada creencia que el sistema tiene sobre él. El diseño es opinionado de una forma que vale la pena estudiar, porque invierte el supuesto horneado en buena parte del stack de memoria que cubrimos en nuestra actualización de arquitecturas de memoria.

Memoria que modela al usuario, no al transcript

El patrón dominante para memoria de agentes es la extracción: tras cada interacción, le pasas la conversación a un LLM y le pides que resuma, deduplique y guarde los hechos salientes. Funciona, pero tiene dos costos estructurales. El resumen crece con la historia, así que el contexto que inyectas se sigue inflando; y cada escritura quema tokens de modelo, alrededor de dos llamadas a LLM por interacción en sistemas basados en extracción.

La apuesta de FERNme es que la personalización no necesita una narrativa de lo que pasó — necesita un modelo de quién es el usuario. Un usuario que reserva asientos de pasillo, evita la comida picante, y compra para sus hijos no necesita que eso se re-derive de un transcript cada sesión. Necesita ser un perfil chico, estable y editable. Así que FERNme guarda el perfil directamente y nunca guarda el transcript.

Aritmética, no extracción

El path de escritura es la parte interesante. Cuando llega un evento — un clic, una compra, una preferencia declarada — FERNme lo mapea a través de un vocabulario controlado de tags con namespace (pref:, topic:, goal:, context:) y refuerza los edges entre los nodos que co-ocurrieron. Eso es una actualización Hebbiana: los nodos que se activan juntos se cablean juntos. Los edges llevan pesos difusos de 0 a 9, el reforzamiento satura para que nada se desboque, y un decay estilo ACT-R deja que las preferencias viejas se desvanezcan.

Crucialmente, todo eso es aritmética de enteros sobre un grafo. Como lo plantea el proyecto: "las actualizaciones de memoria son aritmética sobre un grafo — 0 llamadas a LLM por interacción vs. ~2 para memoria basada en extracción." El modo pure por defecto nunca toca un modelo en el hot path; dos modos experimentales, gated y offline, permiten un tagger LLM opcional para texto libre novedoso, pero siempre fuera del path de escritura. El resultado es una capa de memoria cuya latencia y costo de escritura están desacoplados por completo del pricing del modelo.

# Conceptual: un evento se vuelve updates de edges, no una frase guardada
evento: el usuario compra un impermeable talla niño
→ reforzar edge(usuario ↔ "topic:kids")
→ reforzar edge(usuario ↔ "pref:waterproof")
# 0 llamadas a LLM. Solo escrituras Hebbianas saturantes con decay.

La card de 25 tokens

Lo que el agente realmente recibe en tiempo de inferencia es una "card." FERNme reporta que se mantiene en 24.9 ± 0.5 tokens sea la primera visita del usuario o su quinto año — plana, por construcción. Lo logra con un population prior: la card guarda solo las desviaciones del usuario respecto a lo que un usuario promedio preferiría, así que todo lo obvio y compartido se lee desde el prior y nunca cuesta un token. El proyecto mide el baseline de historia completa creciendo hasta 77× más grande a las 120 interacciones; la card de FERNme no crece.

La recuperación usa spreading activation a través del grafo difuso: un contexto entrante activa los nodos cercanos, y los vecinos más fuertemente activados se ensamblan en la card de tokens mínimos. Los usuarios nuevos no están fríos — el population prior da una ventaja de patrón colectivo que el proyecto mide como +0.06 precision@5 en los primeros tres turnos, con k-anonimato y privacidad diferencial para que ningún individuo se filtre al prior.

Supernode: un perfil que el usuario controla

La pieza que hace esto más que un cache es el supernode. Cuando un usuario inicia sesión en distintos sitios, FERNme ensambla sus memorias por sitio en un solo perfil indexado a un person ID opaco derivado de un token verificado. El framing es explícito: "inicia sesión en distintos sitios, tus memorias se ensamblan como Lego en un perfil que controlas, default-deny, data sensible aislada." Los sitios no pueden leer la data de otros sin consentimiento, las categorías sensibles se excluyen del compartir cross-site, y el usuario obtiene endpoints REST para la gobernanza que eso implica — /edit, /export, /delete, más un forget_everywhere que borra el perfil y lo desaprende del population prior. Un event log append-only con una cadena HMAC tamper-evident respalda el reclamo de propiedad.

Esta es la inversión: en vez de que cada sitio construya un perfil privado y opaco del usuario, el usuario controla un perfil transparente y presta vistas con scope de él a los sitios y agentes que elige.

Por qué las escrituras deterministas resisten la inyección

Hay un dividendo de seguridad que cae gratis de la arquitectura. Como las escrituras son aritmética y no extracción LLM, el texto malicioso en una página o en un mensaje del usuario no puede ser "convencido" de volverse una creencia guardada. El proyecto lo dice sin rodeos — "las instrucciones inyectadas nunca entran a la memoria" — y trata los tags de evento como no confiables, aplicando descarte de patrones de inyección y caps de valor en una capa de seguridad. Una memoria a la que un atacante no puede escribir con prosa cierra uno de los agujeros más feos del threat model de agentes: el envenenamiento persistente de memoria, donde una mala interacción corrompe cada sesión futura.

Las cifras — y los caveats

FERNme publica una suite de benchmarks, y las cifras titulares son llamativas. En detección de drift — notar que las preferencias de un usuario cambiaron — reporta 0.72 de recall versus 0.13 de un contador de frecuencia. La context precision@3 cae en 0.62 versus 0.51 del baseline. En el Pareto costo/calidad por 1,000 interacciones, el modo pure reporta 0.52 de calidad a $0.008, lo que enmarca como 122× más barato que Mem0; un modo gated llega a 0.66 de calidad a $0.023 (42× más barato); un modo offline 0.73 a $0.104 (9× más barato). Un piloto simulado de storefront reporta un +16% de lift relativo en conversión. El repositorio trae 119 tests pasando y scripts de evaluación reproducibles.

Qué significa para LLM4Agents

Una capa de memoria de tokens planos y sin LLM está directamente alineada con cómo factura LLM4Agents. En un gateway donde un agente paga por llamada en stablecoins vía x402, dos llamadas de extracción LLM por interacción no son solo latencia — son ítems de línea en cada turno. Una memoria que escribe gratis e inyecta una card de 25 tokens en vez de un resumen creciente ataca exactamente la curva de costo que un operador vigila, la que dimensionamos en nuestra pieza de economía de flota.

También encaja en el cableado. FERNme ya trae un MCP server, así que un agente corriendo contra nuestro gateway podría montarlo como superficie de tools y leer o escribir la memoria del usuario a través del mismo protocolo que usa para todo lo demás — el modelo que recorrimos en el deep dive de MCP. Y su determinismo es una respuesta distinta a la misma pregunta que hizo nuestra comparación de Graphiti y Mem0: cómo le das a un agente memoria durable sin el costo y la superficie de inyección de las escrituras mediadas por LLM.

Cómo mantenerse en la frontera

Leyendo a FERNme como una señal y no como un solo proyecto, tres movimientos mantienen a un gateway de pagos para agentes por delante de hacia dónde va la memoria:

• Tratar la memoria como una primitiva facturable. Los agentes en el gateway ya pagan por token; una tool de memoria de costo plano y sin LLM es un default competitivo que vale la pena exponer, y una MCP-native como FERNme se enchufa sin un protocolo nuevo.
• Hacer de los perfiles user-owned una opción de primera clase. El modelo supernode — un perfil transparente que el usuario controla, prestado a los agentes default-deny — se alinea con hacia dónde van la identidad y el consentimiento de agentes; el gateway que soporta memoria portable y user-owned gana el argumento de confianza.
• Preferir paths de escritura deterministas donde encajen. La memoria aritmética resistente a inyección elimina toda una clase de ataques de envenenamiento. Donde la personalización es el trabajo, una capa determinista debería ser el default y la extracción LLM la excepción, no al revés.

FERNme es temprano, y sus cifras más audaces aún son sintéticas. Pero la idea debajo de él — que un agente debería cargar un modelo del usuario chico, propio y resistente a manipulación en vez de un transcript que crece sin fin — es la forma correcta para la memoria en un mundo donde cada escritura cuesta dinero y cada input es un ataque potencial.