## La elección de base de datos que envejece mal

Una empresa crea un agente para atención al cliente. Almacena observaciones en una base de datos, Postgres, Mongo, Redis, lo que sea que el equipo ya ejecute. Meses después, otro equipo crea un agente de salud de cuentas. Alguien los conecta porque un humano se cansó de copiar y pegar contexto entre herramientas. Esa conexión, una tabla de base de datos compartida, se convierte en estado compartido de múltiples agentes por accidente.

Tres agentes ahora comparten el estado de las cuentas de los clientes: soporte entrante, puntuación de estado y recomendaciones de renovación.

El agente de soporte procesa a un cliente frustrado y almacena: "el cliente expresó su insatisfacción con el precio, considerando alternativas". El agente de calificación de salud lee esto y degrada la cuenta. El agente de renovación lee la puntuación rebajada, genera y envía una oferta de descuento. Todo en cuestión de minutos. Ningún humano en el circuito.

La observación inicial del agente de soporte fue incorrecta. El cliente estaba frustrado por un error de facturación, no por un precio. Pero la extracción de memoria mediada por LLM comprimió la interacción en un resumen engañoso, y ese resumen se propagó a través del estado compartido como verdad fundamental.

La recuperación funcionó en cada paso. El fallo estuvo en la escritura. Nada en el sistema podía detectar que la observación inicial era infiel a su fuente, ni rastrear la cadena causal desde una mala escritura hasta una mala acción.

## Por qué los sistemas de agente único enmascaran el problema

Cuando un agente escribe en un almacén de memoria, la corrupción de escritura degrada la calidad lentamente. El agente resume una observación ligeramente errónea. Sobrescribe un atributo de entidad. Almacena hechos contradictorios. El sistema todavía funciona. Simplemente se vuelve cada vez menos confiable. Nunca se culpa a la capa de memoria porque el modo de falla parece un problema de LLM.

Aquí es donde estamos casi todos hoy. El dolor está latente. Nadie puede responder preguntas básicas: qué aprendió el agente, cuándo, de qué fuente, contradijo algo que almacenó la semana pasada. Pero el sistema no falla visiblemente. La confianza se erosiona sutilmente.

## ¿Qué cambia con múltiples agentes?

Cuando el Agente A escribe observaciones que el Agente B lee y actúa, surge una topología de falla diferente.

**Amplificación de la contradicción.** Dos agentes almacenan datos contradictorios sobre la misma entidad a partir de diferentes interacciones. Un tercer agente llega para actuar y ve cualquier hecho que la capa de recuperación surja, sin ninguna base para decidir entre ellos. Sin un registro de observación de solo anexos con marcas de tiempo y atribución de fuente, no existe un camino forense para comprender la contradicción.

**Cascadas de sobrescritura silenciosa.** El agente A actualiza un registro. El Agente B, que opera con una lectura obsoleta, escribe su propia actualización que revierte implícitamente el cambio del Agente A. En una base de datos mutable, esto es casi indetectable. En un registro de solo agregar con observaciones vinculadas a hash, es estructuralmente imposible.

**Colapso del límite de confianza.** El estado compartido significa que cada agente confía en las escrituras del otro. Pero los agentes tienen capacidades, contextos de aviso y perfiles de error diferentes. Un agente de análisis financiero especializado y un agente de soporte de propósito general probablemente no deberían tener la misma autoridad de escritura sobre el mismo estado de entidad. En una base de datos plana sin restricciones de esquema sobre quién puede escribir qué, lo hacen.

## Las cuatro fases

La industria se está moviendo a través de un arco predecible.

### 1. "Solo usa Postgres" (o [simplemente usa un archivo de rebajas](/posts/the-markdown-memory-ceiling))

Manus, Claude Code y OpenClaw utilizan archivos de texto sin formato para la memoria. Evolución convergente, no un manual compartido. Cuando un equipo busca una base de datos, la memoria se conecta a lo que ya está allí: RAG sobre Postgres con pgvector, Redis para el estado de la sesión, incrustaciones en Pinecone. Cualquiera de las dos opciones funciona para casos de uso sencillos. El modelo mental es que los agentes necesitan recordar cosas, los archivos o las bases de datos almacenan cosas y el problema está resuelto.

