Proponer, criticar, verificar: cuándo un panel de agentes le gana a un solo prompt bien armado

El razonamiento de un solo prompt falla en silencio. Le pides a un modelo, en una sola pasada, que sopese una concesión difícil; y te devuelve una respuesta segura y bien redactada que está equivocada de una forma que no vas a notar hasta que te cueste algo. Este texto va sobre la alternativa, un panel de proponer/criticar/verificar, y, igual de importante, sobre saber cuándo ese panel es matar moscas a cañonazos. Al final vas a tener un bucle de orquestación concreto, las tres técnicas que todo el mundo confunde y una cuenta honesta de lo que de verdad te cuesta un panel.

01 · La falla que nadie enseña en el demo

Una sola pasada se casa con un encuadre temprano y se gasta el resto de los tokens defendiéndolo. No hay un adversario interno. Los mismos pesos que generaron la afirmación generan también la justificación, así que la justificación es aduladora por diseño. No estás recibiendo verificación: estás recibiendo una sola opinión con saco y corbata.

Para tareas de bajo riesgo y bien definidas, eso está perfecto. Renombra estas variables. Resume este correo. Saca las fechas. Un buen prompt gana porque no hay ambigüedad real que resolver, y una respuesta equivocada es barata de detectar y más barata todavía de arreglar.

El lío empieza cuando la decisión es ambigua y cara de equivocar. ¿Aceptamos esta cláusula del contrato? ¿Esta arquitectura va a aguantar el próximo salto de escala? ¿Qué está optimizando de verdad la otra parte en esta negociación? Ahí una sola respuesta segura es un riesgo, porque la confianza y la corrección dejaron de ir de la mano: la prosa quedó más pulida mientras que el razonamiento no se volvió ni un poco más confiable.

02 · Lo que de verdad te da un panel

Un panel multiagente no es "más modelos, mejor". Es un pipeline con tres roles distintos, y los roles pesan muchísimo más que la cantidad.

1. Proponer. Uno o varios agentes generan respuestas candidatas. Súbeles la temperatura, o arranca cada uno con un encuadre distinto: "optimiza para costo", "optimiza para seguridad", "asume el caso optimista". La meta es diversidad de verdad, no tres formas de decir lo mismo.
2. Criticar. Un agente aparte, con otro system prompt y la consigna explícita de ser adversario, ataca cada propuesta. Su trabajo es encontrar la falla, no ser complaciente. Aquí se rompe la trampa del encuadre temprano, porque el crítico nunca se casó con la propuesta.
3. Verificar. Un agente final revisa a los sobrevivientes contra restricciones duras: ¿cita fuentes reales? ¿Cuadran los números? ¿Viola algún requisito que se haya declarado? La verificación es el paso más barato y el que más rinde, y es justo el que la gente se salta.

Esto funciona, y no por arte de magia. Funciona porque la correlación entre errores baja cuando separas el generar del evaluar. Una falla que el proponente no ve suele saltar a la vista de un crítico que arrancó de otro prompt. No estás volviendo más listo a ningún modelo; estás montando las cosas para que sus errores los agarre algo que no los comparte.

Esta es la columna vertebral de ThinkTank AI, nuestra plataforma de deliberación multiagente. La parte interesante de la ingeniería no es levantar agentes; eso es un for-loop. Es obligarlos a que discrepen de verdad, y después resolver el desacuerdo con algo que no sea pura intuición.

La diversidad es todo el juego

La manera más común en que un panel se degrada en silencio hasta volverse puro teatro es que todos los agentes compartan el mismo modelo base y un prompt casi idéntico. Ahí comparten los mismos puntos ciegos, se ponen de acuerdo con toda la seguridad del mundo y producen la ilusión de un consenso construido sobre un error compartido. La diversidad se compra a propósito: distintos encuadres, distintos system prompts y, a veces, modelos completamente distintos. Si no puedes explicar por qué dos agentes discreparían, no tienes dos agentes: tienes uno que pagaste dos veces.

03 · Debate, autoconsistencia y verificación adversaria

Hay tres técnicas que se usan como si fueran lo mismo, pero hacen trabajos distintos.

Autoconsistencia es la barata. Corres el mismo prompt N veces y te quedas con la respuesta mayoritaria. Funciona bien cuando la tarea tiene una respuesta discreta y comprobable (un número, una categoría, un sí o no) y el modelo acierta más de lo que falla. Para prosa abierta casi no sirve, porque no existe una "mayoría" limpia entre párrafos.

Debate pone a dos agentes en bandos opuestos y los deja intercambiar réplicas durante unas rondas, con un juez leyendo la transcripción. El valor no está en la pelea. Está en que el juez ve la objeción más fuerte contra cada postura puesta sobre la mesa de forma explícita, en lugar de tener que imaginarla. Limita las rondas a dos o tres. De ahí en adelante, los agentes empiezan a darse la razón para reducir fricción, que es exactamente la falla que querías evitar.

