Què fa realment la meva pila agèntica

La meva pila d'agent és com puc provar Neotoma. També és el meu sistema operatiu personal. Un monorepo privat on els agents d'IA s'encarreguen de tot, des del triatge de correu electrònic fins a pagaments de Bitcoin fins a desplegaments de llocs web, amb Neotoma com a memòria estructurada a sota.

Totes les funcions que envio a Neotoma es validen aquí primer, principalment a Cursor i secundàriament mitjançant agents terminals com Claude Code, Codex i Cursor CLI. Cada buit que trobo a la memòria de l'agent apareix aquí primer. La pila és com faig la meva vida diària i la meva feina. La fricció que trobo, a més dels comentaris dels usuaris, és el que impulsa el full de ruta de Neotoma.

Tinc la intenció d'obrir la pila. Però el repo ha acumulat mesos de dades personals, scripts codificats als meus comptes i configuració vinculada a la meva configuració. Abans que es publiqui, necessito introduir aquestes dades completament a Neotoma i refactoritzar les eines perquè siguin genèriques. Aquesta feina està en curs.

Aquesta publicació explica què és la pila, com la faig servir i què revela sobre què ha de fer la memòria de l'agent estructurat.

Quina és la pila

La pila és un monorepo amb més d'una dotzena de servidors MCP i CLI, cadascun connectant agents d'IA a un servei diferent: Gmail, Google Calendar, WhatsApp, una cartera Bitcoin, Instagram, Asana, HomeKit, DNSimple, Google Search Console, 1Password, un web scraper i molt més. Alguns són servidors MCP que els agents anomenen com a eines. Altres són CLI que els agents invoquen des del terminal. Tots dos donen als agents el mateix: arribar als serveis externs.

A la part superior dels servidors MCP hi ha regles i habilitats. Les regles són instruccions de comportament persistents que viuen al repositori, no a Neotoma: emmagatzemeu sempre els contactes a Neotoma abans de respondre, mai cometeu secrets, utilitzeu majúscules i minúscules en els títols, feu proves després dels canvis de codi, preferiu la CLI sobre el tauler per als registres i la configuració, enllaceu la primera menció dels noms dels productes. Les habilitats són fluxos de treball de diversos passos: classificar la meva safata d'entrada, redactar una publicació de bloc, desplegar un lloc web, processar comentaris sobre el producte, extreure una comanda d'Amazon del correu electrònic, pagar a un contractista en Bitcoin.

I a sota de tot hi ha Neotoma com a capa de memòria estructurada. Cada agent hi llegeix i hi escriu. Això és el que fa que la pila es composi al llarg del temps en lloc de restablir-se a cada sessió.

Com treballo amb això

Visc a Cursor. El meu dia és una seqüència de sessions d'agents. Obro un agent nou, descric el que vull que es faci i l'agent s'executa utilitzant els servidors, regles i habilitats MCP de l'espai de treball. Algunes sessions són ràpides: "respon a aquest correu electrònic". Algunes són llargues: "tria la meva safata d'entrada, processa els darrers comentaris dels provadors i, a continuació, redacta una publicació comparativa sobre l'agent de memòria de Google".

És treballar conjuntament amb agents. M'assec al meu escriptori i treballo al costat d'ells tot el dia. Tasques personals: programar una reparació, pagar un contractista, gestionar esdeveniments del calendari. Professionals: redacció de publicacions, processament de feedback, desplegament de llocs web, gestió de dominis. Els agents s'encarreguen de l'execució. Proporciono direcció, reviso resultats i aprovo accions que necessiten un ésser humà al bucle.

Cada sessió d'agent té el context de l'espai de treball complet: cada servidor MCP, cada regla, cada habilitat. L'agent pot llegir el meu Gmail, consultar el meu calendari, consultar el context previ a Neotoma, emmagatzemar dades noves, generar imatges, enviar codi i verificar els desplegaments. El meu paper és cada cop més descriure la intenció i revisar els resultats.

Com encaixa Neotoma