### 2. Optimización de recuperación

Productos como Mem0, Zep y MemPalace aceptan que los agentes necesitan una abstracción de memoria dedicada, pero plantean el problema como calidad de recuperación. Cómo incluir el contexto correcto en el mensaje en el momento adecuado. Esto resuelve un problema que los desarrolladores ya pueden sentir: mala recuperación, ventanas de contexto infladas, recuperaciones irrelevantes. Pero esta fase deja la ruta de escritura sin auditar. Todo lo que extrae el LLM se trata como verdad fundamental.

Esta fase dominará durante uno o dos años porque el dolor de recuperación es legible. Los desarrolladores notan cuando el agente olvida o recupera algo incorrecto. La corrupción de escritura es ilegible. El agente actúa con confianza en el mal estado y nadie se da cuenta hasta que afloran las consecuencias posteriores.

### 3. La crisis de confianza

Esto llega cuando los agentes pasan de ser asistentes de bajo riesgo a actores de alto riesgo, administrando dinero, tomando decisiones de adquisiciones, manejando flujos de trabajo de cumplimiento y operando de forma autónoma durante días o semanas. La pregunta pasa de "¿el agente recuperó lo correcto?" a "¿puedo probar lo que el agente sabía, cuándo lo supo y si ese conocimiento era legítimo?"

Las fallas de alto perfil en las que los agentes actuaron sobre un estado de memoria corrupto forzarán este cambio. Los compradores empresariales exigirán pistas de auditoría. Los reguladores de las finanzas y la atención sanitaria requerirán una procedencia determinista.

### 4. La bifurcación

La industria se divide. Ruta A: las bases de datos existentes agregan primitivas agentes. Postgres obtiene extensiones para el registro de observaciones y la resolución de entidades. Supabase o PlanetScale incluyen una capa de producto de "memoria de agente". Esto captura muchos casos de uso en los que los requisitos de confianza son moderados.

Ruta B: infraestructura estatal de agentes diseñada específicamente para agentes que operan a través de límites de confianza, mantienen un estado autónomo de larga duración o necesitan procedencia criptográfica. Las invariantes clave (resolución de entidad determinista, solo para agregar, vinculada mediante hash, restringida por esquema) son compromisos arquitectónicos que no se pueden adaptar de manera confiable como extensiones de bases de datos.

Este es el camino donde los sistemas agentes alcanzan su máximo potencial. Los agentes que pueden confiar en su propio estado, seguir su propio razonamiento y coordinarse con otros agentes sin una corrupción silenciosa son cualitativamente más capaces que los agentes que funcionan con la memoria del mejor esfuerzo.

La integridad de la escritura no es una característica de seguridad que se implemente después del hecho. Es la base que hace posible el funcionamiento autónomo.

## Cómo se construirán realmente los sistemas multiagente

La mayoría no se diseñarán como sistemas multiagente. Se acumularán.

**El centro y el radio con un centro humano** es el patrón dominante actual. Un agente principal se enfrenta al usuario y delega subtareas a agentes especializados. El estado compartido es la ventana de contexto del agente principal. El riesgo de integridad de escritura es bajo. Pero esta topología tiene un techo rígido: el agente central tiene cuellos de botella y no puede mantener el contexto en flujos de trabajo de larga duración. Esto se asigna a las fases 1 y 2: "simplemente use Postgres" o una capa de recuperación funciona bien porque un agente controla el estado.

**Agentes de canalización** vienen a continuación. Transferencias secuenciales donde cada agente procesa y enriquece un elemento de trabajo. Liderar la calificación para la investigación de la empresa, la redacción de proyectos de divulgación y la programación de reuniones. La integridad de la escritura comienza a importar aquí. Si el agente de investigación almacena datos incorrectos de la empresa, todos los agentes posteriores calibran incorrectamente. Aquí es donde los equipos empiezan a pasar de la fase 2 a la fase 3: la recuperación todavía funciona, pero la crisis de confianza se está acumulando bajo la superficie.

