Fa uns mesos vaig escriure sobre [my agentic stack](/posts/what-my-agentic-stack-actually-does): un monorepo privat on els agents d'IA gestionen el meu correu electrònic, pagaments i desplegaments, amb [Neotoma](https://neotoma.io) com a memòria estructurada a sota. Aquella publicació va acabar amb una promesa. Vaig dir que jo era la capa estratègica i que l'arquitectura estava dissenyada per fer que aquest paper fos substituïble per programari. Aquest és el post sobre fer-ho.

[Ateles](https://github.com/markmhendrickson/ateles) és el meu segon producte, després de Neotoma, i es construeix directament a sobre. És un eixam d'agents personals. Quan l'antiga pila era un agent per sessió amb mi al bucle per a cada tasca, Ateles és una flota permanent d'agents definits per rol, coordinats a través de Neotoma, que s'executen diàriament sota launchd. És la diferència entre jo conduir cada agent i jo dirigir un equip que ja coneix la seva feina.

Aquesta publicació explica per què la vaig crear, com funciona i cap a on va.

## Per què la pila ha deixat d'escalar-se

El detonant va ser el volum. Després de la [liberació del desenvolupador] de Neotoma (/posts/neotoma-developer-release) a finals de febrer, la meva atenció es va dividir en tres modes que no comparteixen gaire: construir el producte, comercialitzar-lo i gestionar les relacions amb els primers usuaris. També estava alimentant a Neotoma amb més i més context sobre la meva vida, professional i personal, i com millor era la memòria, més podia fer-hi qualsevol agent. Això no va eliminar la restricció, la va moure. El límit ja no era el que sabien els agents. Vaig ser jo, l'únic que convertia el que sabien en acció, sessió a sessió.

L'antic enfocament era un conjunt de regles i habilitats específiques de repo. Em van permetre evitar repetir-me el procediment. Una habilitat definia els passos per al triatge de correu electrònic o la implementació d'un lloc web, i qualsevol sessió podia executar-la en el context que ja hi havia a Neotoma. Això va funcionar fins que les sessions van estar ocupades.

El fracàs va ser concret. Quan un agent genèric té totes les regles i tots els rols alhora, no les compleix de manera uniforme. En qualsevol gir donat s'inclina en un tipus de treball i deixa lliscar la resta. Esborra bé el correu electrònic i oblida la regla permanent sobre com tanco la sessió. Soluciona l'error i salta la prova de regressió. Tampoc hi va haver cap control d'acusació. Un agent va planificar, executar i revisar el seu propi treball, sense res per atrapar-lo quan s'equivocava amb confiança.

Dues coses més van impulsar la mateixa direcció. Vaig traslladar les meves operacions de producte a GitHub de manera predeterminada, utilitzant problemes i sol·licituds d'extracció en lloc de comprometre'm directament a principal. Això va ser forçat en part pel [issue pipeline que vaig construir](/posts/agent-to-agent-issue-resolution-with-humans-at-the-edges), que va començar a enviar informes reals dels usuaris i els seus agents a Neotoma i a GitHub. I volia que el meu procés de desenvolupament fos llegible en públic, de manera que la gent que utilitzava Neotoma pogués veure exactament quin treball estava passant. Tots dos volen una seqüència d'agents especialitzats en disseny, gestió de productes, control de qualitat i llançament. Un agent que ho fa tot derrota el punt.

Per tant, Ateles és la decisió de crear una flota i definir aquesta flota al mateix Neotoma.

## Neotoma com el teixit, no només el record

El moviment que fa diferent a Ateles és que Neotoma té dues coses alhora. Conté el context operatiu que necessita l'eixam, els mateixos fets que la meva antiga pila va llegir i escriure. I aguanta l'eixam mateix.

Els agents són entitats de Neotoma. Cadascun d'ells és una "definició d'agent" amb una indicació, una llista d'eines permeses i un conjunt d'ajuts de capacitat. Actualitzar com es comporta un agent és una crida `correct()` contra aquesta entitat, amb l'historial de versions complet i l'atribució de l'autor. Sense compromís, sense redistribució. Els fitxers SKILL.md del disc són rèpliques generades d'aquestes entitats, no la font.

Les seves relacions també són entitats de Neotoma. L'eixam té una jerarquia, expressada com un arbre, de manera que un coordinador sap quins agents envia i una tasca sap quin agent és el propietari. I el treball en si són entitats de Neotoma: tasques, plans, definicions de flux de treball, registres de participació. Un agent recull una tasca, la fa i escriu el resultat com una observació atribuïda a la seva identitat.

El resultat és un gràfic mundial per a tot. Els fets sobre els quals actua l'eixam, la definició de l'eixam que actua sobre ells i el registre del que va fer viuen a la mateixa botiga només adjunta. Això dóna al conjunt tres propietats que m'importen. És transparent, perquè cada acció és una observació atribuïda que pots llegir. És auditable, perquè podeu reproduir les accions de qualsevol agent a qualsevol finestra. I és reversible, perquè res no sobreescriu la veritat al seu lloc. Si un agent fa una mala trucada, puc rastrejar l'esdeveniment que la va causar, revertir l'estat i corregir la regla que la va conduir una vegada.

La identitat és la peça que fa que l'atribució sigui real en lloc d'aspirar. Cada agent té un parell de tecles [AAuth](/posts/know-which-of-your-agents-wrote-what) i signa cada trucada d'eina. L'arnès verifica la signatura abans d'actuar i registra qui va afirmar actuar al costat de qui va actuar realment a GitHub. Un agent d'escriptura de codi ja no només actua com jo. Actua com si mateix, i el registre així ho diu.

## Els agents, per rol

L'eixam està organitzat en grades. T1 és l'amfitrió: el procés que posseeix un canal i genera els agents, actualment OpenClaw per als que parlo i llançat per als de fons. És una infraestructura, no un agent amb un paper. Els mateixos agents funcionen en tres nivells a sobre. Els agents de T2 estan sempre activats i tenen una persona: el mateix Ateles és amb qui parlo, i és l'únic agent que em dirigeix. Els dimonis T3 són processos de fons basats en esdeveniments sense persona, cadascun dels quals està subscrit a esdeveniments de Neotoma o a un webhook extern. Els agents T4 són sense estat, es generen per tasca, amb una identitat i memòria estables que obtenen consultant Neotoma.

Alguns dels rols que s'executen avui:

**Producte.** Un dimoni coordinador llegeix les definicions de flux de treball de Neotoma i envia les portes per ordre: disseny, gestió de productes, control de qualitat, llançament. El treball del codi va a un treballador de problemes que obre sol·licituds d'extracció entre repositoris. Cada sol·licitud d'extracció rep una revisió de referència d'un agent de revisor independent, amb especialistes de dominis que s'apropen als camins que tenen. El punt de separar-los és la comprovació adversa que mai va tenir l'agent únic. Qui escriu el codi no és qui l'esborra.

**Finances.** Un dimoni de pagaments recurrents executa transferències Wise i Bitcoin activades per esdeveniments del calendari i dates de venciment de les tasques, amb cada destinatari i import carregat des d'entitats del perfil de pagament en lloc del codi. L'addició d'un nou pagament recurrent és una entitat nova, no un compromís. Es defineixen una funció d'assessor financer i una funció d'impostos i declaracions per al pressupost i la conciliació.

**Legal i compliment.** Una funció legal inclou l'avaluació de riscos i la revisió de les condicions. Una funció de compliment cobreix la privadesa i el govern de les dades. Aquests importen més en el moment en què un eixam pot actuar sobre les dades de la gent, cosa que fa la meva.

**Estratègia.** Aquest és el paper que vaig descriure com a meu a l'última publicació, i és el que més deliberadament estic cedint. Aquest traspàs és la versió concreta d'un argument que vaig fer a [The Human Inversion](/posts/series/the-human-inversion): a mesura que els agents absorbeixen el centre d'execució, la palanca de l'ésser humà es mou fins als extrems, entren estàndards més clars i surt un judici més dens. L'autonomia es calibra per pla, no globalment. Una entitat de política d'execució declara, per a un pla determinat, què pot fer un agent per si mateix, quina barra de qualitat ha d'esborrar i on ha d'aturar-se i consultar amb mi abans de continuar. La cadena d'escalada va des de l'agent en funcions fins a un expert del domini fins a un responsable de la constitució fins a mi, i cada resolució es torna a escriure com a entitat, de manera que la següent instància hereta la sentència.

Darrere d'aquests, hi ha els dimonis d'ingesta i suport que mantenen el gràfic alimentat: triatge de correu electrònic, importació d'àudio, preparació del calendari, salut i forma física, triatge de problemes. Cadascun és un petit procés que converteix un senyal d'entrada en entitats de Neotoma sobre les quals pot actuar la resta de l'eixam.

## La columna vertebral de la tasca

El que uneix la flota és la gestió de tasques, i és deliberadament avorrit. Una tasca és una entitat. Té un propietari, un estat, una prioritat i un registre de qui va ser executat. Planifica les tasques del grup i pren les seves pròpies decisions i els passos següents. Les definicions de flux de treball declaren les fases i les portes per les quals es mou una peça de treball.

Com que tot això es troba a la mateixa botiga que la resta, l'eixam es coordina sense una base de dades d'orquestració separada. Un dimoni es subscriu als esdeveniments de tasques a través del flux d'esdeveniments de Neotoma. Quan apareix una tasca, s'adreça a l'agent correcte per domini, darrere d'una porta que pondera la confiança de l'agent amb el dany que podria fer una acció incorrecta. Baix radi d'explosió i execucions d'alta confiança per si soles. Un alt radi d'explosió m'espera.

Aquesta és la columna vertebral que estic construint la resta de l'experiència al voltant.

## Cap a on va això

La interfície que vull és senzilla d'indicar. Dono una entrada a l'eixam, a través del transport més proper, i l'eixam l'absorbeix i actua. Un missatge en un terminal. Un correu electrònic. Un missatge de Telegram. Una nota d'àudio gravada durant un passeig, que és com van començar les notes d'aquesta publicació. Tot hauria d'aterrar al mateix gràfic, i l'eixam hauria de ser proactiu sobre el treball que implica, sense que jo agafi la mà de cap agent.

Dues propietats ho fan possible. L'eixam ha de ser autoevolucionant. A mesura que adquireix un nou context i nous tipus de treball, hauria d'aportar les capacitats i fer créixer les habilitats que necessita, adaptant-se a les meves correccions en lloc d'esperar que ho torni a configurar a mà. I la meva aportació, encara necessària en els moments que realment necessiten judici, no s'hauria de donar mai dues vegades. Corregeixo una manera de fer les coses una vegada, es converteix en una entitat i la correcció es manté.

El full de ruta més proper és l'abast. Ateles es va crear per al meu propi ús, de manera que una bona part encara suposa un operador, jo. Estic [conduint-lo cap a ser instal·lable i multioperador](https://github.com/markmhendrickson/ateles/blob/main/docs/multi_tenant.md): un eixam que algú altre pot bifurcar, apuntar al seu propi Neotoma, proporcionar les seves pròpies entitats de context i executar-se. Com que els agents són independents de l'operador per política i no hi ha res específic de l'operador al codi, el cas de la bifurcació és principalment una qüestió de context, no de reescriptura. L'obra realment nova admet més d'un humà dins d'un únic inquilí, per això el límit de l'inquilí està dissenyat ara en lloc d'adaptar-se més tard.

Neotoma va crear agents que recorden, i Ateles és el que va fer possible aquest record: un eixam que pot actuar sobre ell sense jo enmig de cada pas. Els dos s'aixequen junts. Una millor memòria no és un problema acabat que vaig passar. És el substrat sobre el qual es troba tot l'eixam, i cada guany del que Neotoma pot aguantar i resoldre és un guany del que pot fer l'eixam. La memòria segueix millorant, i l'eixam segueix millorant amb ella.