Sense memòria estructurada, cada sessió d'agent comença des de zero. L'agent no sap qui són els vostres contactes, quines tasques teniu obertes, què vau comentar ahir o què ja vau pagar a algú. Podeu enganxar context a cada indicació, però això no s'escala més enllà d'unes quantes sessions. Memòria de plataforma emmagatzema el vostre ambient, no el vostre treball. RAG ajuda amb el codi, però no amb els fets estructurats que impulsen els fluxos de treball: a qui deu diners, quins comentaris vau rebre la setmana passada i quines tasques encara estan obertes.

La meva instància de Neotoma emmagatzema més de 1.000 contactes, 600 tasques, 140 converses, 120 publicacions de bloc i 170 tipus d'entitats que els agents van crear a mesura que trobaven nous tipus d'informació: transaccions, regles permanents, notes de comentaris, esdeveniments del calendari, disputes, factures, habilitats, resultats de desplegament. Quan un agent inicia una sessió nova, recupera el que necessita. Quan acaba, emmagatzema el que ha après.

Aquests són els 20 principals tipus d'entitats de la meva instància de Neotoma avui, amb un exemple de cadascun:

Cap d'aquests esquemes es va dissenyar per endavant. Els agents creen i amplien esquemes segons sigui necessari a mesura que troben nous tipus d'informació. El sistema té ara un total de 170 tipus d'entitats, la majoria amb només un grapat de registres. La llarga cua és on la memòria de l'agent es posa interessant: una única entitat en disputa amb el seu historial complet de negociacions, un únic compromís de fer un seguiment amb algú si canvia l'estratègia, una única preferència sobre com gestionar un pagament específic.

La diferència pràctica és que els agents es basen en el treball previ. Quan demano a un agent que enviï un correu electrònic a algú, primer cerca en Neotoma el contacte. Quan li demano que processi els comentaris, recupera les entitats de comentaris existents i enllaça de noves. Quan li demano que pagui a un contractista en Bitcoin, coneix la regla permanent (pagueu sempre a aquesta persona en BTC) i inclou l'enllaç de la transacció a la confirmació perquè ho diu una altra regla permanent.

Emmagatzematge i recuperació de prop

El Neotoma MCP exposa eines que els agents truquen directament. A continuació, es mostra com és l'emmagatzematge i la recuperació reals a la pràctica.

Quan un agent necessita mantenir un torn de conversa amb les entitats extretes, crida a "store" amb una única càrrega útil:

botiga({
  "entitats": [
    {
      "entity_type": "conversa",
      "title": "Triatge de correu electrònic el 9 de març"
    },
    {
      "entity_type": "missatge_agent",
      "rol": "usuari",
      "content": "triatge de la meva safata d'entrada",
      "clau en mà": "conv-42:1"
    },
    {
      "entity_type": "contacte",
      "full_name": "Alex Chen",
      "correu electrònic": "alex@example.com",
      "source": "trucada de comentaris del provador"
    },
    {
      "entity_type": "tasca",
      "title": "Seguiu els comentaris d'Alex",
      "status": "pendent",
      "priority": "mitjana"
    }
  ],
  "relacions": [
    {
      "relationship_type": "PART_OF",
      "source_index": 1,
      "índex_destí": 0
    },
    {
      "relationship_type": "REFERS_TO",
      "source_index": 1,
      "índex_destí": 2
    },
    {
      "relationship_type": "REFERS_TO",
      "source_index": 1,
      "índex_destí": 3
    }
  ],
  "idempotency_key": "conv-42-turn-1-triage"
})

Una trucada emmagatzema la conversa, el missatge, un contacte nou i una tasca, tot enllaçat per relacions escrites. L'agent no necessitava prèviament una definició d'esquema per a "contacte" o "tasca". Neotoma accepta camps arbitraris i dedueix l'estructura.

Quan un agent necessita context abans de respondre, consulta per identificador:

retrieve_entity_by_identifier({
  "identifier": "Alex Chen"
})

Això retorna el registre de contacte amb el correu electrònic, les converses prèvies i la procedència de cada camp. Si l'agent necessita un context més ampli, consulta per tipus:

recuperar_entitats({
  "entity_type": "feedback_note",
  "search": "Versió per a desenvolupadors",
  "límit": 10
})

