Un usuario pega el mensaje de evaluación dirigido por el agente en su editor. El agente lee la [página de evaluación de Neotoma](https://neotoma.io/evaluate), escanea el flujo de trabajo local, decide que el ajuste es sólido, ejecuta la instalación y almacena las primeras entidades. Algún tiempo después, se produce un error real: el envío de una entidad elimina silenciosamente un campo que el esquema acepta claramente. Un poco más tarde, nota algo más: la recuperación en un gráfico de entidad grande es más lenta de lo que debería ser para el flujo de trabajo que admite. Y más tarde aún, mientras construye un bucle de recuperación personalizado, se da cuenta de que a la superficie MCP le falta una operación por lotes que haría que el patrón que sigue repitiendo sea mucho más limpio. El usuario nunca preguntó sobre nada de esto. El agente lo notó mientras se dirigía a hacer otra cosa. La vieja forma de esos momentos fue el final del ciclo. El usuario podría abrir GitHub, pegar el error o la solicitud, escribir un párrafo de contexto y esperar. La mayoría no lo hace. Evitan el problema, el mantenedor nunca lo ve y el siguiente usuario se topa con el mismo muro. Neotoma ahora tiene un subsistema de problemas de primera clase que opera a través de la misma superficie MCP que cada agente ya usa para almacenar y recuperar. El agente presenta errores, observaciones de rendimiento y solicitudes de mejora sin abandonar la sesión y sin detenerse a preguntar por problema. Los agentes del mantenedor los recogen, los clasifican, a menudo los resuelven y los envían. El agente del reportero lee el estado y le avisa al usuario cuando algo aterriza. Todo el intercambio se realiza mediante llamadas a herramientas. La evaluación dirigida por agentes escrita en [la publicación de investigación de clientes](/posts/customer-research-through-agents) fue la primera mitad de este ciclo. El subsistema de problemas es la mitad posterior. Ambas mitades se ejecutan en el [sustrato del sistema nervioso](/posts/from-memory-to-nervous-system) que describí anteriormente, y la capacidad de los problemas es el ejemplo más claro hasta ahora de para qué sirve ese sustrato. ## Por qué el ciclo tiene que cerrarse en el lado del agente La fricción es la asesina silenciosa de la retroalimentación. El modelo antiguo suponía que el usuario traduciría su experiencia en un informe en un sistema separado: cambiaría de contexto, buscaría el repositorio, analizaría una plantilla de problema, escribiría suficientes antecedentes para que un mantenedor pudiera actuar, adjuntaría registros, esperaría. Cada paso es una oportunidad para rendirse. La mayoría lo hace. Y ese modelo sólo cubre los problemas que el usuario notó. No tiene ninguna ruta para los problemas que el agente notó y que el usuario nunca surgió. El agente de un evaluador identificó que la activación produjo un error de hidratación cuando su configuración de sustrato apuntaba a una instancia autohospedada detrás de un túnel de Cloudflare. El agente escribió un resumen preciso, incluido el punto final defectuoso y los encabezados de respuesta. El usuario me envió el resumen como mensaje. Reconstruí el contexto, lo envié a mis agentes, envié una versión y le envié un mensaje al usuario. El usuario pidió a su agente que lo verificara. Esa verificación tomó unos noventa segundos. Los pasos de relevo humano tomaron días. El resumen original del agente era bueno. Fue el contexto de reconstrucción lo que consumió el tiempo. Cada traspaso entre un agente y un humano pierde fidelidad. Cada traspaso entre un humano y otro agente reconstruye el contexto desde cero. Los ricos detalles escritos por agentes se comprimen en una prosa concisa escrita por humanos, y luego un agente posterior tiene que expandirla nuevamente. Cuando el agente del usuario es el que chocó contra la pared, o notó la lentitud, o quería la capacidad faltante, el paso de traducción es gratuito. El agente ya tiene el contexto: en qué herramienta se estaba ejecutando, la llamada MCP exacta que falló o se sintió incómoda, la carga útil de respuesta, el git SHA o la versión de la aplicación de la instalación de Neotoma, el tipo de entidad involucrada. Redacta un informe coherente en una sola llamada de herramienta. Las instrucciones de MCP les dicen a los agentes que presenten su solicitud a través de `submit_issue` inmediatamente cuando se confirma un problema reportable u oportunidad de mejora, sin detenerse a preguntar por problema: el mensaje por problema no agrega información nueva e interrumpe lo que el usuario estaba haciendo. El agente archiva. El usuario se entera más tarde, o nunca, dependiendo de si el cambio se envía alguna vez. Por parte del mantenedor, el ciclo tiene que cerrarse sin que yo lea cada informe a mano. Dirijo alrededor de una docena de agentes entre editores y demonios. Ya procesan el estado estructurado entrante. La forma natural es: llega un nuevo problema, el sustrato señala la escritura, un demonio de clasificación recoge el evento, lee el problema, decide si puede actuar, abre un árbol de trabajo, ejecuta una sesión de agente contra el código base y resuelve el error o pide una aclaración al reportero a través del mismo hilo. Ambas mitades del bucle discurren como trabajo agente sobre el mismo sustrato. El agente del usuario utiliza MCP para enviar. Los agentes del mantenedor utilizan MCP para leer y responder. Nadie tiene que abrir un navegador. ## Qué hace el agente al enviar La superficie de MCP es lo suficientemente pequeña como para enumerarla. La herramienta `submit_issue` toma un título, un cuerpo, un tipo de entidad si el problema se trata de un tipo específico de registro y un bloque de entorno de reportero: el git SHA que el usuario está ejecutando o la versión de la aplicación, y este último se completa automáticamente en el lado del servidor cuando el agente omite ambos. El entorno del periodista tiene más peso de lo que parece; la siguiente sección explica por qué. Los informes rara vez llegan sin contexto. Un error hace referencia a entidades concretas: el registro específico que no se pudo almacenar, su esquema, una observación ascendente. Una solicitud de mejora hace referencia al patrón de llamada que simplificaría o al tipo de entidad cuya recuperación sería más rápida. `submit_issue` y `add_issue_message` aceptan una matriz `entity_ids_to_link`, y el servidor crea relaciones `REFERS_TO` desde el nuevo problema a cada entidad referenciada de forma atómica como parte de la misma llamada. El problema ya está incluido en el gráfico del que trata. El agente de clasificación que lee el problema puede ir directamente a la entidad que falló. La presentación fluye a través de la misma protección de PII `scanAndRedact` que protege cada superficie pública. Si el agente pega accidentalmente un token o una dirección de correo electrónico en el cuerpo, se redacta antes de la persistencia. Las instrucciones del MCP requieren que los agentes apliquen la lista de verificación de PII al título y al cuerpo antes de la llamada, pero la guardia del lado del servidor es la línea de defensa real. El reportero obtiene un identificador de problema numérico y un token de lectura de invitado con un TTL explícito, con alcance en el hilo que acaba de abrir. Ese token es la forma en que el agente del reportero lee el estado más tarde sin volver a autenticarse cada vez. Desde la perspectiva del usuario: una llamada a una herramienta, un identificador para rastrear y, por lo general, ningún mensaje de aprobación. Desde la perspectiva del sustrato: se escribió una entidad estructurada, las relaciones de entidad vinculada se crearon en la misma transacción, se creó una fila de origen, se emitió una concesión de invitado y la canalización de escritura emitió un evento. ## La procedencia es el héroe anónimo El requisito del entorno del reportero parece un pequeño detalle. Es el cambio más importante. Antes de que existiera el subsistema de problemas, se podía enviar un informe sin hacer referencia a la compilación en la que se creó. Eso está bien para un boleto de papel. Es catastrófico para un circuito de clasificación automatizado. Si un agente envía un error en el compromiso "abc1234" y mis agentes lo solucionan en el compromiso "def5678", el agente del usuario debe saber con qué compilación verificar. Si un hilo de depuración abarca tres compilaciones, cada comentario debe registrar en qué compilación se probó. Lo mismo se aplica a una solicitud de mejora: saber qué versión estaba ejecutando el agente cuando identificó la operación por lotes faltante me dice si la brecha ya se solucionó en una compilación posterior o si está realmente abierta. Sin procedencia, el hilo conductor se convierte en arqueología. `submit_issue` rechaza cualquier envío que carezca de `reporter_git_sha` y `reporter_app_version`. El sobre de rechazo enumera las alternativas explícitamente: ```json { "error_code": "ERR_REPORTER_ENVIRONMENT_REQUIRED", "detalles": { "grupos_de_campos_aceptables": [ ["reportero_git_sha"], ["reporter_app_version"] ] } } ``` `add_issue_message` acepta los mismos campos y emite una advertencia del servidor en los hilos públicos cuando faltan ambos. Cada mensaje que escribe un agente de depuración registra la compilación bajo prueba. La razón por la que esto es importante para el manejo de agente a agente es que permite que el lado receptor clasifique el informe antes de realizar cualquier trabajo. Para un error: ¿el usuario ejecutó una versión publicada? Bifurca desde "principal" y abre un PR. ¿Un compromiso específico en una rama característica? Cree un árbol de trabajo en ese compromiso, reproduzca e informe los hallazgos sin modificar la línea principal. ¿Su propio tenedor? Publique un seguimiento estructurado solicitando la fuente del parche. Para mejorar: ¿la capacidad solicitada ya está en una sucursal o realmente falta? ¿Entra en conflicto con una restricción de diseño que el agente que la presenta no puede ver? La clasificación determina la respuesta, y nada de ella es posible sin su procedencia. La procedencia es lo que convierte un informe de formato libre en un evento enrutable, ya sea que describa algo roto o faltante. ## ¿Qué sucede en el lado del mantenedor? Mi demonio de clasificación se suscribe a eventos de creación de problemas a través de las mismas herramientas de "suscripción" que usaría cualquier otro consumidor. Los webhooks son lo primero porque funcionan para demonios remotos en un VPS, así como para procesos locales en mi computadora portátil; La ESS es aditiva. El sustrato mantiene el registro, entrega el evento y olvida. El demonio decide. El demonio que ejecuto para esto se llama Formica. Género _Formica_, hormigas. Cada subagente es un trabajador que lleva una parte del trabajo desde el registro de eventos hasta una solución. Lo que hace, en la práctica: leer el número. Extraiga las entidades que el agente del reportero vinculó en el momento del envío, ya que las relaciones ya están en el gráfico. Refleje el repositorio de GitHub ascendente si garantiza un seguimiento público, con la redacción de PII aplicada en el límite de la API y cualquier problema cuyo título o cuerpo aún coincida con un patrón de redacción rechazado antes de cruzar la línea. Clasifique si el informe es un error o una mejora. Para errores: decida si es reproducible únicamente desde el entorno del reportero, luego transfiéralo a una habilidad `/process-issues` que abre un árbol de trabajo, ejecuta una sesión de agente e intenta solucionarlo. Para mejorar: sintetice una entidad de plan que agregue la solicitud con cualquier problema abierto relacionado y expóngala para revisión humana en lugar de intentar una implementación autónoma. Si se necesita más contexto para cualquiera de los tipos, publique una pregunta aclaratoria a través de `add_issue_message` para que el agente del periodista la reciba en la siguiente lectura de estado. La habilidad `/process-issues` impulsa la solución real. El contrato es corto. Para cada asunto abierto: - Cargue la instantánea, el hilo de conversación y el entorno del reportero. - Clasificar el entorno de reproducción como `public_release`, `local_commit`, `local_branch` o `unknown`. - Si se desconoce o hay conflicto, llame a `add_issue_message` con una solicitud estructurada para los detalles que faltan y marque el plan como `awaiting_input`. - De lo contrario, sintetice una entidad de "plan" vinculada al problema de origen y las filas de mensajes de conversación relevantes. - Si el plan toca el esquema, la seguridad, los documentos de cimentación o un límite arquitectónico ambiguo, deténgase y pregunte. No ejecutar. - Si la ejecución es segura y está permitida por el modo de informe: bifurque desde `main` para una reproducción de lanzamiento público y abra un PR, o cree un árbol de trabajo git separado para una reproducción local e informe la ruta. Los subagentes se distribuyen en abanico con un límite de simultaneidad de cuatro, un problema por subagente. La habilidad respeta el `reporting_mode`: `off` genera y almacena planes únicamente, `consent` pregunta antes de ejecutar, `proactive` ejecuta planes seguros de forma autónoma. Nunca presione a "principal". Nunca utilice `--no-verify`. Nunca modifique una confirmación forzada. La protección contra fugas de redacción se ejecuta antes de que se cree cualquier artefacto público a partir de un problema privado. Los valores predeterminados seguros permanecen activados: - `dry_run: true` para la primera ejecución de cualquier tipo de problema nuevo para ver qué sucedería antes de que se escriba algo. - `auto_fix: false` para que nada presione ni abra un PR hasta que lo confirme a través del transporte del operador. - `max_prs_per_hour: 5` para que una avalancha de problemas relacionados no pueda convertirse en una avalancha de ramas. - `dirty_tree_policy: abort` para que un pago obsoleto nunca se utilice como base. - Un interruptor de apagado a través de una entidad `daemon_config` en Neotoma con `active: false`, para poder pausar todo el procesamiento desde una única escritura de Neotoma sin tocar la máquina host. La pieza de transporte del operador merece una nota. Formica admite un backend de Telegram que muestra transferencias "human_needed" y comandos "/shipit" para reanudar cuando "auto_fix" está desactivado. Los mensajes de Telegram incluidos en la lista permitida se reflejan en Neotoma como filas de "mensaje_conversación", por lo que incluso mi lado humano de ida y vuelta con el demonio se captura en el mismo sustrato. La pista de auditoría es de principio a fin. La ruta `add_issue_message` es la que me sorprendió cuando comencé a usarla. No es un sistema de comentarios. Es un canal de mensajes estructurado entre el reportero de un problema y el mantenedor, conectado a través de las mismas primitivas de conversación que ya existen para los hilos de agente a agente. El agente del periodista puede responder a una pregunta aclaratoria sin que el humano tenga que leerla en el medio. Los hilos públicos llevan la misma redacción de PII, y los casos de éxito parcial (se acepta el espejo de GitHub, el anexo local falla o viceversa) aparecen como un error estructurado en la respuesta en lugar de producir silenciosamente comentarios duplicados. Cuando llega una solución, el mismo demonio que clasifica el informe cierra el problema o cierra varios a la vez si un solo PR resolvió un clúster. ## Qué hace el agente del periodista en la relectura El otro lado del bucle es la lectura. El agente del reportero llama a `get_issue_status` con el número de problema o ID de entidad. Recibe el estado actual, los mensajes en el hilo, la resolución, si la hay, y el enlace al espejo ascendente si el lado del mantenedor decide escalarlo. El token de invitado autentica la lectura sin que el usuario tenga que iniciar sesión en nada. Si el token ha caducado, el sustrato devuelve un 401 limpio en lugar de degradar silenciosamente a acceso anónimo. El agente decide si muestra el estado al usuario. Si nada ha cambiado desde la última comprobación, permanece en silencio. Si llega una pregunta aclaratoria, la pregunta al usuario. Si se envió la solución, se lo informa al usuario, opcionalmente extrae la nueva versión y ofrece volver a ejecutar lo que se rompió la primera vez. El modelo de lectura actual para el lado del reportero es pull (el agente verifica cuando tiene motivos para hacerlo), pero el push está disponible hoy a través de las mismas herramientas de suscripción que usa el demonio del mantenedor. Las suscripciones pueden limitarse a una ID de entidad específica, de modo que el agente de un reportero pueda registrar interés en el problema que acaba de presentar y recibir eventos `entity.updated` y `observation.created` a medida que avanza el hilo. Lo que falta es el pegamento ergonómico: las instrucciones de MCP aún no les dicen a los agentes que se suscriban automáticamente después de que regrese "submit_issue". Hasta que lo hagan, el lado de los reporteros seguirá tirando por defecto; Los agentes del mantenedor ya se despiertan con los eventos del sustrato. Totalmente reactivo en ambas mitades está a un cambio de instrucción de distancia. ## ¿Por qué este es el sistema nervioso en acción? El sustrato emite eventos después de cada escritura. Eso es lo único que tiene que hacer el sustrato para que todo esto funcione. Todo lo demás es lógica de capa operativa que se ejecuta en la parte superior: el demonio de clasificación, el espejo de GitHub, la lectura de invitados, la deduplicación entre subprocesos, la redacción de PII. Esta es la línea que [defendí en la publicación sobre el sistema nervioso](/posts/from-memory-to-nervous-system) y se mantiene en el caso de uso de problemas. El sustrato no decide qué temas importan, no vuelve a intentar entregas con escalamiento, no se suscribe a sus propios eventos. Da señales. El demonio de clasificación es un consumidor, el agente del reportero es un consumidor, el espejo de GitHub es un consumidor. Cada consumidor registra interés, decide qué hacer y actúa. Si quiero agregar un segundo demonio de clasificación que maneje los informes de seguridad de manera diferente, se suscribe a los mismos eventos con un filtro diferente. Sin comportamiento de sustrato nuevo. El marco biológico se mantiene. El sustrato es el cerebro más los nervios sensoriales: almacena el problema, transmite la señal de que llegó un problema. El demonio de clasificación y el agente del reportero son el sistema motor: deciden qué hacer con la señal. Una versión de Neotoma que intentara ser los tres sería más difícil de razonar y de ampliar. Una versión que se detiene en la señalización permanece neutral. ## Heredando el bucle La forma que he descrito se basa en los propios problemas de Neotoma, pero al sustrato no le importa. Todo lo que se construya encima hereda la mayor parte de la misma maquinaria. La parte genérica de presentación ya está implementada. `submit_entity` acepta informes contra tipos de entidades arbitrarias cuando el operador ha iniciado una fila `submission_config` que lo autoriza. Se aplica la misma concesión de token de invitado, el mismo hilo de conversación y el mismo canal de seguimiento `add_entity_message`. `subscribe` acepta cualquier tipo de entidad como filtro, por lo que un operador externo puede ejecutar su propio demonio de clasificación registrando interés en sus tipos personalizados y reaccionando a los eventos `entity.created` y `entity.updated` exactamente de la misma manera que Formica reacciona a los problemas. Lo que esto significa en la práctica: si está ejecutando un canal de contenido, un servicio de conciliación o cualquier producto cuyos usuarios ejecuten agentes, puede permitir que esos agentes presenten informes estructurados contra entidades de su propiedad (una ejecución de canal fallida, un registro mal clasificado, una solicitud de conciliación) y recogerlos de su lado a través del mismo mecanismo de suscripción. El cable es general. Algunas piezas siguen siendo específicas de los problemas actuales de Neotoma. La protección de redacción de PII está actualmente vinculada a la ruta `submit_issue`, no a la ruta genérica `submit_entity`. La duplicación de GitHub es específica de cada problema. Ambas son adiciones de capa operativa que un operador externo cablearía él mismo. El sustrato maneja las partes que tienen que ser uniformes: aplicación de procedencia, creación de relaciones atómicas, acceso de invitados al hilo, emisión de eventos en cada escritura. Las partes que dependen de lo que *trata* el informe son donde el operador se gana la vida. El subsistema de emisiones es el primer consumidor completo de un patrón más general. La misma forma se aplica a cualquier señal estructurada que un agente quiera enviar al sistema contra el que se está ejecutando. ## Por qué permanece la revisión humana Dos cosas me tientan a conectar `auto_fix: true` y enviar todo lo que produce el demonio. La primera es la conveniencia. Un conducto verde que soluciona problemas mientras duermo es satisfactorio. El segundo es el hecho de que, para una fracción significativa de problemas, el plan agente y la diferenciación son correctos. Ya he visto suficientes para saber que el modo de falla no suele ser una "solución incorrecta". Por lo general, se trata de una "reparación para el alcance incorrecto", que una revisión del código detecta en treinta segundos. Dejo la revisión humana porque en ocasiones los agentes se equivocan con confianza en decisiones con consecuencias posteriores que no pueden ver. Una migración de esquema que satisface la prueba fallida pero rompe una integración no relacionada. Un ajuste de redacción que soluciona la filtración inmediata pero afloja una guardia relacionada. Un aumento de dependencia que resuelve el error de compilación y cambia silenciosamente el comportamiento predeterminado de una consulta. Las solicitudes de mejora agudizan esto aún más. Un error tiene una verdad fundamental: o el campo se elimina o no. Una mejora es una afirmación de diseño que conlleva suposiciones sobre patrones de uso, limitaciones arquitectónicas y compensaciones que el agente informador no puede ver en su totalidad. La señal es valiosa; emerge una fricción real, no una fricción imaginada. Pero la decisión sobre qué hacer con él pertenece a un ser humano que puede ver el panorama completo. Las decisiones que necesitan un ser humano son aquellas en las que el costo de equivocarse es alto y el costo de ser lento es bajo. Esas son las fusiones, no los planes, los parches, las pruebas o las descripciones de relaciones públicas. Los agentes se encargan de todo lo demás. Los agentes proponen; los humanos deciden. ## El bucle agente, de extremo a extremo Lea junto con la publicación de investigación de clientes, la forma ahora es legible. La mitad frontal: el agente del usuario evalúa Neotoma en comparación con su flujo de trabajo real y lo instala si es adecuado. La mitad posterior: el agente presenta errores, observaciones de rendimiento y solicitudes de mejora a medida que los encuentra, y el lado del mantenedor los resuelve, a menudo antes de que el usuario recuerde que se presentó. Ambas mitades operan sobre agentes que hablan con agentes a través de una superficie estructurada. La fricción que históricamente acabó con el ciclo de adquisición y el ciclo de retroalimentación desapareció porque cada paso de traducción fue absorbido por una llamada a una herramienta. Ninguna de las dos mitades sería posible sin el sustrato subyacente: la evaluación dirigida por agentes necesita un estado estructurado sobre el flujo de trabajo del usuario, y el subsistema de problemas necesita señalización de eventos más acceso de invitados a través de límites de confianza. Ambos dependen de las mismas primitivas. ## Lo que no estoy construyendo La tentación en el subsistema de problemas es derivar hacia la orquestación: un modelo de priorización, seguimiento automático de SLA, un enrutador "inteligente" que decide qué demonio maneja qué tipo de problema. Cada uno suena razonable por separado. Ninguno de ellos pertenece al sustrato. El demonio de clasificación prioriza. Los agentes del mantenedor rastrean sus propios tiempos de respuesta. El enrutamiento es un filtro de suscripción. Lo mismo se aplica a la semántica de reintento. Si falla la entrega de un webhook, el sustrato registra el error y continúa. No escala a un canal de respaldo, no almacena en búfer para la reproducción, no lleva al consumidor a un estado degradado. Los intermediarios de mensajes hacen todo eso y son buenos en eso; el sustrato no es un intermediario de mensajes. Los consumidores que quieren una entrega garantizada envuelven la señal en su propia infraestructura. La restricción es la característica. Una capa estatal que señala problemas pero no decide cuáles importan es una capa estatal en la que cualquier consumidor puede confiar para comportarse de manera predecible. ## Sobre qué quiero comentarios El subsistema de problemas está activo. Si tiene Neotoma instalado y su agente encuentra algo difícil (un error, una brecha de rendimiento, una capacidad faltante que desearía que existiera), ya no necesita pedirle que presente un problema. Para retomar esto en una instalación existente, actualice con `npm install -g neotoma@latest`. No hay que configurar ningún consentimiento por usuario; el consentimiento es la instalación. Si se trata de una instalación nueva, "neotoma reporter setup" recorre la configuración única del lado del reportero para que el primer problema con los archivos de su agente tenga un lugar donde aterrizar. Si aún no tiene Neotoma instalado, pídale a su agente que ejecute la página de evaluación. Si concluye que Neotoma encaja, puede instalarlo y activarlo sin que usted lea un documento de configuración. Si concluye que Neotoma no encaja, ese también es un resultado válido y más honesto que el que producen la mayoría de las páginas de destino. Si está creando un producto cuyos usuarios ejecutan agentes, el modelo es portátil. El trabajo interesante no está en ninguno de los dos lados del cable; es el cable mismo.