Los agentes no tienen que chatear: orquestación por artefactos

Tesis central: los agentes pueden "hablar entre sí". Esa conversación, eso sí, debe convertirse en un protocolo: cada rol produce un artefacto verificable y el siguiente recibe únicamente ese artefacto, el trozo de repositorio que necesita y su propio mandato. Los bucles se abren por evidencia de fallo, no por conversación libre.

1. Resumen ejecutivo

Un grupo de agentes conversando no es la mejor arquitectura para un sistema multiagente que desarrolla software. Un pipeline rígido sin vuelta atrás, tampoco. Lo que sí es: una máquina de estados dirigida por un cerebro, donde los agentes cooperan mediante artefactos de trabajo, disponen de contexto selectivo y solo entran en bucles cuando existe una razón concreta y observable para hacerlo.

El patrón recomendado es: cerebro → implementador → validación determinista → revisor → adversarial → veredicto. Si aparece un fallo de implementación, se vuelve al implementador con una corrección acotada. Si aparece un fallo de diseño, se vuelve al cerebro. Si el problema es de requisitos, se escala a la persona que encargó la tarea. Cada retorno lleva un informe estructurado, no toda la conversación anterior.

Idea clave: la unidad de comunicación no es el mensaje; es el artefacto. Decisiones, evidencia y acciones pendientes van condensadas en ese artefacto, de forma consumible por el siguiente rol. Y queda persistido, para que cualquiera pueda reconstruir después por qué el sistema hizo lo que hizo.

2. Qué significa realmente que los agentes "hablen entre sí"

Sí, los agentes interactúan. Compartir una sala de chat no hace falta. Leer lo que los demás pensaron, tampoco. La interacción ocurre mediante entregables explícitos: una especificación de implementación, un diff, un informe de revisión con hallazgos citados, un conjunto de casos adversariales, el resultado de unos tests o una solicitud de replanteamiento.

TAREA
 ↓
CEREBRO ──────────────► Especificación de implementación
 ↓
IMPLEMENTADOR ────────► Resultado + diff + evidencia de tests
 ↓
CHECKS DETERMINISTAS ─► Informe de verificación (exit codes, hashes)
 ↓
REVISOR ──────────────► Informe de revisión
 ↓
ADVERSARIAL ──────────► Informe adversarial
 ↓
VEREDICTO
 ├─ PASA → recibo → hecho
 ├─ fallo de implementación → implementador (una corrección)
 ├─ fallo de diseño → cerebro
 └─ hueco de requisito → persona que encargó la tarea

Ejemplo: el implementador termina una tarea y produce un resultado de implementación. El revisor recibe el requisito original, la especificación aprobada, el diff, la evidencia de tests y solo los fragmentos de código necesarios. El transcript de cómo el implementador llegó a la solución no entra. Sus justificaciones, tampoco. Esto preserva la independencia del juicio y elimina el anclaje.

Un matiz importante: "no chatear" no es lo mismo que "no volver atrás". Volver atrás se hace como transición explícita, con un artefacto que la justifica, no como una réplica en un hilo.

3. Por qué no conviene la conversación libre

Problema	Qué ocurre en un enjambre conversacional	Consecuencia
Deriva de contexto	Cada agente añade opiniones, hipótesis y matices que los siguientes heredan	Más tokens y menos foco
Anclaje	El revisor conoce las justificaciones del autor antes de evaluar	Tiende a validar la solución existente
Responsabilidad difusa	No queda claro quién tomó cada decisión	Difícil depurar errores del sistema
Bucles infinitos	Los agentes debaten mejoras marginales indefinidamente	Coste alto y latencia impredecible
Contaminación de roles	El adversarial acaba actuando como otro revisor; el implementador vuelve a diseñar	Se pierde diversidad cognitiva
Memoria inflada	Se reinyecta todo el transcript en cada turno	La ventana se consume con historia, no con código
Estado implícito	La "verdad" del trabajo vive repartida en mensajes	Nadie puede decir en qué estado está la tarea sin releerlo todo