Això retorna les deu notes de comentaris més rellevants sobre la versió del desenvolupador, cadascuna amb la seva instantània completa i l'historial d'observació.

Per a les regles permanents, l'agent les recupera una vegada a l'inici d'un flux de treball:

recuperar_entitats({
  "entity_type": "regla_permanent"
})

La meva instància retorna regles com "pagar sempre a Carlos en Bitcoin" i "proporcionar missatges redactats en blocs de reducció". L'agent els aplica automàticament durant la resta de la sessió.

Quan els fluxos de treball toquen fitxers (rebuts, captures de pantalla, documents), l'agent els emmagatzema al costat d'entitats de la mateixa trucada mitjançant file_path:

botiga({
  "entitats": [
    {
      "entity_type": "transacció",
      "vendor": "Amazon",
      "import": 47,99,
      "currency": "EUR"
    }
  ],
  "file_path": "/path/to/receipt.pdf",
  "idempotency_key": "amazon-order-march-9"
})

La camí d'emmagatzematge no estructurat de Neotoma gestiona el fitxer des d'allà. Els bytes en brut s'adrecen al contingut (SHA-256), de manera que el mateix fitxer no s'emmagatzema mai dues vegades. L'agent passa el fitxer tal com està mitjançant file_path (entorns locals com Cursor) o file_content (base64, per a entorns basats en web); no interpreta ni extreu dades abans d'emmagatzemar-les. De manera predeterminada, Neotoma executa automàticament la interpretació d'IA al fitxer emmagatzemat, extreu entitats estructurades i enllaça de nou a la font amb una relació EMBEDS. Tornar a emmagatzemar el mateix fitxer amb interpreta: true activa la reinterpretació sense crear un duplicat. El rebut es converteix en dades estructurades consultables amb el PDF original conservat per a la procedència. La interpretació també es pot ajornar ('interpretar: fals') per al processament per lots o la gestió de quotes, i després executar-se més tard amb una configuració diferent.

Fluxos de treball a la pràctica

Alguns fluxos de treball mostren el patró.

Triatge de correu electrònic. L'agent llegeix els correus electrònics no llegits mitjançant l'MCP de Gmail, consulta en Neotoma els registres de contactes existents i el context anterior amb cada remitent, redacta les respostes utilitzant les regles del meu estil de comunicació, emmagatzema contactes i tasques nous i arxiva els missatges processats. Una única execució de triatge pot emmagatzemar cinc contactes nous, tres tasques i una dotzena de torns de conversa.

Escriptura de publicacions al blog. L'habilitat en si viu a Neotoma com una entitat estructurada. L'agent el recupera amb retrieve_entity_snapshot. A continuació, consulta les publicacions existents per calibrar l'estil, escriu l'esborrany, emmagatzema l'entitat de publicació amb totes les metadades, genera imatges d'heroi, crea còpies compartides per a Twitter i LinkedIn, regenera la memòria cau del lloc web des de l'exportació de Neotoma i es desplega. Aquesta publicació es va escriure així.

Pagaments en Bitcoin. Pago a un contractista en Bitcoin mitjançant un servidor MCP de cartera BTC. Neotoma emmagatzema la regla permanent, el registre de contactes i l'historial de transaccions. L'agent recupera els tres, executa el pagament, emmagatzema la nova transacció amb l'enllaç de la cadena i confirma.

Processament de comentaris. Quan els provadors donen comentaris sobre la versió del desenvolupador de Neotoma, els agents extreuen entitats de comentaris estructurats, les vinculen al registre de contactes del provador, classifiquen els comentaris per cub i els avaluen en funció de les restriccions de l'etapa de llançament. Els comentaris previs es poden recuperar pel provador, per cub o per data.

Desplegament del lloc web. L'habilitat de desplegament sincronitza les edicions locals de rebaixes a Neotoma, exporta el conjunt de dades del lloc web complet, regenera la memòria cau, impulsa el repositori del lloc web i supervisa les [Accions de GitHub](https://github.com/succeeds. Si la compilació falla, l'agent llegeix els registres, soluciona el problema i torna a executar-se.

Cap a agents que corren sense mi

