Deliberación Multi-Agente: Cuando el Acuerdo Es el Error
El resultado más peligroso que produce mi agente de IA no es un error. Los errores son fáciles. Los linters detectan errores de sintaxis, las suites de pruebas detectan regresiones, y los 95 hooks que construí detectan except: pass y force pushes. El resultado peligroso es una recomendación segura, bien razonada, que resulta estar equivocada.
Le pedí a un solo agente que revisara un endpoint de API en busca de problemas de seguridad. El agente verificó la autenticación, validó la sanitización de entradas y comprobó los encabezados CORS. Resultado limpio. Un segundo agente, con instrucciones separadas como pentester, encontró que el endpoint aceptaba parámetros de consulta sin límites que podían provocar una denegación de servicio mediante amplificación de consultas a la base de datos. El primer agente nunca lo verificó porque nada en su marco de evaluación trataba la complejidad de las consultas como una superficie de seguridad.
Esa brecha es estructural. Ninguna cantidad de ingeniería de prompts la corrige porque la limitación no está en el prompt. La limitación está en tener una sola perspectiva evaluando un problema multidimensional.
Construí un sistema de deliberación multi-agente para cerrar esa brecha. Agentes con diferentes personas investigan de forma independiente, debaten hallazgos y alcanzan consenso mediante votación estructurada. El sistema ejecuta 141 pruebas, impone aislamiento de contexto entre agentes y utiliza una arquitectura de validación de dos puertas que bloquea el acuerdo prematuro.
TL;DR
Los sistemas de IA de un solo agente tienen un punto ciego estructural: no pueden cuestionar sus propias suposiciones. Un bucle Ralph ejecutando Sonnet produce código a $10/hora, pero cada punto ciego del modelo se despliega al mismo ritmo. La deliberación multi-agente fuerza una evaluación independiente desde múltiples perspectivas antes de que cualquier decisión se consolide. Mi implementación utiliza 10 personas de investigación, una máquina de estados de 7 fases y dos puertas de validación (consenso + pride check) ejecutándose en hooks de Claude Code. El sistema se activa en decisiones de baja confianza (por debajo de 0,70) y añade aproximadamente 3x el costo en tokens por deliberación. Para decisiones de seguridad, elecciones de arquitectura y cualquier cosa irreversible, ese costo se paga solo la primera vez que detecta algo que un solo agente pasó por alto. Para correcciones de documentación y ediciones rutinarias, omita la deliberación por completo.
La Noche en Que Mis Agentes Acordaron Romper Todo
Febrero de 2026. Un martes. Le pedí a mi agente que “investigara cómo mejorar el sistema de despacho de hooks” y me fui a preparar café. El agente evaluó su propia confianza en 0,58 (por debajo del umbral de 0,70), lo que activó la deliberación. El sistema generó 3 agentes de investigación. Cada agente de investigación evaluó el problema, encontró subproblemas y generó sus propios agentes de investigación. Esos agentes generaron más.
Siete minutos después: 23 procesos de agentes activos. $4,80 en créditos de API consumidos. El directorio ~/.claude/state/ llenándose de archivos JSON de estado mientras cada agente persistía diligentemente sus hallazgos. El consumo de tokens aumentando a aproximadamente $0,70 por minuto sin señales de convergencia.
La protección contra recursión que había construido para el sistema de calidad rastreaba profundidad (padre genera hijo, hijo genera nieto) pero no amplitud (padre genera 12 hijos que cada uno genera 12 más). El límite de profundidad de 3 nunca se activó porque los agentes se expandieron horizontalmente. Maté los procesos manualmente y me quedé mirando los archivos de estado.
Cada agente coincidió en que el sistema de despacho de hooks necesitaba mejoras. Cada agente propuso cambios que sonaban razonables. Ningún agente cuestionó si la investigación en sí estaba correctamente delimitada. Veintitrés agentes alcanzando consenso sobre la pregunta equivocada.
La corrección tomó 20 minutos: un presupuesto de generación que rastrea el total de hijos activos por padre, limitado a 12. La lección más profunda tomó más tiempo. La curva de aceleración de infraestructura que había documentado hizo posible construir el sistema de deliberación en 2 semanas, precisamente porque la infraestructura de hooks ya existía. Pero la construcción rápida no previene fallos estructurales. La progresión desde pipelines RAG de un solo agente hasta sistemas autónomos sigue un arco predecible. La deliberación multi-agente se encuentra al final por una razón: solo se construye después de que un solo agente envía con confianza la respuesta equivocada.
El acuerdo, no el desacuerdo, era el modo de fallo peligroso.
Anatomía de una Deliberación
El sistema tiene dos componentes estructurales: una máquina de estados que secuencia el trabajo y dos puertas de validación que evitan que un mal consenso se despliegue.
La Máquina de Estados
Siete fases, cada una condicionada por la anterior:
IDLE -> RESEARCH -> DELIBERATION -> RANKING -> PRD_GENERATION -> COMPLETE
|
(or FAILED)
RESEARCH: Agentes independientes investigan el tema. Cada agente recibe una persona diferente (Arquitecto Técnico, Analista de Seguridad, Ingeniero de Rendimiento y 7 más). El aislamiento de contexto asegura que los agentes no puedan ver los hallazgos de los demás durante la investigación. L0 (reglas del sistema) y L1 (contexto del proyecto) son compartidos. L2 (enfoque específico del agente) es privado. L3 (patrones de dominio) carga bibliotecas de patrones relevantes por persona.1
DELIBERATION: Los agentes ven todos los hallazgos de investigación y generan alternativas. El agente de Debate identifica conflictos entre perspectivas. El agente de Síntesis combina hallazgos no contradictorios.
RANKING: Cada agente puntúa cada enfoque propuesto en 5 dimensiones ponderadas:
| Dimensión | Peso |
|---|---|
| Impacto | 0,25 |
| Calidad | 0,25 |
| Viabilidad | 0,20 |
| Reusabilidad | 0,15 |
| Riesgo | 0,15 |
Las puntuaciones ponderadas se agregan en una puntuación de consenso. El umbral es adaptable según la tarea: 0,85 para decisiones de seguridad, 0,80 para arquitectura, 0,70 por defecto, 0,65 para refactorización, 0,50 para documentación.2
Las Dos Puertas
Puerta 1: Validación de Consenso (hook PostToolUse:Task). Cuatro verificaciones se ejecutan después de que cada agente de deliberación completa:
- La fase debe haber alcanzado al menos RANKING
- Mínimo 2 agentes completados (configurable)
- La puntuación de consenso cumple el umbral adaptable según la tarea
- Si algún agente disintió, sus preocupaciones deben estar documentadas
Fallar cualquier verificación bloquea el avance de la deliberación.3
Puerta 2: Pride Check (hook Stop). Cinco verificaciones de calidad se ejecutan antes de que la sesión pueda cerrarse:
- Métodos Diversos: Múltiples personas únicas representadas
- Transparencia de Contradicciones: Las disidencias tienen razones documentadas
- Manejo de Complejidad: Al menos 2 alternativas generadas
- Confianza del Consenso: Puntuación clasificada como fuerte (superior a 0,85) o moderada (0,70-0,84)
- Evidencia de Mejora: La confianza final supera la confianza inicial
La arquitectura de dos puertas detecta problemas en diferentes etapas. La Puerta 1 previene la convergencia prematura durante el proceso. La Puerta 2 previene el despliegue de resultados que parecen completos pero carecen de rigor.
Los Analistas de Inteligencia Tuvieron Este Problema Primero
Construí el sistema de deliberación en enero de 2026. Dos semanas después, encontré Psychology of Intelligence Analysis de Richards Heuer en una lista de lectura sobre toma de decisiones estructurada. El Capítulo 8 describe el Análisis de Hipótesis Competidoras (ACH): los analistas evalúan evidencia contra múltiples hipótesis simultáneamente, en lugar de construir un caso para su conclusión preferida.4
El paralelo fue incómodo. El marco de Heuer, publicado en 1999 para la CIA, abordaba el mismo fallo estructural que yo había estado depurando: personas inteligentes convergiendo en una sola explicación porque nunca se obligaron a evaluar alternativas.
Así es como se ve el ACH en la práctica. Un analista de inteligencia que investiga un presunto programa de armamento no pregunta “¿es esto un programa de armamento?” (sesgo de confirmación). En cambio, el analista lista cada hipótesis plausible (programa de armamento, investigación civil, instalación de doble uso), evalúa cada pieza de evidencia contra cada hipótesis e identifica qué evidencia distingue mejor entre hipótesis.
Mi sistema hace lo mismo con vocabulario diferente. Tres agentes evalúan un cambio propuesto en el esquema de base de datos. El Agente A (Arquitecto Técnico) escribe: “El esquema está limpio, normalizado a 3NF.” El Agente B (Ingeniero de Rendimiento) escribe: “Los patrones de consulta requerirán joins entre 4 tablas en cada lectura.” El Agente C (Analista de Seguridad) escribe: “Los campos PII no están cifrados en reposo.” El mismo esquema, tres evaluaciones diferentes, tres piezas de evidencia diferenciadora. La fase de ranking evalúa el enfoque propuesto contra estas evaluaciones independientes de la misma forma en que el ACH evalúa hipótesis contra evidencia.
No diseñé el sistema a partir del marco de Heuer. Reinventé un subconjunto del ACH por prueba y error, y luego descubrí que alguien ya había escrito el libro de texto. La versión honesta es más útil que la halagadora: llegar a la misma arquitectura de forma independiente confirma que el problema subyacente es real, no teórico.
Por Qué el Acuerdo Es el Modo de Fallo Peligroso
Charlan Nemeth estudió la disidencia minoritaria desde 1986 hasta su libro de 2018 In Defense of Troublemakers. Los grupos con disidentes toman mejores decisiones que los grupos que alcanzan un acuerdo rápido. El disidente no necesita tener razón. El acto de disentir obliga a la mayoría a examinar suposiciones que de otro modo pasarían por alto.5
The Wisdom of Crowds de James Surowiecki identifica cuatro condiciones para decisiones grupales sabias: diversidad de opinión, independencia de juicio, descentralización y un mecanismo de agregación.6 Si se viola la independencia (permitir que los agentes vean el trabajo de los demás durante la investigación), se obtiene comportamiento de manada. Si se viola la diversidad (usar prompts idénticos para cada agente), se obtienen cámaras de eco.
Probé la condición de independencia directamente. Dos agentes evaluando la misma estrategia de despliegue con visibilidad de los hallazgos del otro: el Agente A puntuó el riesgo en 0,45. El Agente B vio esa puntuación y produjo 0,48. Los mismos agentes sin visibilidad: 0,45 y 0,72. La brecha entre 0,48 y 0,72 es el costo del comportamiento de manada. La evaluación independiente del Agente B señaló un riesgo de orquestación de contenedores que desapareció cuando la presión social entró en la evaluación.
Trabajos recientes confirman que ambos patrones se mantienen para agentes LLM. Choi et al. en NeurIPS 2025 encontraron que la votación por mayoría entre agentes con prompts independientes captura la mayor parte de las ganancias de calidad de los sistemas multi-agente.7 Kaesberg et al. en ACL 2025 cuantificaron la división: la votación mejora las tareas de razonamiento en un 13,2%, mientras que los protocolos de consenso mejoran las tareas de conocimiento en un 2,8%.8 Esto sugiere que la elección debería depender del tipo de tarea. Por eso mi sistema utiliza umbrales adaptativos según la tarea en lugar de un número único de consenso.
Wu et al. probaron si los agentes LLM pueden genuinamente debatir y encontraron que sin incentivos estructurales para el desacuerdo, los agentes convergen hacia la respuesta inicial que suena más segura, independientemente de su corrección.9 Wynn et al. fueron más lejos: el debate puede ser activamente perjudicial. Los modelos cambian de respuestas correctas a incorrectas en respuesta al razonamiento de sus pares, incluso cuando los modelos más fuertes superan en número a los más débiles.10 Liang et al. identificaron la causa raíz como “Degeneración del Pensamiento”: una vez que un LLM establece confianza en una posición, la autorreflexión no puede generar contraargumentos novedosos, haciendo la evaluación multi-agente estructuralmente necesaria.11
Mi sistema aborda la independencia mediante el aislamiento de contexto (las capas L2 son privadas del agente durante la investigación). La diversidad proviene de 10 personas distintas con diferentes prioridades de evaluación. La agregación utiliza puntuación ponderada en 5 dimensiones en lugar de votación simple. El incentivo estructural para el desacuerdo es más débil: registro si la disidencia está documentada pero no recompenso a los agentes por disentir. El módulo de detección de conformidad intenta abordar esta brecha, con resultados mixtos.
Detectando el Desacuerdo Falso
El módulo de conformidad rastrea patrones que sugieren que los agentes están de acuerdo sin una evaluación genuina. Preocupaciones documentadas que repiten el mismo lenguaje entre agentes, puntuaciones que se agrupan sospechosamente cerca del umbral, o apoyo unánime de todas las personas (un Analista de Seguridad y un Ingeniero de Rendimiento rara vez están de acuerdo en todo) activan advertencias.
Lo que detecta: disidencia formulaica (agentes copiando el lenguaje de preocupación de los demás), agrupamiento de puntuaciones (cada agente puntuando dentro de 0,3 puntos en una escala de 10 puntos) y perspectivas minoritarias ausentes (aprobación unánime de personas con prioridades conflictivas).
Un ejemplo de mis registros: cinco agentes evaluaron una refactorización de autenticación. Los cinco puntuaron el riesgo de seguridad entre 7,1 y 7,4. El detector de conformidad señaló el agrupamiento. Cuando volví a ejecutar con aislamiento de contexto fresco (limpiando cachés L2), las puntuaciones se distribuyeron entre 5,8 y 8,9. El agrupamiento original reflejaba contaminación de contexto compartido, no un acuerdo genuino.
Lo que no detecta: acuerdo sofisticado donde los agentes genuinamente evalúan desde la perspectiva de su persona pero llegan a la misma conclusión por diferentes razones. El módulo no puede distinguir consenso real del comportamiento de manada cuando el razonamiento parece independiente. Intenté entrenar un clasificador con ejemplos de acuerdo genuino vs. fabricado, pero los datos de entrenamiento eran muy pocos (menos de 50 sesiones de deliberación) y la señal demasiado débil. El detector de conformidad detecta los casos obvios y omite los sutiles.
La evaluación honesta: la detección de conformidad añade una verificación de cordura útil en el 10-15% de las deliberaciones donde los agentes convergen demasiado rápido. Para el otro 85-90%, las puertas de consenso y pride check proporcionan validación suficiente. Consideré construir un sistema de conformidad más sofisticado y decidí que el esfuerzo de ingeniería no correspondería con la mejora marginal.
Lo Que No Funcionó
Callejón Sin Salida 1: Rondas de Debate de Forma Libre
La primera versión tenía agentes escribiendo refutaciones extensas a los hallazgos de los demás: 3 rondas de texto de ida y vuelta. Vi una deliberación sobre estrategia de indexación de base de datos desarrollarse en 7.500 tokens de debate. Ronda 1: desacuerdo genuino sobre índices compuestos vs. de columna única. Ronda 2: posiciones reiteradas con elaboración menor. Ronda 3: argumentos casi idénticos envueltos en palabras diferentes. La señal alcanzó su pico en la ronda 1 y se degradó a partir de ahí.
El costo en tokens por deliberación llegó a $2-4, y la densidad de información útil disminuyó con cada ronda. La solución: la puntuación estructurada por dimensiones reemplazó el debate de forma libre. Los agentes puntúan propuestas en 5 dimensiones con valores numéricos en lugar de escribir ensayos. El costo y el tiempo se redujeron aproximadamente un 60%, y la calidad del ranking final mejoró porque las puntuaciones numéricas fuerzan una precisión que la prosa oscurece.
Callejón Sin Salida 2: Recursión Basada en Profundidad para la Deliberación
El incidente de generación infinita expuso un error fundamental de modelado. La protección contra recursión rastreaba profundidad: padre en profundidad 0 genera hijo en profundidad 1, hijo genera nieto en profundidad 2, profundidad máxima 3. Pero los agentes de deliberación deberían expandirse en amplitud (10 agentes de investigación en el mismo nivel), no en profundidad (un agente generando un hijo que genera un nieto). El límite de profundidad de 3 nunca se activó porque 23 agentes en profundidad 1 sigue siendo “profundidad 1.”
La solución fue un modelo de presupuesto de generación: los agentes de deliberación heredan la profundidad del padre en lugar de incrementarla, y comparten un presupuesto total de generación de hijos limitado a 12. El modelo de presupuesto se ajusta al modo de fallo real (demasiados agentes totales) en lugar de una métrica proxy (demasiados niveles de anidamiento). El linaje de agentes se rastrea en un archivo JSON para que el presupuesto persista entre las finalizaciones asíncronas de agentes.12
Callejón Sin Salida 3: Una Sola Puerta de Validación
La primera implementación ejecutaba un solo hook de validación al final de la sesión, combinando verificaciones de consenso con verificaciones de calidad. El modo de fallo apareció durante la primera semana. Un agente completó la deliberación con una puntuación de consenso de 0,52, por debajo del umbral de 0,70. Luego continuó con tareas no relacionadas durante 20 minutos antes de que el hook de fin de sesión señalara el fallo. Veinte minutos de trabajo construidos sobre una base que no había pasado la validación.
Dividir en dos puertas corrigió el problema de sincronización. La Puerta 1 (validación de consenso) se ejecuta como un hook PostToolUse:Task, detectando mal consenso inmediatamente después de que el agente de deliberación completa. La Puerta 2 (pride check) se ejecuta al final de la sesión, detectando problemas de calidad que se acumularon a lo largo de los pasos. Dos hooks en diferentes puntos del ciclo de vida coinciden con cómo ocurren realmente los fallos: algunos son instantáneos (mala puntuación) y otros son graduales (baja diversidad, documentación de disidencia faltante).
Las Matemáticas Honestas
La deliberación cuesta tokens. Cada agente de investigación procesa aproximadamente 5.000 tokens de contexto y genera 2.000-3.000 tokens de hallazgos. Con 3 agentes (mínimo para una deliberación útil) son 15.000-24.000 tokens adicionales por decisión. Con 10 agentes (panel completo de investigación), aproximadamente 50.000-80.000 tokens.
A precios de Opus ($15/$75 por millón de tokens), una deliberación de 3 agentes cuesta aproximadamente $0,68-0,90. Una deliberación de 10 agentes cuesta $2,25-3,00. Mi sistema activa la deliberación en aproximadamente el 10% de las decisiones (aquellas con puntuación por debajo de 0,70 de confianza), por lo que el costo amortizado en todas las decisiones es de $0,23-0,30 por sesión.
Si eso vale la pena depende de lo que cueste una mala decisión. Una vulnerabilidad de seguridad no detectada en un despliegue a producción cuesta horas de respuesta a incidentes. Una mala elección de arquitectura cuesta semanas de refactorización. Un error tipográfico en la documentación no cuesta nada.
El módulo de confianza determina qué decisiones activan la deliberación. Cuatro dimensiones (ambigüedad, complejidad, impacto y dependencia del contexto) cada una produce una puntuación de 0-1. Múltiples dimensiones necesitan puntuar alto para que la confianza general caiga por debajo de 0,70 y active la deliberación. Los problemas de una sola dimensión (“esto es complejo pero no ambiguo”) se mantienen por encima del umbral y omiten la deliberación.13
Dos Agentes, Una Regla
No necesita 10 personas de investigación, 8 módulos Python ni 141 pruebas para obtener valor de la deliberación multi-agente. Comience con 2 agentes y 1 regla: los agentes deben evaluar de forma independiente antes de ver el trabajo del otro.
Deliberación Mínima Viable
Decision arrives
|
v
Confidence check: is this risky, ambiguous, or irreversible?
|
├── NO -> Single agent decides (normal flow)
|
└── YES -> Spawn 2 agents with different system prompts
Agent A: "Argue FOR this approach"
Agent B: "Argue AGAINST this approach"
|
v
Compare findings
|
├── Agreement with different reasoning -> Proceed
├── Genuine disagreement -> Investigate the conflict
└── Agreement with same reasoning -> Suspect herding
El diagrama de flujo de decisión anterior cubre el 80% del valor. Aquí está la implementación mínima:
# Minimum viable deliberation: 2 agents, 1 rule
def deliberate(decision_description):
agent_for = spawn_agent(
f"Argue FOR this approach: {decision_description}",
persona="advocate"
)
agent_against = spawn_agent(
f"Argue AGAINST this approach: {decision_description}",
persona="critic"
)
if same_reasoning(agent_for, agent_against):
return "WARNING: Suspect herding. Verify independently."
elif genuine_conflict(agent_for, agent_against):
return "Investigate the specific disagreement."
else:
return "Proceed. Independent agreement with different reasoning."
Todo lo demás añade mejoras incrementales: el ranking de 5 dimensiones, los umbrales adaptativos según la tarea, la detección de conformidad. La idea central sigue siendo simple: dos perspectivas independientes detectan fallos que una sola perspectiva no detecta.
Agente Único vs. Multi-Agente: Qué Cambia
| Escenario | Agente Único | Deliberación Multi-Agente |
|---|---|---|
| Revisión de seguridad | “La arquitectura se ve limpia” | Agente A: “Limpia.” Agente B: “Falta limitación de tasa en admin” |
| Diseño de esquema | “Normalizado a 3NF” | Agente A: “Limpio.” Agente B: “Joins de 4 tablas en cada lectura” |
| Actualización de dependencia | “Las pruebas pasan, desplegar” | Agente A: “Las pruebas pasan.” Agente B: “El changelog muestra cambio de API incompatible en v3” |
| Actualización de documentación | “README actualizado” | Todos los agentes coinciden (omisión correcta, por debajo del umbral de confianza) |
Qué Deliberar
| Deliberar | Omitir |
|---|---|
| Arquitectura de seguridad | Errores tipográficos en documentación |
| Diseño de esquema de base de datos | Renombrado de variables |
| Cambios en contratos de API | Actualizaciones de mensajes de log |
| Estrategias de despliegue | Reformulación de comentarios |
| Actualizaciones de dependencias | Actualizaciones de fixtures de pruebas |
Probando la Deliberación
El sistema ejecuta 141 pruebas en tres capas:14
- 48 pruebas de integración bash: Validación de sintaxis de hooks, flujo de consenso, puertas de pride check, cumplimiento de protección contra recursión y compatibilidad entre configuraciones
- 81 pruebas unitarias Python: Los 7 módulos de biblioteca (máquina de estados, confianza, aislamiento de contexto, ranking, agentes, conformidad, generación de PRD)
- 12 pruebas de extremo a extremo: Simulación completa del pipeline desde la evaluación de confianza hasta la salida del PRD
Probar un sistema diseñado para producir desacuerdo requiere probar dos categorías. El camino feliz: los agentes discrepan productivamente y alcanzan consenso. Los caminos de fallo: los agentes convergen demasiado rápido, nunca convergen o exceden los presupuestos de generación. Las pruebas E2E simulan cada escenario con respuestas deterministas de agentes, verificando que las dos puertas detecten cada modo de fallo documentado.
Comience con el patrón de 2 agentes. Añada complejidad cuando la versión de 2 agentes falle en algo específico. Cada agente, umbral y puerta de validación adicional en mi sistema existe porque la versión más simple falló en una tarea específica. Sus fallos serán diferentes, y el sistema que construya para detectarlos debería reflejar sus fallos, no los míos.
Conclusiones Clave
- El acuerdo es el modo de fallo peligroso. Los agentes individuales no pueden cuestionar sus propias suposiciones. Dos agentes independientes con diferentes prioridades de evaluación detectan puntos ciegos estructurales que las puertas de calidad y la filosofía no pueden abordar.
- Dos puertas superan a una. La validación de consenso durante el proceso detecta problemas temprano. El pride check al final de la sesión detecta problemas que se acumularon a lo largo de los pasos. Dividir la validación en dos hooks en diferentes puntos del ciclo de vida coincide con cómo ocurren realmente los fallos.
- Delibere selectivamente. El módulo de confianza activa la deliberación en aproximadamente el 10% de las decisiones. Deliberar sobre todo desperdicia tokens. No deliberar sobre nada omite las decisiones donde las perspectivas independientes importan más.
Preguntas Frecuentes
¿Cuánto cuesta la deliberación multi-agente por decisión?
Una deliberación de 3 agentes cuesta aproximadamente $0,68-0,90 en tokens de API a precios de Opus (15.000-24.000 tokens adicionales). Un panel completo de 10 agentes cuesta $2,25-3,00. El sistema activa la deliberación en aproximadamente el 10% de las decisiones, por lo que el costo amortizado en todas las decisiones es de $0,23-0,30 por sesión de codificación.
¿Cada decisión necesita deliberación?
No. El módulo de confianza puntúa las decisiones en cuatro dimensiones (ambigüedad, complejidad, impacto, dependencia del contexto). Solo las decisiones con una puntuación general de confianza por debajo de 0,70 activan la deliberación, aproximadamente el 10% del total de decisiones. Las correcciones de documentación, los renombrados de variables y las ediciones rutinarias omiten la deliberación por completo. La arquitectura de seguridad, los cambios de esquema de base de datos y los despliegues irreversibles la activan consistentemente.
¿Puede funcionar con modelos diferentes a Claude?
Los principios arquitectónicos (evaluación independiente, votación estructurada, validación de dos puertas) se aplican a cualquier LLM capaz de seguir instrucciones de persona y producir salida estructurada. La implementación utiliza hooks de Claude Code y la herramienta Task para la generación de agentes, que es infraestructura específica de Claude. Portarlo a otro modelo requiere reemplazar el mecanismo de generación y las plantillas de prompts, manteniendo la máquina de estados, el sistema de ranking y las puertas de validación.
¿Cómo se prueba un sistema diseñado para producir desacuerdo?
141 pruebas en tres capas: 48 pruebas de integración bash verifican el comportamiento de los hooks (flujo de consenso, puertas de pride check, protecciones contra recursión), 81 pruebas unitarias Python cubren cada módulo de biblioteca con entradas deterministas, y 12 pruebas de extremo a extremo simulan pipelines completos de deliberación con respuestas fijas de agentes. Las pruebas E2E cubren tanto los caminos de éxito (desacuerdo productivo que alcanza consenso) como los caminos de fallo (acuerdo prematuro, fallo en converger, agotamiento del presupuesto).
¿Cuál es el impacto en latencia de la deliberación?
Una deliberación de 3 agentes añade 30-60 segundos de tiempo real (los agentes se ejecutan secuencialmente a través de la herramienta Task). Una deliberación de 10 agentes añade 2-4 minutos. Los hooks de consenso y pride check se ejecutan cada uno en menos de 200ms. El cuello de botella principal es el tiempo de inferencia del LLM por agente, no la sobrecarga de orquestación. Para las decisiones que ameritan deliberación, la latencia es aceptable porque la alternativa (descubrir el error después) cuesta significativamente más tiempo.
Referencias
-
Módulo de aislamiento de contexto de deliberación del autor. Implementación en
~/.claude/lib/deliberation/context_isolation.py. Cuatro niveles de aislamiento: L0 (reglas del sistema, compartido), L1 (contexto de sesión, compartido), L2 (enfoque del agente, privado), L3 (patrones de dominio, por persona). ↩ -
Configuración de deliberación del autor. Umbrales definidos en
~/.claude/configs/deliberation-config.json. ↩ -
Hook de consenso post-deliberación del autor. Implementación en
~/.claude/hooks/post-deliberation.sh, conectado a PostToolUse:Task. ↩ -
Heuer, Richards J., Psychology of Intelligence Analysis, Center for the Study of Intelligence, CIA, 1999. Capítulo 8: Analysis of Competing Hypotheses. Texto completo (CIA). ↩
-
Nemeth, Charlan, In Defense of Troublemakers: The Power of Dissent in Life and Business, Basic Books, 2018. Véase también: Nemeth, C. J., “Differential Contributions of Majority and Minority Influence,” Psychological Review, 93(1), 23-32, 1986. ↩
-
Surowiecki, James, The Wisdom of Crowds: Why the Many Are Smarter than the Few, Doubleday, 2004. Capítulo 1. ↩
-
Choi, H. K., Zhu, X., y Li, S., “Debate or Vote: Which Yields Better Decisions in Multi-Agent Large Language Models?” NeurIPS 2025 Spotlight. arXiv:2508.17536. ↩
-
Kaesberg, L. B. et al., “Voting or Consensus? Decision-Making in Multi-Agent Debate,” Findings of ACL 2025, pp. 11640-11671. ACL Anthology. ↩
-
Wu, H., Li, Z., y Li, L., “Can LLM Agents Really Debate? A Controlled Study of Multi-Agent Debate in Logical Reasoning,” arXiv:2511.07784, 2025. ↩
-
Wynn, A., Satija, H., y Hadfield, G., “Talk Isn’t Always Cheap: Understanding Failure Modes in Multi-Agent Debate,” arXiv:2509.05396, 2025. ↩
-
Liang, T. et al., “Encouraging Divergent Thinking in Large Language Models through Multi-Agent Debate,” EMNLP 2024, pp. 17889-17904. ACL Anthology. ↩
-
Protección contra recursión del autor. Modelo de presupuesto de generación en
~/.claude/hooks/recursion-guard.sh. Linaje de agentes rastreado en~/.claude/state/agent-lineage.json. ↩ -
Módulo de confianza del autor. Implementación en
~/.claude/lib/deliberation/confidence.py. Cuatro dimensiones: ambigüedad, complejidad, impacto, dependencia del contexto. ↩ -
Suite de pruebas del autor. 48 pruebas bash en
~/.claude/tests/test-deliberation-pipeline.sh, 81 pruebas Python en~/.claude/tests/test_deliberation_lib.py, 12 pruebas E2E en~/.claude/tests/test_deliberation_e2e.py. ↩