La conversación libre es óptima para explorar. Para entregar, es pésima. En un chat, la información más reciente pesa más que la más importante, y el consenso se confunde con la corrección.

4. Principios de diseño

1. Artefactos antes que conversación. Todo traspaso entre agentes tiene una salida estructurada y persistida.
2. Contexto mínimo suficiente. Cada agente recibe lo necesario para su función, no todo lo disponible. El objetivo no es minimizar tokens a cualquier precio, sino maximizar señal por token.
3. Independencia del evaluador. Revisor y adversarial no heredan el razonamiento privado ni la defensa del implementador.
4. Evidencia antes que opinión. Tests, compilación, tipos, lint y ejecución tienen prioridad sobre el juicio de un modelo. La evidencia se firma: comando, exit code, hash de la salida.
5. Bucles dirigidos. Se vuelve atrás por una causa clasificada, nunca por "sigamos debatiendo".
6. Límites explícitos. Todo ciclo tiene un número máximo de vueltas, un presupuesto y un criterio de escalado.
7. Separación de responsabilidades. Planear, implementar, verificar, revisar y atacar son funciones distintas.
8. Estado explícito. El sistema mantiene la verdad del workflow: fase, artefactos, intentos, costes y veredictos.
9. Escalado por naturaleza del fallo. Un problema de arquitectura no se parchea indefinidamente en implementación.
10. Rutas proporcionales al riesgo. No toda tarea necesita cerebro + revisor + adversarial.

5. Los roles y qué capacidad necesita cada uno

La diversidad útil no te la da el número de modelos. Te la da asignar funciones cognitivas distintas. Tres agentes con el prompt "haz code review" producen correlación, no cobertura. Cada función pide una capacidad distinta, y eso es lo que te deja gastar el modelo más caro donde más decide y el más barato donde más se escribe.

Rol	Pregunta dominante	Capacidad que necesita	Volumen de tokens
Cerebro	¿Cuál es la solución más coherente con el sistema y sus restricciones? ¿Cuál es el siguiente estado correcto?	El mejor razonamiento disponible: es quien especifica, arbitra y decide	Bajo: pocas decisiones de mucho valor
Implementador	¿Cómo convierto esa solución en un cambio correcto y mínimo?	Buen razonamiento y buen uso de herramientas, rápido y económico por token. No hace falta el modelo top	Alto: es quien más lee y escribe
Checks deterministas	¿Se puede comprobar esto sin razonar?	Ninguna: herramientas	Cero
Revisor	¿Cumple realmente lo pedido y está bien construido?	Razonamiento fuerte, esfuerzo alto, de una familia de modelos distinta a la del implementador	Medio: un turno sobre un artefacto compacto
Adversarial	¿Qué supuesto puedo romper para demostrar que falla?	Razonamiento fuerte y creativo, familia distinta al implementador; solo en tareas de riesgo	Bajo y puntual
Persona	Las decisiones que el sistema no puede derivar	Criterio de negocio	Mínimo: elige entre opciones ya materializadas

Que los modelos de una misma casa compartan puntos ciegos y sesgos de entrenamiento no es un detalle estético: es la regla de las familias. Un revisor que piensa como el implementador aprueba lo que el implementador habría aprobado.

5.1 El cerebro decide; la máquina de estados ejecuta

Meter un modelo "coordinador" que decida a quién llamar en cada turno tienta. Es la conversación libre con otro nombre. La estructura sana tiene dos piezas.

• El cerebro (el modelo de mayor capacidad) toma las decisiones que requieren juicio: convierte el objetivo en especificación, redacta el mandato de cada fase, clasifica un fallo de diseño frente a uno de implementación, decide partir una tarea. Son pocas decisiones y de alto valor, por eso puede ser el modelo más caro y seguir siendo el que menos gasta.
• La máquina de estados (código determinista) aplica esas decisiones: compila el contexto de cada rol, ejecuta los checks, impone presupuestos, admite o rechaza artefactos, registra el estado y ejecuta la transición siguiente. No razona; comprueba.