Cada flux de treball comença amb l'obertura d'un agent del cursor i l'escriptura d'una instrucció. Estic al corrent de cada tasca. Això està bé per a l'etapa actual, però no és l'estat final.

Estic configurant processos automatitzats perquè els agents puguin gestionar els fluxos de treball sense la meva implicació directa. Les peces ja hi són: les habilitats defineixen els passos complets del flux de treball, Neotoma emmagatzema el context i les regles, els servidors MCP proporcionen l'abast. El que falta és l'orquestració que desencadena els fluxos de treball a la programació o en resposta als esdeveniments, i una interfície d'aprovació lleugera perquè pugui revisar i autoritzar accions sense seure al meu ordinador portàtil.

L'arquitectura en capes de Neotoma està dissenyada exactament per a això. Separa tres preocupacions:

1. Capa de la veritat (Neotoma). Procedent d'esdeveniments, impulsat per reductors, determinista. Tots els agents en llegeixen. Les actualitzacions d'estat només flueixen a través d'esdeveniments de domini processats pels reductors. Cap agent muta la veritat directament.
2. Capa d'estratègia. Llegeix l'estat actual del món des de Neotoma. Avalua les prioritats, les limitacions, el risc, els compromisos i el temps. Emet decisions i ordres. Cognició pura: estat a dins, decisions fora. Sense efectes secundaris.
3. Capa d'execució. Pren ordres de la capa d'estratègia. Realitza efectes secundaris mitjançant adaptadors externs (API de correu electrònic, serveis de pagament, calendari, missatgeria). Emet esdeveniments de domini que descriuen el que va passar. Aquests esdeveniments retornen a través dels reductors per actualitzar l'estat. Efecte pur: ordres entrades, esdeveniments fora.

El bucle està tancat:

Senyals entrants (correu electrònic, WhatsApp, calendari, dades financeres)
  -> Normalització -> Estat Neotoma (registre d'esdeveniments + reductors)
  -> Marca d'estratègia (avaluar prioritats, decisions de sortida)
  -> Agents d'execució (realitzar efectes secundaris, emetre esdeveniments)
  -> Reductors -> Estat actualitzat
  -> Següent marca

Avui sóc la capa estratègica. Miro l'estat, decideixo què fer i dic a un agent que ho executi. L'arquitectura fa que aquest paper sigui substituible per programari. Un motor d'estratègia llegeix Neotoma, avalua allò que necessita atenció en funció de les regles i prioritats vigents i emet ordres als agents d'execució. Aquests agents truquen als servidors MCP, emmagatzemen els resultats i el cicle es repeteix.

L'invariant crític és que cap capa escriu directament al magatzem de dades subjacent de Neotoma. Les actualitzacions només flueixen a través d'esdeveniments de domini i reductors. Això fa que el sistema sigui auditable i reversible. Si un agent autònom pren una mala decisió, puc rastrejar l'esdeveniment que la va provocar, revertir l'actualització de l'estat i corregir la regla que la va provocar.

L'objectiu és reduir el temps diari a l'ordinador. No eliminar-lo. Passar de l'execució pràctica a la revisió i l'aprovació. Vull despertar-me amb un resum del que van gestionar els meus agents durant la nit: correus electrònics seleccionats, publicacions redactades, implementacions verificades, pagaments en cua. Vull aprovar un pagament de Bitcoin des del meu Apple Watch. Vull revisar un correu electrònic redactat al meu telèfon mentre camino i tocar per enviar. Els agents gestionen el 80% que és repetible. M'encarrego del 20% que necessita jutjar.

Aquí és on la qüestió del maquinari es posa interessant. Els telèfons i els rellotges actuals no estan dissenyats per a aquest patró d'interacció. Necessites un dispositiu optimitzat per a breus revisions i gestos d'aprovació, no per escriure o navegar.

Dels dispositius que existeixen actualment, Apple Watch se sent el més proper al factor de forma adequat: sempre al canell, visible, capaç d'interaccions senzilles amb un toc per aprovar. Però la capa de programari encara no hi és. No hi ha manera de canalitzar els resums d'agents i les sol·licituds d'aprovació al rellotge d'una manera que sembli nativa.

Aquesta podria ser una àrea per a mi per experimentar en algun moment, creant una aplicació complementària lleugera que uneixi l'estat de Neotoma a una interfície a nivell de canell. Tant si la superfície adequada acaba sent una aplicació de rellotge, un dispositiu d'IA dedicat o alguna cosa que encara no existeix, el model d'interacció és clar: els agents fan la feina, la memòria estructurada manté l'estat i l'ésser humà proporciona direcció al ritme de la intenció en lloc del ritme d'execució.

Procediment obert de la pila

La pila és privada avui en dia perquè conté la meva vida: contactes, finances, dades de salut, comunicacions personals, normes vigents sobre com porto la meva llar. Abans de poder-lo obrir de codi obert, he de desenredar-ho tot.

El camí és senzill. Les dades personals es mouen completament a Neotoma, que ja és la font de la veritat per a la majoria. Els scripts que fan referència als meus comptes i camins específics es refactoritzen per llegir-los des de la configuració. Els embolcalls del servidor MCP esdevenen genèrics. Les habilitats perden els seus supòsits codificats.

El que queda és una pila agent reutilitzable: una plantilla monorepo amb bastides de servidor MCP, un marc de regles i habilitats, integració de Neotoma per a la memòria estructurada i exemples de fluxos de treball que qualsevol pot adaptar. L'arquitectura és la part interessant. Les meves dades personals no ho són.

No tinc una línia de temps per a això. La refactorització es produeix al costat de l'ús diari. Cada vegada que toco un guió, el faig més genèric. Cada vegada que passo dades a Neotoma, les trec del repositori. La pila es fa més portàtil amb cada sessió.

Què demostra això sobre Neotoma

Vaig construir aquesta pila abans que existís Neotoma. La primera versió utilitzava fitxers plans i taules Parquet. Va funcionar fins que no.

Els modes d'error eren específics: un agent emmagatzemaria un contacte com a "Sarah Kim" en una sessió i "S. Kim" en una altra, creant duplicats sense cap manera de combinar-los. No hi havia cap procedència, així que no podia dir quin agent va escriure un camp ni quan.

Les consultes es limitaven a coincidències exactes en columnes individuals, de manera que es preguntava "quin comentari vaig rebre la setmana passada?" significava escanejar tots els fitxers manualment. De tant en tant, els registres es sobreescriuen malament o s'eliminaven completament, sense cap registre d'esdeveniments per recuperar-se. I no hi ha res vinculat entre els tipus, així que saber que una tasca relacionada amb un contacte relacionat amb una transacció em va obligar a tenir aquest gràfic al cap.

Neotoma va substituir aquesta capa. Va oferir als agents una memòria estructurada, consultable i conscient de les relacions que funciona en tots els fluxos de treball. La pila ara té 170 tipus d'entitats a Neotoma, no perquè hagi dissenyat 170 esquemes per endavant, sinó perquè els agents creen tipus d'entitats a mesura que troben nous tipus d'informació. Una nota de comentaris és diferent d'una transacció és diferent d'una regla permanent, i el sistema les gestiona totes.

Aquesta és la prova interna que fa que Neotoma sigui honest. Quan la recuperació és lenta, ho sento a cada sessió d'agent. Quan falla la resolució d'entitats, tinc contactes duplicats. Quan l'emmagatzematge no és fiable, els fluxos de treball es trenquen. Cada error i cada buit apareix en el meu treball diari abans que aparegui en el de qualsevol altre.

El problema de la memòria és universal. Tots els desenvolupadors que creen fluxos de treball d'agents colpejaran el mateix mur: agents que no recorden, no poden consultar i no poden basar-se en el treball anterior. No n'hi ha prou amb la recuperació; l'estructura i la procedència són els que fan que la memòria sigui fiable. Aquesta pila és una prova que la memòria estructurada canvia el que poden fer els agents. Neotoma és com ho faig disponible per a tothom.

La liberació del desenvolupador està oberta per a la prova. Si esteu creant fluxos de treball agents i voleu memòria estructurada a sota, aquí és per on començar.