## L'opció de base de dades que envelleix malament

Una empresa crea un agent d'atenció al client. Emmagatzema les observacions en una base de dades, Postgres, Mongo, Redis, sigui el que ja faci l'equip. Mesos després, un altre equip crea un agent de salut del compte. Algú els connecta perquè un humà es va cansar de copiar i enganxar context entre eines. Aquesta connexió, una taula de base de dades compartida, es converteix en un estat compartit multiagent per accident.

Ara tres agents comparteixen l'estat dels comptes dels clients: assistència d'entrada, puntuació de salut i recomanacions de renovació.

L'agent de suport processa un client frustrat i emmagatzema: "el client va expressar la seva insatisfacció amb el preu, considerant alternatives". L'agent de puntuació de salut llegeix això, rebaixa el compte. L'agent de renovació llegeix la puntuació rebaixada, genera i envia una oferta de descompte. Tot en qüestió de minuts. Cap humà al bucle.

L'observació inicial de l'agent de suport era incorrecta. El client es va frustrar amb un error de facturació, no de preus. Però l'extracció de memòria mediada per LLM va comprimir la interacció en un resum enganyós, i aquest resum es va propagar a través de l'estat compartit com a veritat bàsica.

La recuperació va funcionar a cada pas. El fracàs va estar en l'escriptura. Res del sistema no podia detectar que l'observació inicial fos infidel a la seva font, ni rastrejar la cadena causal des de la mala escriptura fins a la mala acció.

## Per què els sistemes d'agent únic emmascaren el problema

Amb un agent escrivint en un magatzem de memòria, la corrupció d'escriptura degrada la qualitat lentament. L'agent resumeix una observació lleugerament equivocada. Sobreescriu un atribut d'entitat. Emmagatzema fets contradictoris. El sistema encara funciona. A poc a poc es fa menys fiable. La capa de memòria mai es culpa perquè el mode de fallada sembla un problema de LLM.

Aquí és on avui es troben gairebé tothom. El dolor és latent. Ningú pot respondre preguntes bàsiques: què va aprendre l'agent, quan, de quina font, va contradir alguna cosa que va emmagatzemar la setmana passada. Però el sistema no es trenca visiblement. La confiança s'erosiona subtilment.

## Què canvia amb diversos agents

Quan l'agent A escriu observacions que l'agent B llegeix i sobre les quals actua, sorgeix una topologia de fallada diferent.

**Amplificació de contradiccions.** Dos agents emmagatzemen fets conflictius sobre la mateixa entitat a partir d'interaccions diferents. Un tercer agent arriba per prendre mesures i veu qualsevol fet que apareix la capa de recuperació, sense cap base per a adjudicar-se entre ells. Sense un registre d'observació només adjunt amb segells de temps i atribució de la font, no hi ha cap camí forense per entendre la contradicció.

**Cascades de sobreescritura silenciosa.** L'agent A actualitza un registre. L'agent B, que opera amb una lectura obsoleta, escriu la seva pròpia actualització que implícitament reverteix el canvi de l'agent A. En una base de dades mutable, això és gairebé indetectable. En un registre només adjunt amb observacions enllaçades amb hash, és estructuralment impossible.

** Col·lapse del límit de confiança.** L'estat compartit significa que cada agent confia en les escriptures de l'altre. Però els agents tenen diferents capacitats, contextos d'avís i perfils d'error diferents. Un agent d'anàlisi financera especialitzat i un agent de suport de propòsit general probablement no haurien de tenir la mateixa autoritat d'escriptura sobre el mateix estat de l'entitat. En una base de dades plana sense restriccions d'esquema sobre qui pot escriure què, ho fan.

## Les quatre fases

La indústria s'està movent per un arc previsible.

### 1. "Només utilitzeu Postgres" (o [només feu servir un fitxer de reducció](/posts/the-markdown-memory-ceiling))