El cerebro no programa. Produce un artefacto: la especificación y, por fase, un mandato. Ahí van el objetivo, los ficheros esperados, el comando de test exacto, el presupuesto de líneas y la frontera de rollback. Si la tarea no cabe en el presupuesto, se parte antes de invocar a nadie.

5.2 El implementador entrega evidencia, no confianza

Le llega un mandato estable, localiza el código relevante, implementa, ejecuta las verificaciones y devuelve exactamente qué cambió: el diff, la evidencia de tests (qué test falló primero, qué lo puso en verde, qué segundo caso lo triangula) y una lista corta de aprendizajes. Si descubre que la especificación no es viable, no rediseña en silencio: emite un bloqueo de diseño y devuelve el control. Un test existente que falla nunca se edita; se para y se reporta. Esa regla evita muchos desastres.

5.3 El revisor no explora; juzga un artefacto

En un solo mensaje le meten el requisito, la especificación, el diff completo con su manifiesto de ficheros y un esquema de respuesta. Ni repositorio ni razonamiento del autor. Eso no lo limita: lo obliga a hacer su trabajo. Y permite la admisión de su respuesta, algo que un revisor conversacional nunca permite. Si no lista todos los ficheros del cambio, si cita una línea que no existe en el diff, o si dice "no pude inspeccionar" y aun así aprueba, la revisión no se admite. No se reintenta sola: se registra como fallo tipado y el cerebro decide.

5.4 El adversarial no repite el code review

Su faena es falsar la solución: casos límite, concurrencia, fallos parciales, idempotencia, seguridad, estados imposibles, supuestos frágiles. Pregunta "¿cómo puedo romper esto aunque el camino feliz funcione?" y entrega escenarios reproducibles, idealmente como tests que fallan. Solo entra cuando el riesgo lo justifica. Quien decide el nivel de revisión no es el tamaño del cambio: es la señal (autenticación, pagos, datos, ejecución de comandos).

6. Los artefactos: el verdadero lenguaje entre agentes

Compactos para viajar entre agentes, ricos para reconstruir por qué el workflow tomó una decisión: así tienen que ser los artefactos. Se pueden persistir como YAML/JSON versionados en el repositorio o como registros por ejecución.

6.1 Sobre de tarea

task_id: T-1842
objective: "Añadir rotación de refresh token"
acceptance_criteria:
 - "un refresh token solo puede usarse una vez"
 - "dos refresh concurrentes no crean dos sesiones válidas"
constraints:
 - "mantener compatibilidad con clientes actuales"
risk: HIGH
repo_revision: "a84f1c2"

6.2 Especificación de implementación (cerebro → implementador)

design_summary: "Rotación atómica del refresh token"
files_expected: [src/auth/service.py, src/auth/repository.py]
invariants:
 - "consume(old_token) es atómico"
 - "un token consumido nunca vuelve a ser válido"
test_plan: [unit_refresh_rotation, concurrent_refresh_attempt, revoked_token_reuse]
out_of_scope: ["cambiar el formato del JWT"]
budget: {max_changed_lines: 400, rollback_boundary: "a84f1c2"}

6.3 Resultado de implementación

status: implemented
changed_files: [src/auth/service.py, src/auth/repository.py]
summary:
 - "compare-and-swap al consumir el token"
 - "índice único sobre token_hash"
checks: {pytest: PASS, mypy: PASS, ruff: PASS}
tdd_evidence:
 - {test: concurrent_refresh_attempt, red: "AssertionError: 2 sesiones", green: PASS, triangulate: "3 concurrentes"}
known_risks: []
blockers: []

6.4 Informe de revisión