**Les siguen agentes impulsados ​​por eventos con contexto compartido**. Varios agentes se suscriben a eventos de un entorno compartido (CRM, código base, canal de comunicación), mantienen sus propias perspectivas y escriben observaciones en un almacén común. Sin orquestador. Esta es la fase 3 en su totalidad: escrituras simultáneas de agentes con diferentes marcos interpretativos, ningún coordinador que detecte las contradicciones y la integridad de la escritura se vuelve realmente peligrosa.

**Los agentes autónomos persistentes con estado de larga duración** son el estado final. Agentes que se ejecutan continuamente, mantienen modelos mundiales en evolución, se sincronizan periódicamente con otros agentes o un almacén de verdad compartido. Las ventanas de contexto no pueden servir como memoria. Estos agentes necesitan un almacenamiento persistente con garantías reales de integridad. Esta es la fase 4: la bifurcación. O su infraestructura fue construida para esto o no.

Una tensión clave es que muchos desarrolladores eligen su almacenamiento en las topologías uno y dos, cuando el riesgo de estado compartido es leve. Eligen cualquier base de datos que ya tengan y agregan una tabla de recuerdos. Para cuando alcanzan las topologías tres y cuatro, los compromisos arquitectónicos están integrados. Migrar del estado mutable al estado de solo agregar no es un intercambio de biblioteca. Es una reestructuración.

## La superficie de integración que importa

La arquitectura ganadora probablemente no sea "reemplazar su base de datos", sino "sentarse entre sus agentes y su base de datos".

Los agentes escriben observaciones en una capa de integridad de escritura: solo para agregar, con restricciones de esquema y con seguimiento de procedencia. Esa capa gestiona el estado legible por el agente. La base de datos existente del desarrollador sigue siendo el sistema de registro de datos comerciales, registros de clientes, transacciones y catálogo de productos. Pero el estado generado por el agente, las observaciones, las inferencias, las resoluciones de la entidad, las decisiones, viven en una capa construida específicamente.

En la práctica, las dos capas se comunican entre sí. Un agente lee un registro de cliente de Postgres, ejecuta un análisis y escribe sus observaciones (puntuación de estado, riesgo de abandono, acción recomendada) en la capa de integridad de escritura con una referencia al registro de origen. Un segundo agente consulta la capa de integridad para todas las observaciones sobre ese cliente, obtiene una instantánea consistente con su procedencia y actúa en consecuencia. Si algo sale mal, se rastrea la cadena: qué agente escribió qué, cuándo y en función de qué fuente de datos. La base de datos empresarial nunca se contamina con el estado generado por el agente y la capa del agente nunca pierde la pista de dónde provienen sus observaciones.

La distinción entre "datos comerciales escritos por humanos" y "estado de observación escrito por agentes" es el marco más claro de por qué se necesita una nueva capa de datos. No estás reemplazando su base de datos. Está agregando una capa para una categoría de datos que no existía antes de que los agentes comenzaran a escribir de forma autónoma.

## Lo que estoy construyendo

Esto es lo que hace [Neotoma](https://github.com/markmhendrickson/neotoma). Adjuntar sólo observaciones. Procedencia vinculada al hash. Escrituras restringidas por esquema. Resolución de entidades deterministas. Cada observación que escribe un agente es rastreable, auditable y consistente desde el primer día.

He estado ejecutando mi propia pila de agentes a través de él. Múltiples agentes (clasificación de correo electrónico, gestión de tareas, finanzas, planificación de contenido), todos escribiendo en la misma tienda. El problema del estado compartido de múltiples agentes no es hipotético para mí. Es lo que encuentro cada semana cuando la extracción de un agente contradice la de otro, o cuando una lectura obsoleta produce una acción posterior en mal estado.

El costo de esperar para adoptar la integridad de escritura no es una deuda técnica que pueda pagar más adelante. Es un vacío en su historial de auditoría. Todo lo anterior a la migración es una caja negra. Esa brecha es permanente.