Manus, Claude Code i OpenClaw utilitzen fitxers de text senzill per a la memòria. Evolució convergent, no un llibre de jocs compartit. Quan un equip arriba a una base de dades, la memòria s'enganxa al que ja hi ha: RAG sobre Postgres amb pgvector, Redis per a l'estat de la sessió, incrustacions a Pinecone. Qualsevol camí funciona per a casos d'ús senzills. El model mental és que els agents necessiten recordar coses, fitxers o bases de dades emmagatzemen coses, problema resolt.

### 2. Optimització de la recuperació

Productes com Mem0, Zep i MemPalace accepten que els agents necessiten una abstracció de memòria dedicada, però emmarquen el problema com a qualitat de recuperació. Com introduir el context adequat al missatge en el moment adequat. Això resol un problema que els desenvolupadors ja poden sentir: mal record, finestres de context inflades, recuperacions irrellevants. Però aquesta fase deixa el camí d'escriptura sense auditar. Qualsevol que sigui els extractes de LLM es tracta com a veritat bàsica.

Aquesta fase dominarà durant els propers anys o dos perquè el dolor de recuperació és llegible. Els desenvolupadors s'adonen quan l'agent oblida o recupera la cosa equivocada. La corrupció d'escriptura és il·legible. L'agent actua amb confiança en mal estat i ningú se n'adona fins que apareixen les conseqüències aigües avall.

### 3. La crisi de confiança

Això arriba quan els agents passen d'assistents de baix risc a actors d'alt risc, gestionant diners, prenent decisions d'adquisició, gestionant fluxos de treball de compliment, operant de manera autònoma durant dies o setmanes. La pregunta passa de "l'agent va recuperar el correcte?" a "Puc demostrar què sabia l'agent, quan ho sabia i si aquest coneixement era legítim?"

Els errors d'alt perfil en què els agents van actuar en estat de memòria danyat forçaran aquest canvi. Els compradors empresarials demanaran pistes d'auditoria. Els reguladors en finances i sanitat requeriran una procedència determinista.

### 4. La bifurcació

La indústria es divideix. Camí A: les bases de dades existents afegeixen primitives agents. Postgres obté extensions per al registre d'observació i la resolució d'entitats. Supabase o PlanetScale ofereix una capa de producte de "memòria d'agent". Això captura molts casos d'ús on els requisits de confiança són moderats.

Ruta B: infraestructura d'estat agent dissenyada específicament per als agents que operen a través dels límits de confiança, que mantenen un estat autònom de llarga durada o que necessiten una procedència criptogràfica. Els invariants clau (només per afegir, enllaçats amb hash, restringit per esquemes, resolució d'entitats determinista) són compromisos arquitectònics que no es poden adaptar de manera fiable com a extensions de base de dades.

Aquest és el camí on els sistemes agents assoleixen tot el seu potencial. Els agents que poden confiar en el seu propi estat, traçar el seu propi raonament i coordinar-se amb altres agents sense corrupció silenciosa són qualitativament més capaços que els agents que funcionen amb la memòria del millor esforç.

La integritat de l'escriptura no és una funció de seguretat fixada després del fet. És la base que fa possible el funcionament autònom.

## Com es construiran realment els sistemes multiagent

La majoria no es dissenyaran com a sistemes multiagent. S'aniran acrecentant.

**Hub-and-spoke amb un hub humà** és el patró dominant actual. Un agent principal s'enfronta a l'usuari i delega subtasques a agents especialitzats. L'estat compartit és la finestra de context de l'agent principal. El risc d'integritat d'escriptura és baix. Però aquesta topologia té un sostre dur: els colls d'ampolla de l'agent concentrador no poden mantenir el context en els fluxos de treball de llarga durada. Això s'associa a les fases 1 i 2: "només utilitza Postgres" o una capa de recuperació funciona bé perquè un agent controla l'estat.

Els **agents de canonades** vénen després. Transmissions seqüencials on cada agent processa i enriqueix un element de treball. Liderar la qualificació per a la investigació de l'empresa fins a la redacció de divulgació i la programació de reunions. La integritat de l'escriptura comença a importar aquí. Si l'agent d'investigació emmagatzema dades incorrectes de l'empresa, cada agent aigües avall calibra malament. Aquí és on els equips comencen a passar de la fase 2 a la fase 3: la recuperació encara funciona, però la crisi de confiança s'està acumulant sota la superfície.