subject_hash: "sha256 del diff revisado"
inspection: {status: completed, paths: [src/auth/service.py, src/auth/repository.py]}
verdict: CHANGES_REQUIRED
findings:
 - id: REV-01
 severity: HIGH
 location: src/auth/repository.py:41-48
 claim: "lectura y update ocurren en dos transacciones"
 proof_refs: ["consumed = row.consumed", "session.commit() # antes del update"]
 evidence_class: deterministic # deterministic | inferential | insufficient
 causal_disposition: introduced # introduced | pre-existing
 required_fix: "update condicional dentro de una sola transacción"
retest: [concurrent_refresh_attempt]

Con tres campos tienes el trabajo hecho. evidence_class manda que un hallazgo "insuficiente" no abra corrección: escala, el sistema no fabrica certeza. causal_disposition manda que lo preexistente vaya a seguimiento y no bloquee este cambio. proof_refs exige citas literales del diff; "N/A" no se admite.

6.5 Informe adversarial

verdict: FAIL
attack_cases:
 - id: ADV-03
 scenario: "dos refresh simultáneos con 5 ms de diferencia"
 expected: "solo uno devuelve 200"
 observed_or_predicted: "ambos pueden pasar antes del commit"
 impact: "duplicación de sesión"
 confidence: 0.91
route_hint: implementation_issue

6.6 Recibo de fase

phase: F3-auth
tree_hash: "e4eba59f…"
checks: [{cmd: "pytest -q", exit_code: 0, output_hash: "…"}]
review: {admitted: true, verdict: PASS, subject_hash: "…"}
adversarial: {verdict: PASS}
human_decisions: ["ampliar presupuesto de contexto a 24k (ESC-004)"]

Una fase no se cierra porque el implementador suelte un "hecho". Se cierra cuando existe un recibo que liga el hash del árbol, los checks con sus exit codes, la revisión admitida y las decisiones humanas. Sin ese recibo no hay avance.

6.7 Escalación a la persona

Si el sistema no puede derivar una decisión (un hallazgo con evidencia insuficiente, un presupuesto que no alcanza, un hueco de requisitos), no pregunta con texto libre. Saca un sobre con la evidencia y exactamente dos opciones, cada una con la acción concreta que la materializa, más una salida documentada fuera del par. Elige la persona y aplica el sistema. Registrar una decisión humana y no aplicarla deja un artefacto roto.

7. Contexto selectivo: qué debe ver cada agente

La calidad del sistema no se juega solo en el contexto que metes: también en el que dejas fuera. Un compilador de contexto construye un paquete distinto por rol en tres capas — permanente (reglas del rol, checklist), de tarea (fase, requisitos, escalaciones abiertas) y material (ficheros fuente, diff, contratos) — bajo un presupuesto explícito. Si el material no cabe, no se poda en silencio: se rechaza y se escala con la opción de partir la tarea.

Contexto	Cerebro	Implementador	Revisor	Adversarial
Sobre de tarea completo	Sí	Sí	Sí	Sí
Arquitectura general del repo	Sí	Solo la relevante	No	Solo la relevante
Especificación de implementación	Autor	Sí	Sí	Sí
Código fuente	Exploración	Sí (edita)	Solo el diff	Diff + superficie de ataque
Resultados de tests	Diseña el plan	Los ejecuta	Exit codes y hashes	Sí
Razonamiento privado del implementador	No	Propio	No	No
Informe de revisión previo	Solo si hay rediseño	Sí, al corregir	Solo el delta en re-revisión	Selectivo
Informe adversarial previo	Solo si hay rediseño	Sí, al corregir	Opcional	Sí, en re-test

Regla práctica: el revisor tiene que ver lo que se hizo y la evidencia, no la defensa narrativa de quien lo hizo. El adversarial tiene que ver superficie suficiente para atacar la solución, no toda la historia de la ejecución.

8. Validación determinista antes de validación por modelo

Un agente no debería quemar razonamiento demostrando lo que una herramienta comprueba más barato y mejor. Antes de invocar al revisor corren los checks disponibles en el repositorio: formato, lint, compilación, tipos, tests unitarios y de integración, tests de contrato, trazabilidad requisito→test, mutación, análisis de seguridad, migraciones en seco.