Verificación adversaria es en la que más confío para trabajo de alto riesgo. Le pasas al verificador una lista de afirmaciones falsables y le dices que tumbe cada una: no "¿esto está bien?", sino "encuentra la razón concreta por la que esto es falso". La crítica vaga es puro teatro. Una lista falsable obliga a trabajar de verdad, y te deja un rastro auditable que después le puedes mostrar a un humano.

04 · Un bucle que sí puedes correr

Aquí va una versión reducida del bucle en TypeScript. Corre el paso de proponer en paralelo, lanza las críticas en abanico y luego verifica de forma secuencial, dejando solo a los sobrevivientes.

type Verdict = { ok: boolean; reasons: string[] }

async function deliberar(pregunta: string): Promise<string> {
  // 1. Proponer: candidatos diversos desde distintos encuadres
  const encuadres = ["optimiza para costo", "optimiza para seguridad", "asume el peor caso"]
  const propuestas = await Promise.all(
    encuadres.map((e) => proponer(pregunta, e))
  )

  // 2. Criticar: un adversario ataca cada candidato
  const criticadas = await Promise.all(
    propuestas.map(async (p) => ({ propuesta: p, ataque: await criticar(pregunta, p) }))
  )

  // 3. Verificar contra restricciones falsables; deja solo a los que sobreviven
  const sobrevivientes: string[] = []
  for (const c of criticadas) {
    const v: Verdict = await verificar(pregunta, c.propuesta, c.ataque)
    if (v.ok) sobrevivientes.push(c.propuesta)
  }

  // 4. Sintetizar. Si nada sobrevive, escala a un humano.
  if (sobrevivientes.length === 0) return escalarAHumano(pregunta, criticadas)
  return sintetizar(pregunta, sobrevivientes)
}

Fíjate en la rama de escalar a un humano. Un panel que no logra llegar a una respuesta verificada debe decirlo, no escoger a un perdedor y maquillarlo. Esa rama no es un plan B: es la funcionalidad clave. El honesto "no pude verificar ninguna de estas" vale más que una respuesta equivocada y segura, porque manda el caso difícil al único lugar que de verdad puede hacerse cargo.

Un par de notas de producción que el bucle de juguete se salta:

• Acota el gasto. Envuelve cada llamada de agente con un presupuesto de tokens y de tiempo real. Sin un techo, una sola pregunta ambigua puede abrirse en abanico en un árbol caro y lento antes de que nadie se dé cuenta.
• Maneja el fallo parcial. Si una llamada de propuesta hace timeout, no abortes todo el panel: sigue con los candidatos que tengas y registra el hueco. Un panel con dos sobrevivientes le gana a un 500.
• Loguea el desacuerdo, no solo la respuesta. La transcripción de por qué se descartaron los candidatos suele ser más útil que el ganador, tanto para el debug como para el humano que hereda la escalación.

05 · Las concesiones, dichas con honestidad

Un panel cuesta más en todos los ejes que importan.

• Tokens. Tres propuestas, más sus críticas, más la verificación, pueden salir cinco a diez veces más caras que un solo prompt. Eso no es error de redondeo; a volumen te cambia la economía por unidad.
• Latencia. Aun paralelizando el paso de proponer, la cadena de criticar y luego verificar es secuencial. Los segundos se vuelven decenas de segundos, y eso muchas veces no se aguanta en un producto interactivo.
• Complejidad. Ahora cargas con un grafo de orquestación, lógica de reintentos, control de presupuesto y manejo de fallos parciales. Más piezas, más maneras de que algo se rompa, más que mantener seguro.
• Un modo de falla nuevo: el colapso de consenso. Si todos tus agentes comparten el mismo modelo base y un prompt parecido, comparten también los puntos ciegos, y el panel se pone de acuerdo con toda la seguridad del mundo mientras se equivoca en bloque. La diversidad forzada en el encuadre es lo que mantiene honesto al panel.

¿Cuándo es un panel matar moscas a cañonazos? La mayoría de las veces, para ser franco. Sáltatelo cuando la tarea está bien definida, cuando una respuesta equivocada es barata de corregir, cuando la latencia es el producto, o cuando un buen prompt con su chequeo de verificación ya da la talla. Echar mano de un sistema multiagente para algo que un solo prompt resuelve es el mismo error que montar Kubernetes para correr un cron. Usa el panel donde el costo de equivocarte con toda la seguridad aplasta el costo de los tokens de más, y en ningún otro lado.

Un chequeo rápido antes de armar uno: escribe, en una sola frase, lo que cuesta una respuesta equivocada. Si no puedes nombrar una consecuencia concreta, no necesitas un panel. Si la consecuencia es un contrato perdido, un incidente de seguridad o una migración que no puedes deshacer, ahí sí ya estamos hablando.

Un prompt bien armado optimiza para una buena respuesta; un panel optimiza para atrapar la mala. Son metas distintas, y cuál necesitas depende por completo de lo que cuesta un error. El patrón es simple: propón con diversidad, critica con un adversario, verifica contra restricciones falsables y escala cuando nada sobrevive. La disciplina está en reservarlo para las decisiones que de verdad lo ameritan, y confiar en un buen prompt para todo lo demás.