Un bucle de agentes que se detiene solo

Tres agentes en un equipo, cada uno fijado a un modelo distinto, con el puente y sus límites entre ellos

¿Puedes confiar en lo que escribe la IA? ¿Y cuánto cuesta averiguarlo? Esas son las dos preguntas honestas sobre programar con IA, y todo el mundo habla a gritos de las dos. Lo que casi no he escuchado es que son la misma pregunta. Las resuelves con un solo diseño.

El caso del sesgo es el de siempre. Un modelo se entrena con una porción torcida del mundo, la salida hereda esa torcedura y no puedes confiar del todo en ella. Todo cierto. Nada de eso significa que te detengas. Significa que dejes de apoyarte en un solo modelo. Ejecuta varios, deja que se revisen entre sí, y aquello que un modelo no ve suele ser algo que otro sí detecta.

Y ese arreglo es justo lo que convierte al costo en la segunda pregunta. Dos modelos cuestan más que uno. Tres agentes hablando entre sí cuestan más que tres trabajando por separado, y un bucle que nadie vigila cuesta lo que se le antoje. Así que estás resolviendo dos problemas con un solo diseño: conseguir suficiente desacuerdo para atrapar los errores, y evitar que ese desacuerdo dispare una factura que nunca aceptaste. Construir la verificación y ponerle un límite resultan ser el mismo trabajo.

Tres herramientas hacen esto a distintas escalas, incluida una que construí yo misma.

opencode-fusion: un panel que discute, luego un juez

opencode-fusion es la versión local de Samir Patil (@sampatil1010) de Fusion de OpenRouter (@OpenRouter): ejecuta una misma tarea en un panel de modelos a la vez y luego resuelve su desacuerdo en lugar de promediarlo. El panel por defecto es Sonnet, GPT y GLM, definido como un arreglo de bash que editas para añadir o quitar modelos. Se ejecutan en paralelo a través de la CLI de OpenCode, y cada salida se escribe en su propio archivo temporal. Los fallos se anotan pero no abortan la ejecución.

Luego un modelo juez lee todas las salidas y escribe un informe estructurado: dónde coinciden los modelos, dónde se contradicen y qué lado tiene más probabilidad de tener razón, qué pasó por alto cada modelo y qué se ve arriesgado. Un sintetizador toma la tarea original, el informe del juez y las salidas en bruto, y produce la única respuesta que de verdad ves.

Invocas todo con una sola línea:

bash run_fusion.sh "<TASK>"

El paralelismo es la parte aburrida. Lo que en realidad estás comprando es el desacuerdo. Cuando dos modelos llegan a la misma respuesta y un tercero se va por otro lado, esa brecha te dice algo que una respuesta segura por sí sola nunca diría. El juez hace la lectura. Obtienes una respuesta en lugar de tres transcripciones.

agmsg: agentes que se mensajean entre sí

opencode-fusion es de un solo turno. Preguntas, el panel responde, listo. A veces quieres que los modelos vayan y vengan. Eso es agmsg, de @fujibee.

agmsg permite que los agentes de CLI se mensajeen entre sí a través de un archivo SQLite compartido. Sin demonio, sin red, solo bash y sqlite3, instalado como una habilidad de agente. Es multiproveedor, así que Claude Code, Codex, Gemini CLI y Copilot CLI pueden unirse al mismo equipo y pasarse mensajes. Y los mensajes persisten, que es lo que lo separa de las alternativas. Un subagente integrado es efímero y está atado al proveedor de su padre. MCP es un agente echando mano de herramientas. agmsg es de otra forma: agentes independientes, modelos distintos, hablando entre sí por un canal duradero.

La instalación es de una sola línea:

bash <(curl -fsSL https://raw.githubusercontent.com/fujibee/agmsg/main/setup.sh)

Tras un reinicio, los agentes obtienen un comando (/agmsg en Claude Code y Copilot CLI, $agmsg en Codex y Gemini CLI), eligen un equipo y un nombre, y empiezan a hablar.

Una cosa que conviene saber antes de conectarlo a cualquier cosa: agmsg es deliberadamente tonto. Mueve mensajes y nada más, así que dos agentes demasiado corteses se la pasarán pidiéndose aclaraciones hasta que tu factura de tokens parezca un número de teléfono. Lo que corte ese bucle tiene que venir de ti.

Lo que construí

Conecté agmsg a un pequeño puente que vigila la bandeja compartida y entrega mensajes entre tres agentes de forma automática. Sin que ningún humano retransmita nada entre ellos.

El puente hace un solo trabajo. Consulta la bandeja de SQLite cada cuatro segundos con un SELECT en busca de filas sin leer, y luego entrega cada una a su agente destino. Sin observador de archivos, nada ingenioso, solo un bucle y una consulta.

Los tres agentes están en un mismo equipo, y ninguno funciona igual. Uno corre a través de una CLI con su modelo definido en un archivo de configuración local, otro corre como un comando de un solo turno, y otro responde por una API HTTP. Cada uno está fijado a un modelo distinto, y ese modelo vive en la configuración del propio agente, no en el puente. Al puente no le importa ni sabe qué modelo está del otro lado de un mensaje, y ese es el punto: puedo cambiar el modelo de cualquier agente sin tocar lo que mueve los mensajes.

La razón de los tres modelos distintos nunca fue que los agentes pudieran hablar entre sí. Fue que cuando uno de ellos se equivocara, ya había un modelo entrenado con datos distintos esperando para atraparlo.

Eso solo se sostiene mientras los modelos sean de verdad independientes. Dos entrenados con casi el mismo texto comparten los mismos puntos ciegos, y cuando lo hacen coincidirán en una respuesta equivocada tan rápido como en una correcta, así que el desacuerdo con el que cuento nunca aparece. Repartir entre proveedores (gpt-4.1, Sonnet 4.6 y uno propio) compra más independencia que tres versiones de un mismo modelo, pero es una cobertura, no una garantía.

El puente en sí es pequeño, un bucle de sondeo y el conjunto de límites de abajo. Lo estoy puliendo para liberarlo como código abierto pronto.

Evitar que se devore a sí mismo

agmsg no va a impedir que dos agentes se pidan aclaraciones para siempre. Un bucle desbocado aquí quema dinero real, rápido, así que la contención está toda en el puente. Cuatro límites, cada uno para una forma distinta en que sale mal.

Dos contadores de ventana deslizante, ambos sobre una ventana de 300 segundos. Uno limita el total de despachos a 12 por ventana. El otro limita los saltos de bot a bot a 6 por ventana, porque ese es el intercambio que se desboca: dos agentes respondiéndose sin ningún humano alrededor que se aburra y lo detenga. Cuando cualquiera de los límites se dispara, el mensaje se descarta y se registra, nunca se reintenta. Un mensaje descartado es más barato que un bucle.

Después un bloqueo en vuelo por agente, para que cada agente maneje un turno a la vez y no se le pueda apilar trabajo nuevo mientras todavía está pensando. Y cortes por reloj de pared por agente, ajustados a qué tan lento se le permite ser a cada uno: 280 segundos, 150 y 120. Un turno colgado muere por reloj en lugar de quedarse con el bloqueo para siempre.

No un presupuesto de tokens. Los contadores y los relojes acotan el costo de forma indirecta, y son más fáciles de razonar que una cifra en dólares que tendría que recalibrar todo el tiempo.

/orchestrate: la misma idea con interfaz

Si no quieres construir la fontanería tú misma, la app de GitHub Copilot hace una versión de esto a un nivel más alto. /orchestrate convierte la sesión principal en un coordinador: levanta sesiones hijas, le da a cada una su propia rama y tarea, y deja que reporten de vuelta mientras la sesión principal dirige y resume. Una sesión, una rama, un PR. Cada una corre en su propio git worktree, así que no se editan los mismos archivos por debajo unas a otras, y eliges el modelo por sesión.

La misma idea que el puente, solo que gestionada por ti: varios agentes, modelos distintos, evitando pisarse entre sí. Renuncias al control fino que tendrías construyéndolo tú misma, y a cambio no tienes que mantener nada de eso.

Ninguna de estas herramientas finge que un solo modelo tiene razón. Asumen que a veces se equivocará, meten la verificación en el flujo de trabajo y mantienen barata esa verificación.

Ese es todo el movimiento. “El modelo está sesgado” y “es demasiado caro de ejecutar” se tratan como razones para esperar. No lo son. Son dos caras de un mismo problema de diseño, y el arreglo se lee igual desde cualquiera de los dos lados: ejecuta más de un modelo, déjalos estar en desacuerdo donde de todos modos iban a estarlo, y pon algo en el camino que lea el desacuerdo para que tú no tengas que hacerlo. El límite es lo que lo mantiene honesto. Leer el desacuerdo nunca debería costar más que el error que atrapa.

Una nota antes de que vayas a construir esto. Todo lo que hay aquí es lo que yo he usado, compartido tal cual. No está validado para tu configuración, y no puedo responder por la seguridad de herramientas que no escribí. Lee el código, pruébalo en un lugar seguro y decide por ti misma. Que me sirva a mí no es lo mismo que sea seguro para ti. Esa parte te toca verificarla a ti.

Publicado originalmente en X.