Ese chequeo deja un artefacto firmado: comando, exit code, hash de la salida. Un informe de verificación que diga "pasa" con un hallazgo crítico abierto, o "falla" con todo en verde, se rechaza por contradictorio. La prosa nunca gobierna una transición.

9. Cómo diseñar los bucles

Si el bucle corrige información nueva, está haciendo su trabajo. Si se pone a repetir opinión, es perjudicial y punto. Cada vuelta tiene que cargar un delta: un hallazgo, una prueba fallida, un bloqueo de diseño o un requisito nuevo.

Código de retorno	Destino	Qué viaja en el traspaso
CORRECCIÓN	Implementador	Hallazgo concreto + evidencia + tests a re-ejecutar. Presupuesto en líneas
REDISEÑO	Cerebro	Restricción violada + evidencia + impacto + diff relevante
RE-REVISIÓN	Revisor	Solo el delta de la corrección + hallazgos anteriores
RE-TEST ADVERSARIAL	Adversarial	Patch nuevo + casos de ataque que fallaron
EVIDENCIA INSUFICIENTE	Persona	El hallazgo tal cual: el sistema no fabrica certeza
HUECO DE REQUISITO	Persona	La pregunta mínima que bloquea una decisión real
ESCALADO	Cerebro o persona	Historial resumido de intentos y por qué fallaron

La recomendación es clara: una corrección por candidato como norma, dos como máximo, y el presupuesto proporcional al cambio original. Se fuerza el escalado si reaparece el mismo hallazgo, si la corrección devuelve un delta vacío o si el sistema oscila entre dos soluciones. Los avisos no abren correcciones: un WARNING se anota y se sigue. "Arreglar" avisos sobre un candidato ya aprobado es, de largo, la forma más común de quemar ciclos.

10. Rutas según complejidad y riesgo

Nivel	Ruta sugerida	Ejemplos
BAJO	Implementador → checks → revisión ligera	Renombrados, textos, estilos, bug local evidente
MEDIO	Cerebro ligero → implementador → checks → revisor	Endpoint nuevo, lógica de negocio acotada
ALTO	Cerebro → implementador → checks → revisor → adversarial	Autenticación, pagos, concurrencia, migraciones
CRÍTICO	Cerebro fuerte → implementador → checks amplios → revisor fuerte → adversarial fuerte → decisión humana	Seguridad, datos destructivos, infraestructura productiva

No mires el volumen (cuántas líneas). Mira la señal: qué está tocando el cambio. Un cambio de cinco líneas en autorización pesa más que un renombrado de cinco mil.

11. Estado y persistencia

Reproducible o no sirve. Cada ejecución tiene que poder repetirse tal cual, así que el sistema persiste, como mínimo, el identificador de tarea, la revisión del repositorio, la fase actual, el agente y la capacidad usada en cada invocación, el artefacto de entrada y el de salida, los resultados de checks, el coste y los tokens, la duración, el código de razón de cada transición y el número de iteración. Los artefactos son inmutables por versión: no se sobrescribe un informe de revisión v1 con el v2. Se enlaza la versión nueva con su padre. Así puedes reconstruir exactamente qué información tenía cada agente cuando decidió.

Especificación v1
 ↓
Resultado de implementación v1
 ↓
Informe de revisión v1 (CHANGES_REQUIRED)
 ↓
Resultado de implementación v2 (corrección)
 ↓
Informe de revisión v2 (PASS)
 ↓
Informe adversarial v1 (PASS)
 ↓
Recibo de fase

12. Cuándo permitir interacción directa entre agentes

Que exista, vale, pero como excepción controlada. El implementador puede emitir una solicitud de aclaración al cerebro cuando una precondición técnica contradice la especificación. Esa interacción pasa por la máquina de estados y queda registrada como artefacto. La regla es seca: una pregunta concreta → una respuesta concreta → se vuelve al flujo. Si la respuesta cambia el diseño, se crea una nueva versión de la especificación. No se abre una conversación bidireccional ilimitada.

13. Métricas para saber si el sistema mejora

