Centres de comandament d'agents com a font de veritat

Pawel Jozefiak va escriure recentment sobre l'execució d'un agent d'IA personal i les eines que va crear per gestionar-lo. Va passar de Notion a Obsidian a un tauler personalitzat recolzat per SQLite, després a una aplicació nativa SwiftUI amb mode de focus i visibilitat de la barra de menús.

L'error crític que va colpejar va ser que les tasques es tornaven a executar perquè la finalització no es va registrar de manera fiable. Va acabar amb un sistema de memòria de sis capes (memòria de treball, rollover setmanal, índex permanent, perfils profunds, cerca semàntica, canal de millora personal) i una conclusió clara. Hi ha un buit entre les eines de tasques genèriques i els IDE d'agent complets. El que falta és un "Centre de comandaments" per al cicle de vida de l'agent: reclamar, executar, revisar, iterar, amb visibilitat en temps real.

Estic construint Neotoma, una capa de veritat per a la memòria de l'agent. No crea el tauler ni l'agent. Proporciona la capa que utilitzaria un centre de comandaments.

El buit que va descriure

Les opcions de Jozefiak eren massa genèriques (Trello, Linear) o massa tècniques (terminal, JSON). Els taulers genèrics no coneixen l'estat de l'agent. Qui va afirmar què? L'agent treballa o està esperant la revisió? Com es registra la finalització perquè l'agent no executi la mateixa tasca dues vegades? Els registres en brut i JSON no us donen cap tauler.

Necessitava alguna cosa entremig: un lloc únic on l'agent i l'ésser humà comparteixin la tasca, amb una semàntica clara per a la reclamació, el complet i l'estat, i prou ràpid perquè les enquestes o les actualitzacions en temps real no caiguin. Aquest "únic lloc" és un problema de dades. El centre de comandaments és la IU. El que llegeix i on escriu és el substrat.

El que proporciona una capa de veritat

Neotoma emmagatzema entitats mecanografiades, observacions i relacions. Els exposa a través de MCP perquè qualsevol agent (Claude Code, Cursor, un corredor programat) pugui emmagatzemar i corregir l'estat. S'incorporen identificacions d'idempotència i deterministes.

Quan l'agent reclama una tasca, emmagatzema o corregeix una entitat amb l'estat "en curs". Quan es completa, es corregeix de nou amb l'estat "fet". La mateixa clau d'idempotència, el mateix resultat cada vegada. L'error de Jozefiak (no s'ha enregistrat la finalització, la tasca es torna a executar) és exactament el que pretenen evitar les escriptures idempotents i duradores.

Un tauler de control o una aplicació nativa que vulgui mostrar "què està fent l'agent" consultaria la mateixa botiga: llista d'entitats per tipus (p. ex. tasca), filtra per estat, mostra l'assignat i les marques de temps. L'agent i el tauler comparteixen una font de veritat. No hi ha SQLite personalitzat, ni cap capa de sincronització que pugui derivar. El tauler és una vista sobre Neotoma.

On encaixa la memòria de sis capes

Les sis capes de Jozefiak (memòria de treball, transferència setmanal, índex permanent, perfils profunds, cerca semàntica, millora personal) són preocupacions de la capa estratègica i de la capa d'aplicació. Ells decideixen què mantenir, què comprimir, què resumir i què retroalimentar el comportament de l'agent.

Neotoma no fa compactació ni resum. És la botiga duradora i estructurada des d'on es llegeixen i escriuen les capes. La memòria de treball pot ser "últimes N observacions" o "entitats tocades en les últimes 48 hores". La transferència setmanal pot escriure noves observacions (resums, índexs) a Neotoma. La cerca semàntica es pot executar sobre el mateix gràfic d'entitats. El límit és clar: Neotoma és la capa de la veritat; les capes superiors implementen la política de retenció i l'estratègia de recuperació.

Per què això és important per als constructors

Si esteu creant un agent personal i necessiteu l'estat de la tasca, el seguiment de l'estat i la visibilitat, teniu dos camins. Podeu enrollar el vostre propi emmagatzematge (SQLite, fitxers, una API personalitzada) i després crear un tauler o tauler a la part superior. Us trobareu amb la semàntica de finalització, la idempotència i la coherència entre sessions. O podeu utilitzar un substrat que ja us ofereix entitats, observacions, procedència i accés a MCP. El centre de comandaments es converteix en un client d'aquest substrat. L'agent és un altre client. Tots dos llegeixen i escriuen el mateix estat.

No estic construint el centre de comandament. Estic construint la capa on s'assentaria. Neotoma és el pla de dades per als taulers d'agents i les eines del cicle de vida. Si aquest buit descrit per Jozefiak s'omple amb productes (a l'estil WizBoard o d'una altra manera), aquests productes necessitaran un backend. Una capa de veritat és aquest backend.

Com s'adapta això a les tendències per les quals estic apostant

A sis tendències agentiques sobre les quals vaig escriure recentment, vaig argumentar que els agents es convertiran en actors econòmics amb estat, que els errors es faran visibles econòmicament, que la fragmentació de les eines persistirà i que es mesurarà l'ús. La bretxa del centre de comandament que va colpejar Jozefiak es troba a la intersecció d'aquestes pressions.

Quan els agents tenen un estat i tenen una llarga durada, cal veure què estan fent. Tendència 1: "Les interfícies de producte que exposen la història de l'agent com una cosa inspeccionable en lloc d'efímer" és exactament el que és un centre de comandaments. Quan els errors costen diners o reputació, cal saber què sabia l'agent en aquell moment. Tendència 2: traçabilitat i "què sabia l'agent?" fer que una única font de veritat per a les tasques i l'estat sigui necessari, no és agradable tenir-ho.

Quan utilitzeu diverses eines i models, indiqueu fragments. Tendència 5: el centre de comandaments i l'agent han de llegir i escriure el mateix estat, per això el substrat s'ha de situar a sota de la interfície d'usuari. Quan l'ús té un preu, tornar a executar la mateixa tasca perquè no es va registrar la finalització és un residu visible. Tendència 6: la finalització idempotent i duradora és tant una optimització com una garantia de correcció.

Estic provant Neotoma en els meus propis fluxos de treball d'agent i documentant el patró del "cicle de vida de la tasca de l'agent": emmagatzemar entitats de tasques, utilitzar observacions per a l'estat i l'historial, actualitzar mitjançant MCP correctament amb claus d'idempotència perquè la finalització sigui inequívoca. Aquest patró és el que impulsaria una vista del centre de comandaments (reclamar, executar, revisar, iterar) sense que cada constructor reinventés la seva pròpia lògica SQLite i sincronització. També estic afegint "tauler d'agent / backend del centre de comandaments" a com descric Neotoma perquè altres que vulguin crear aquest tipus d'eina sàpiguen que hi ha un substrat sobre el qual poden construir.