**Agents basats en esdeveniments amb context compartit** segueixen. Diversos agents es subscriuen als esdeveniments des d'un entorn compartit (CRM, base de codi, canal de comunicació), mantenen les seves pròpies perspectives i escriuen observacions a una botiga comuna. Sense orquestrador. Aquesta és la fase 3 al complet: les escriptures concurrents d'agents amb diferents marcs interpretatius, cap coordinador per detectar contradiccions i la integritat de l'escriptura esdevé realment perillosa.

**Agents autònoms persistents amb estat de llarga durada** són l'estat final. Els agents funcionen contínuament, mantenen models de món en evolució, es sincronitzen periòdicament amb altres agents o amb un magatzem de veritat compartit. Les finestres de context no poden servir com a memòria. Aquests agents necessiten un emmagatzematge persistent amb garanties reals d'integritat. Aquesta és la fase 4: la bifurcació. O la vostra infraestructura es va crear per a això o no ho va ser.

Una tensió clau és que molts desenvolupadors trien el seu emmagatzematge a les topologies 1 i 2, quan el risc d'estat compartit és lleu. Trien qualsevol base de dades que ja tinguin i afegeixen una taula de records. Quan arriben a les topologies tres i quatre, els compromisos arquitectònics s'han incorporat. La migració de l'estat mutable a l'estat només adjunt no és un intercanvi de biblioteca. És una rearquitectura.

## La superfície d'integració que importa

L'arquitectura guanyadora probablement no sigui "substituir la vostra base de dades" sinó "seure entre els vostres agents i la vostra base de dades".

Els agents escriuen observacions a una capa d'integritat d'escriptura: només adjunta, limitada per esquemes, seguiment de procedència. Aquesta capa gestiona l'estat llegible per l'agent. La base de dades existent del desenvolupador segueix sent el sistema de registre de dades comercials, registres de clients, transaccions, catàleg de productes. Però l'estat generat per l'agent, les observacions, les inferències, les resolucions d'entitats, les decisions, viuen en una capa específica.

A la pràctica, les dues capes parlen entre elles. Un agent llegeix un registre de client de Postgres, realitza una anàlisi i escriu les seves observacions (puntuació de salut, risc d'abandonament, acció recomanada) a la capa d'integritat d'escriptura amb una referència al registre d'origen. Un segon agent consulta la capa d'integritat per a totes les observacions sobre aquest client, obté una instantània coherent amb la procedència i actua sobre ella. Si alguna cosa va malament, traceu la cadena: quin agent va escriure què, quan, en funció de les dades font. La base de dades empresarial mai es contamina amb l'estat generat per l'agent i la capa d'agent mai perd la pista d'on provenen les seves observacions.

La distinció entre "dades comercials escrites per humans" i "estat d'observació escrit per agents" és l'enquadrament més clar per què es necessita una nova capa de dades. No estàs substituint la seva base de dades. Esteu afegint una capa per a una categoria de dades que no existia abans que els agents comencessin a escriure de manera autònoma.

## El que estic construint

Això és el que fa [Neotoma](https://github.com/markmhendrickson/neotoma). Observacions només adjuntes. Procedència vinculada al hash. Escriptures limitades per esquemes. Resolució determinista d'entitats. Cada observació que escriu un agent és traçable, auditable i coherent des del primer dia.

He estat executant la meva pròpia pila d'agents a través d'ell. Diversos agents (triatge de correu electrònic, gestió de tasques, finances, planificació de continguts) escriuen tots a la mateixa botiga. El problema de l'estat compartit multiagent no és hipotètic per a mi. És el que em trobo cada setmana quan l'extracció d'un agent contradiu la d'un altre, o quan una lectura obsoleta produeix una acció aigües avall en mal estat.

El cost d'esperar per adoptar la integritat de l'escriptura no és un deute tècnic que podeu pagar més tard. És un buit en el vostre historial d'auditoria. Tot abans de la migració és una caixa negra. Aquest buit és permanent.