Métrica	Qué indica
Pass rate en primera revisión	Calidad de cerebro + implementador
Hallazgos admitidos / hallazgos totales	Precisión del revisor y del adversarial
Vueltas por tarea	Cantidad de retrabajo
Tokens por tarea completada	Eficiencia real, no tokens por agente
Coste por nivel de riesgo	Si el routing sobredimensiona tareas simples
Tasa de reapertura	Tareas "terminadas" que vuelven por defecto
Tasa de escalado al cerebro	Cuántos fallos eran de diseño y no de implementación
Hallazgos únicos del adversarial	Errores que el revisor no vio
Escalaciones a persona por tipo	Si el sistema pregunta lo que debe o lo que no sabe clasificar

14. Anti-patrones

• Todos los agentes reciben todo el historial.
• Revisor y adversarial tienen prácticamente el mismo prompt, o son de la misma familia que el implementador.
• El implementador decide por sí mismo cuándo la tarea está terminada.
• Se vuelve siempre al implementador aunque el fallo sea arquitectónico.
• Cada agente vuelve a leer el repositorio entero desde cero.
• Se usa un modelo para comprobar lo que un test o un compilador ya detecta.
• No existen límites de iteración ni presupuesto.
• Los agentes modifican el mismo workspace simultáneamente sin aislamiento.
• Los hallazgos no tienen evidencia ni criterio de aceptación.
• Se guarda el transcript, pero no los artefactos estructurados que explican el estado.
• Un modelo "coordinador" decide el flujo turno a turno.

14.1 Prueba de olor

• ¿Un agente recibe contexto que no puede justificar por su función?
• ¿Dos roles producen hallazgos casi idénticos de forma sistemática?
• ¿Un fallo vuelve más de dos veces sin cambiar de categoría ni aportar evidencia nueva?
• ¿El revisor necesita leer el razonamiento del implementador para decidir?
• ¿Se invoca un modelo caro antes de ejecutar checks deterministas baratos?
• ¿El sistema no puede explicar con un código de razón por qué eligió el siguiente estado?
• ¿Una tarea simple atraviesa el mismo pipeline que una migración crítica?
• ¿Una decisión humana puede quedar registrada sin aplicarse?

15. Tesis final

Olvídate de la reunión de personas. Un buen sistema multiagente de desarrollo de software se parece a un pipeline de ingeniería con especialistas. Colaboran, sí, pero mediada por contratos de información. El cerebro diseña y decide. El implementador construye. Las herramientas deterministas verifican. El revisor juzga sin anclaje. El adversarial se empeña en romper. La máquina de estados ejecuta la transición que dicte la evidencia. La persona decide lo que el sistema no puede derivar.

La conversación libre maximiza el intercambio de información; eso no se discute. La orquestación por artefactos maximiza la información útil. Esa diferencia es la que permite escalar un sistema sin que el coste, el contexto y la imprevisibilidad crezcan más rápido que la calidad.

Regla de oro: agente → artefacto → evidencia → siguiente agente. Un bucle no se inventa: solo existe si una evidencia concreta justifica volver atrás.

16. Blueprint mínimo para implementar primero

1. Un estado persistente y una máquina de estados determinista; el cerebro decide, el código ejecuta.
2. Seis esquemas: sobre de tarea, especificación de implementación, resultado de implementación, informe de revisión, informe adversarial, recibo de fase.
3. Un compilador de contexto por rol con presupuesto y lista de exclusiones (el razonamiento privado nunca cruza de rol).
4. Checks deterministas antes del revisor, con salida firmada.
5. Revisor sobre artefacto (diff + especificación + esquema), con admisión de su respuesta.
6. Routing por código de razón: implementación, diseño, requisito, pasa; una corrección por candidato con presupuesto.
7. Escalaciones con dos opciones materializables.
8. Medir tokens, coste, vueltas y hallazgos únicos por rol.
9. Solo después: memoria entre tareas, interacción directa excepcional y rutas dinámicas más sofisticadas.