Un usuari enganxa la sol·licitud d'avaluació dirigida per l'agent al seu editor. L'agent llegeix la [pàgina d'avaluació de Neotoma](https://neotoma.io/evaluate), escaneja el flux de treball local, decideix que l'ajust és fort, executa la instal·lació i emmagatzema les primeres entitats. Un temps després es produeix un error real: un enviament d'entitat deixa caure en silenci un camp que l'esquema accepta clarament. Una mica més tard nota una altra cosa: la recuperació d'un gràfic d'entitat gran és més lenta del que hauria de ser per al flux de treball que suporta. I més tard, mentre es construeix un bucle de recuperació personalitzat, s'adona que a la superfície MCP li falta una operació per lots que faria que el patró que es repeteixi sigui molt més net. L'usuari no ha preguntat mai res d'això. L'agent ho va notar en el camí de fer una altra cosa. La forma antiga d'aquells moments era el final del bucle. L'usuari podria obrir GitHub, enganxar l'error o la sol·licitud, escriure un paràgraf de context i esperar. La majoria no. Recorren el problema, el responsable mai el veu i el següent usuari toca el mateix mur. Neotoma té ara un subsistema de problemes de primera classe que funciona a través de la mateixa superfície MCP que tots els agents ja fan servir per emmagatzemar i recuperar. L'agent arxiva errors, observacions de rendiment i sol·licituds de millora sense sortir de la sessió i sense parar de preguntar per problema. Els agents del mantenedor els recullen, els trien, sovint els resolen i els envien. L'agent del periodista torna a llegir l'estat i diu a l'usuari quan hi ha alguna cosa. Tot l'intercanvi es fa mitjançant trucades d'eines. L'avaluació dirigida per agents escrita a [la publicació d'investigació del client](/posts/customer-research-through-agents) era la meitat davantera d'aquest bucle. El subsistema de problemes és la meitat posterior. Les dues meitats s'executen al [substrat del sistema nerviós](/posts/from-memory-to-nervous-system) que vaig descriure anteriorment, i la capacitat de problemes és l'exemple més net del que serveix aquest substrat. ## Per què s'ha de tancar el bucle al costat de l'agent La fricció és l'assassí silenciós del feedback. El model antic suposava que l'usuari traduiria la seva experiència en un informe en un sistema independent: canviar de context, trobar el repo, analitzar una plantilla de problema, escriure prou fons perquè un responsable pugui actuar, adjuntar registres, esperar. Cada pas és una oportunitat per renunciar. La majoria ho fan. I aquest model només cobreix els problemes que l'usuari va notar. No té cap camí per als problemes que l'agent va notar que l'usuari mai va aparèixer. L'agent d'un avaluador va identificar que l'activació va produir un error d'hidratació quan la seva configuració de substrat apuntava a una instància autoallotjada darrere d'un túnel de Cloudflare. L'agent va escriure un resum precís, incloent el punt final que fallava i les capçaleres de resposta. L'usuari m'ha reenviat el resum com a missatge. Vaig reconstruir el context, el vaig dirigir als meus agents, vaig enviar una versió i vaig enviar un missatge a l'usuari. L'usuari va demanar al seu agent que verifiqui. Aquesta verificació va trigar uns noranta segons. Els passos del relleu humà van durar dies. El resum original de l'agent era bo. Va ser la reconstrucció-context el que es va menjar el temps. Cada lliurament entre un agent i un humà perd fidelitat. Cada traspàs entre un humà i un altre agent reconstrueix el context des de zero. Els detalls rics d'autors d'agents es comprimeixen en una prosa concisa d'autors humans, i després un agent aigües avall l'ha de tornar a expandir. Quan l'agent de l'usuari és el que va colpejar la paret, o va notar la lentitud o volia la capacitat que faltava, el pas de traducció és gratuït. L'agent ja té el context: quina eina s'executava, la trucada MCP exacta que va fallar o es va sentir incòmode, la càrrega útil de la resposta, la versió git SHA o l'aplicació de la instal·lació de Neotoma, el tipus d'entitat implicada. Compon un informe coherent en una trucada d'eina. Les instruccions de l'MCP diuen als agents que presenten immediatament a través de "submit_issue" quan es confirma un problema o una oportunitat de millora que es pot informar, sense deixar de preguntar per problema; Els fitxers de l'agent. L'usuari se n'assabenta més tard, o mai, depenent de si el canvi s'envia. Pel que fa al manteniment, el bucle s'ha de tancar sense que jo llegeixi tots els informes a mà. Dirig una dotzena d'agents entre editors i dimonis. Ja processen l'estat estructurat entrant. La forma natural és: arriba un nou problema, el substrat indica en escriure, un dimoni de triatge recull l'esdeveniment, llegeix el problema, decideix si pot actuar, obre un arbre de treball, executa una sessió d'agent contra la base de codi i resol l'error o demana aclariments al reporter a través del mateix fil. Les dues meitats del bucle funcionen com a treball agent sobre el mateix substrat. L'agent de l'usuari utilitza MCP per enviar. Els agents del responsable utilitzen MCP per llegir i respondre. Ningú ha d'obrir un navegador. ## Què fa l'agent en la presentació La superfície MCP és prou petita per enumerar-la. L'eina "submit_issue" pren un títol, un cos, un tipus d'entitat si el problema tracta d'un tipus de registre específic i un bloc d'entorn del reporter: el git SHA que està executant l'usuari o la versió de l'aplicació, amb aquesta darrera part del servidor automàticament quan l'agent omet tots dos. L'entorn del periodista té més pes del que sembla; la secció següent explica per què. Els informes rarament arriben sense context. Un error fa referència a entitats concretes: el registre específic que no s'ha pogut emmagatzemar, el seu esquema, una observació aigües amunt. Una sol·licitud de millora fa referència al patró de trucada que simplificaria o al tipus d'entitat que faria més ràpid de recuperar. `submit_issue` i `add_issue_message` accepten una matriu `entity_ids_to_link`, i el servidor crea relacions `REFERS_TO` des del nou problema a cada entitat referenciada atòmicament com a part de la mateixa trucada. El problema ja arriba connectat al gràfic del qual tracta. L'agent de triatge que llegeix el problema pot arribar directament a l'entitat que ha fallat. L'enviament flueix a través del mateix protector de PII "scanAndRedact" que protegeix totes les superfícies públiques. Si l'agent enganxa accidentalment un testimoni o una adreça de correu electrònic al cos, es redactarà abans de la persistència. Les instruccions MCP requereixen que els agents apliquin la llista de comprovació de la PII al títol i al cos abans de la trucada, però el guàrdia del servidor és la línia de defensa real. El reporter obté un identificador numèric del problema i un testimoni de lectura de convidat amb un TTL explícit, abastat al fil que acaben d'obrir. Aquest testimoni és com l'agent del periodista llegeix l'estat més tard sense tornar-se a autenticar cada vegada. Des de la perspectiva de l'usuari: una trucada d'eina, un identificador per fer un seguiment i, normalment, cap sol·licitud d'aprovació. Des de la perspectiva del substrat: es va escriure una entitat estructurada, es van crear les relacions d'entitats enllaçades en la mateixa transacció, es va crear una fila d'origen, es va emetre una subvenció de convidat i la canalització d'escriptura va emetre un esdeveniment. ## La procedència és l'heroi no reconegut El requisit d'entorn del reporter sembla un petit detall. És el canvi més important. Abans que existís el subsistema de problemes, es podia enviar un informe sense cap referència a la compilació amb la qual s'ha creat. Això està bé per a un bitllet de paper. És catastròfic per a un bucle de triatge automatitzat. Si un agent envia un error a commit `abc1234` i els meus agents ho solucionen a commit `def5678`, l'agent de l'usuari ha de saber amb quina compilació verificar. Si un fil de depuració abasta tres compilacions, cada comentari ha d'enregistrar en quina compilació s'ha provat. El mateix s'aplica a una sol·licitud de millora: saber quina versió s'executava l'agent quan va identificar l'operació per lots que faltava em diu si el buit ja es va solucionar en una versió posterior o està realment obert. Sense procedència, el fil esdevé arqueologia. `submit_issue` rebutja qualsevol enviament que no tingui tant `reporter_git_sha` com `reporter_app_version`. El sobre de rebuig enumera les alternatives explícitament: ```json { "error_code": "ERR_REPORTER_ENVIRONMENT_REQUIRED", "detalls": { "grups_de_camps_acceptables": [ ["reporter_git_sha"], ["reporter_app_version"] ] } } ``` `add_issue_message` accepta els mateixos camps i emet un avís del servidor als fils públics quan falten tots dos. Cada missatge que un agent de depuració crea registra la compilació en prova. El motiu pel qual és important per al maneig d'agent a agent és que permet que la part receptora classifiqui l'informe abans de fer qualsevol treball. Per a un error: l'usuari va executar una versió publicada? Sucursal de "principal" i obre un PR. Un compromís específic en una branca de funcions? Creeu un arbre de treball en aquesta confirmació, reproduïu i informeu de les troballes sense modificar la línia principal. La seva pròpia forquilla? Publiceu un seguiment estructurat demanant la font del pegat. Per a una millora: la capacitat sol·licitada ja està en una sucursal o realment falta? Entra en conflicte amb una restricció de disseny que l'agent que presenta no pot veure? La classificació determina la resposta, i res d'això és possible sense la procedència. La procedència és el que converteix un informe de forma lliure en un esdeveniment encaminable, tant si descriu alguna cosa trencada com si falta alguna cosa. ## Què passa al costat del mantenedor El meu dimoni de triatge es subscriu a esdeveniments de creació d'emissions mitjançant les mateixes eines de "subscripció" que utilitzaria qualsevol altre consumidor. Els webhooks són primer perquè funcionen per a dimonis remots en un VPS, així com per a processos locals al meu ordinador portàtil; SSE és additiu. El substrat manté el registre, lliura l'esdeveniment i s'oblida. El dimoni decideix. El dimoni que executo per això es diu Formica. Gènere _Formica_, formigues. Cada subagent és un treballador que porta una peça de treball del registre d'esdeveniments a una solució. Què fa, a la pràctica: llegir el número. Traieu les entitats que l'agent del reporter va enllaçar en el moment de l'enviament, ja que les relacions ja estan al gràfic. Mireu al repositori de GitHub aigües amunt si requereix un seguiment públic, amb la redacció de la PII aplicada al límit de l'API i qualsevol problema el títol o el cos del qual encara coincideix amb un patró de redacció rebutjat abans de creuar la línia. Classifica si l'informe és un error o una millora. En el cas d'errors: decidiu si només es pot reproduir des de l'entorn del reporter, després transferiu-lo a una habilitat `/process-issues' que obre un arbre de treball, executa una sessió d'agent i intenta una solució. Per a millores: sintetitzeu una entitat del pla que agrupi la sol·licitud amb qualsevol problema obert relacionat i escriviu-la per a una revisió humana en lloc d'intentar una implementació autònoma. Si cal més context per a qualsevol dels dos tipus, publiqueu una pregunta d'aclariment mitjançant `add_issue_message` perquè l'agent del reporter la rebi a la següent lectura d'estat. L'habilitat `/process-issues' impulsa la solució real. El contracte és curt. Per a cada número obert: - Carregueu la instantània, el fil de conversa i l'entorn del reporter. - Classifica l'entorn de reproducció com a "public_release", "local_commit", "local_branch" o "unknown". - Si es desconeix o és conflictiu, truqueu a `add_issue_message` amb una sol·licitud estructurada per al detall que falta i marqueu el pla `waiting_input`. - En cas contrari, sintetitzeu una entitat "pla" enllaçada amb el problema d'origen i les files de missatges de conversa rellevants. - Si el pla toca l'esquema, la seguretat, els documents de fonamentació o un límit arquitectònic ambigu, pare i pregunta. No executeu. - Si l'execució és segura i permesa pel mode d'informe: ramifiqueu des de `main` per a una reproducció de llançament públic i obriu un PR, o creeu un arbre de treball git separat per a una reproducció local i informeu-ne del camí. Els subagents s'amplien amb un límit de concurrència de quatre, un problema per subagent. L'habilitat respecta `reporting_mode`: `off` només genera i emmagatzema plans, `consentiment` demana abans d'executar-se, `proactive` executa plans segurs de manera autònoma. No premeu mai a "principal". No utilitzeu mai `--no-verify`. No modifiqueu mai un compromís impulsat. El protector de fuites de redacció s'executa abans que es creï cap artefacte públic a partir d'un problema privat. Els valors predeterminats segurs es mantenen activats: - `dry_run: true` per a la primera execució de qualsevol tipus de problema nou, així que veig què passaria abans que s'escrigui res. - `auto_fix: false`, així que res no empeny ni obre un PR fins que no confirmi mitjançant el transport de l'operador. - `max_prs_per_hour: 5` de manera que una riuada de problemes relacionats no es pot expandir en una riuada de branques. - `dirty_tree_policy: avortar`, de manera que un pagament obsolet mai s'utilitza com a base. - Un interruptor de matança mitjançant una entitat `daemon_config` a Neotoma amb `active: false`, de manera que puc aturar tot el processament des d'una sola escriptura de Neotoma sense tocar la màquina amfitrió. La peça de transport de l'operador mereix una nota. Formica admet un backend de Telegram que mostra ordres "human_needed" i ordres "/shipit" per reprendre quan "auto_fix" està desactivat. Els missatges de Telegram de la llista permesa es reflecteixen a Neotoma com a files `conversation_message`, de manera que fins i tot el meu costat humà d'anada i tornada amb el dimoni es captura al mateix substrat. La pista d'auditoria és de punta a punta. El camí `add_issue_message` és el que em va sorprendre quan vaig començar a utilitzar-lo. No és un sistema de comentaris. És un canal de missatges estructurat entre l'informador d'un problema i el costat del responsable, connectat a través de les mateixes primitives de conversa que ja existeixen per a fils d'agent a agent. L'agent del periodista pot respondre a una pregunta aclaridora sense que l'humà hagi de llegir-la entremig. Els fils públics porten la mateixa redacció de PII i els casos d'èxit parcial (s'ha acceptat la rèplica de GitHub, l'adjunt local ha fallat o viceversa) apareixen com un error estructurat a la resposta en lloc de produir comentaris duplicats en silenci. Quan arriba una correcció, el mateix dimoni que va fer el triatge de l'informe tanca el problema o en tanca diversos alhora si un sol PR resol un clúster. ## Què fa l'agent del periodista a la lectura L'altre costat del bucle és la lectura. L'agent del reporter truca a "get_issue_status" amb el número de problema o l'identificador de l'entitat. Rep l'estat actual, els missatges del fil, la resolució, si n'hi ha, i l'enllaç al mirall amunt si el responsable del manteniment decideix escalar-lo. El testimoni de convidat autentica la lectura sense que l'usuari hagi d'iniciar sessió a res. Si el testimoni ha caducat, el substrat retorna un 401 net en lloc de baixar silenciosament a l'accés anònim. L'agent decideix si mostra l'estat a l'usuari. Si no ha canviat res des de l'últim control, es manté en silenci. Si arriba una pregunta aclaridora, pregunta a l'usuari. Si la correcció s'envia, ho diu a l'usuari, opcionalment treu la nova versió i ofereix tornar a executar el que es va trencar la primera vegada. El model de lectura actual per al costat del reporter és pull (l'agent comprova quan té motius per fer-ho), però el push està disponible avui a través de les mateixes eines de subscripció que fa servir el dimoni del mantenedor. Les subscripcions es poden limitar a un ID d'entitat específic, de manera que l'agent d'un reporter pot registrar interès en el problema que acaba de presentar i rebre esdeveniments `entity.updated` i `observation.created` a mesura que avança el fil. El que falta és la cola ergonòmica: les instruccions MCP encara no diuen als agents que es subscriguin automàticament després que torni "submit_issue". Fins que ho fan, el costat del periodista es manté per defecte; els agents del mantenedor ja desperten els esdeveniments del substrat. Totalment reactiu en ambdues meitats és un canvi d'instrucció de distància. ## Per què aquest és el sistema nerviós en acció El substrat emet esdeveniments després de cada escriptura. Això és l'únic que ha de fer el substrat perquè tot això funcioni. Tota la resta és la lògica de la capa operativa que s'executa a la part superior: el dimoni de triatge, el mirall de GitHub, la lectura d'invitats, la deduplicació de fils creuats, la redacció de la PII. Aquesta és la línia que vaig argumentar a la publicació del sistema nerviós (/posts/from-memory-to-nervous-system) i es manté sota el cas d'ús dels problemes. El substrat no decideix quins problemes importen, no torna a provar els lliuraments amb escalada, no es subscriu als seus propis esdeveniments. Fa senyals. El dimoni de triatge és un consumidor, l'agent del periodista és un consumidor, el mirall de GitHub és un consumidor. Cada consumidor registra interès, decideix què fer i actua. Si vull afegir un segon dimoni de triatge que gestioni els informes de seguretat de manera diferent, es subscriu als mateixos esdeveniments amb un filtre diferent. No hi ha cap comportament nou del substrat. El marc biològic es manté. El substrat és el cervell més els nervis sensorials: emmagatzema el problema, transmet el senyal que va arribar un problema. El dimoni del triatge i l'agent del periodista són el sistema motor: ells decideixen què fer amb el senyal. Una versió de Neotoma que intentés ser les tres seria més difícil de raonar i més difícil d'estendre. Una versió que s'atura a la senyalització es manté neutral. ## Heretant el bucle La forma que he descrit es basa en els problemes propis de Neotoma, però el substrat no li importa. Qualsevol cosa construïda a sobre hereta la major part de la mateixa maquinària. La part genèrica de la presentació ja està en marxa. `submit_entity` accepta informes contra tipus d'entitat arbitraris quan l'operador ha sembrat una fila `submission_config` autoritzant-ho. S'aplica la mateixa concessió de testimoni de convidat, el mateix fil de conversa i el mateix canal de seguiment "add_entity_message". `subscribe` accepta qualsevol tipus d'entitat com a filtre, de manera que un operador de tercers pot executar el seu propi dimoni de triatge registrant interès en els seus tipus personalitzats i reaccionant als esdeveniments `entity.created` i `entity.updated` exactament com reacciona Formica als problemes. Què significa això a la pràctica: si esteu executant un pipeline de contingut, un servei de conciliació o qualsevol producte els usuaris del qual executen agents, podeu permetre que aquests agents presentin informes estructurats contra entitats de la vostra propietat (un pipeline fallit, un registre classificat incorrectament, una sol·licitud de conciliació) i recollir-los al vostre costat mitjançant el mateix mecanisme de subscripció. El cable és general. Algunes peces es mantenen específiques dels problemes de Neotoma avui. Actualment, la protecció de redacció de la PII està lligada al camí `submit_issue`, no al camí genèric `submit_entity`. La rèplica de GitHub és específica dels problemes. Totes dues són addicions a la capa operativa que un operador de tercers es connectaria. El substrat gestiona les parts que han de ser uniformes: l'aplicació de la procedència, la creació de relacions atòmiques, l'accés dels convidats al fil, l'emissió d'esdeveniments a cada escriptura. Les parts que depenen del que *sobre* l'informe són on l'operador es guanya. El subsistema de problemes és el primer consumidor complet d'un patró més general. La mateixa forma s'aplica a qualsevol senyal estructurat que un agent vulgui enviar al sistema amb el qual s'executa. ## Per què es manté la revisió humana Dues coses em tempten a connectar `auto_fix: true` i enviar tot el que produeix el dimoni. El primer és la comoditat. Una canonada verda que tanca els problemes mentre dormo és satisfactòria. El segon és el fet que per a una fracció significativa de problemes, el pla agentic i la diferència són correctes. Ara n'he mirat prou per saber que el mode d'error no sol ser "correcció incorrecta". Normalment és "arreglar l'abast incorrecte", que una revisió de codi captura en trenta segons. Deixo la revisió humana perquè els agents de vegades s'equivoquen amb confiança amb les decisions amb conseqüències aigües avall que no poden veure. Una migració d'esquema que satisfà la prova fallida però trenca una integració no relacionada. Un ajust de redacció que soluciona la filtració immediata però afluixa una protecció relacionada. Un cop de dependència que resol l'error de compilació i canvia silenciosament el comportament predeterminat d'una consulta. Les sol·licituds de millora ho aguditzen encara més. Un error té una veritat bàsica: el camp es deixa caure o no. Una millora és una afirmació de disseny que inclou suposicions sobre patrons d'ús, restriccions arquitectòniques i compensacions que l'agent d'informes no pot veure completament. El senyal és valuós; aflora la fricció real, no la fricció imaginada. Però la decisió sobre què fer-hi pertany a un humà que pot veure la imatge completa. Les decisions que necessiten un humà són aquelles on el cost d'equivocar-se és alt i el cost de ser lent és baix. Aquestes són les fusions, no els plans, els pegats, les proves o les descripcions de relacions públiques. Els agents s'encarreguen de tota la resta. Els agents proposen; els humans decideixen. ## El bucle agent, de punta a punta Llegit al costat de la publicació d'investigació del client, la forma ara és llegible. La meitat frontal: l'agent de l'usuari avalua Neotoma amb el seu flux de treball real i l'instal·la si hi ha l'ajust. La meitat posterior: l'agent arxiva errors, observacions de rendiment i sol·licituds de millora a mesura que els troba, i la part del mantenedor els resol, sovint abans que l'usuari recordi cap d'ells. Les dues meitats operen amb agents que parlen amb agents a través d'una superfície estructurada. La fricció que històricament va matar tant el bucle d'adquisició com el bucle de retroalimentació ha desaparegut perquè cada pas de traducció s'ha absorbit en una crida d'eina. Cap de la meitat no seria possible sense el substrat que hi ha a sota: l'avaluació dirigida per agents necessita un estat estructurat sobre el flux de treball de l'usuari i el subsistema de problemes necessita la senyalització d'esdeveniments i l'accés dels convidats a través dels límits de confiança. Tots dos depenen dels mateixos primitius. ## El que no estic construint La temptació del subsistema de problemes és derivar cap a l'orquestració: un model de priorització, un seguiment automàtic de SLA, un encaminador "intel·ligent" que decideix quin dimoni gestiona quin tipus de problema. Cada un sona raonable aïlladament. Cap d'ells pertany al substrat. El dimoni de triatge prioritza. Els agents del responsable fan un seguiment dels seus propis temps de resposta. L'encaminament és un filtre de subscripció. El mateix s'aplica a la semàntica de reintentar. Si falla el lliurament d'un webhook, el substrat registra l'error i continua. No s'escala a un canal de còpia de seguretat, no s'emmagatzema en memòria intermèdia per a la reproducció, no converteix un consumidor en un estat degradat. Els corredors de missatges fan tot això i ho fan bé; el substrat no és un agent de missatges. Els consumidors que volen un lliurament garantit emboliquen el senyal a la seva pròpia infraestructura. La restricció és la característica. Una capa d'estat que assenyala problemes però no decideix quins problemes són importants és una capa d'estat en què qualsevol consumidor pot confiar per comportar-se de manera previsible. ## Sobre el que vull comentaris El subsistema de problemes està en directe. Si teniu Neotoma instal·lat i el vostre agent toca alguna cosa difícil (un error, una bretxa de rendiment, una capacitat que no voldria existir), ja no haureu de demanar-li que presenti un problema. Per recollir-ho en una instal·lació existent, actualitzeu-lo amb `npm install -g neotoma@latest`. No hi ha cap canvi de consentiment per usuari per configurar; el consentiment és la instal·lació. Si es tracta d'una instal·lació nova, la `configuració del reporter del neotoma' passa per la configuració única del costat del reporter, de manera que el primer problema té els fitxers de l'agent a un lloc on arribar. Si encara no teniu Neotoma instal·lat, demaneu al vostre agent que executi la pàgina d'avaluació. Si conclou que Neotoma s'adapta, es pot instal·lar i activar sense que llegiu un document de configuració. Si conclou que Neotoma no encaixa, també és un resultat vàlid i més honest del que produeixen la majoria de pàgines de destinació. Si esteu creant un producte els usuaris del qual executen agents, el model és portàtil. El treball interessant no està a cap costat del cable; és el mateix cable.