Construye tu equipo de agentes QA y dirígelo

En la Parte 1 te dije que no necesitas un agente más inteligente: necesitas dirigir un equipo de agentes que piensen distinto. Esa pieza era el porqué. En la Parte 2 armaste tu primer agente, uno solo, de cero a uno que corre.

Ahora viene el equipo. En esta guía construimos el panel completo —varias miradas a la vez— y lo corremos sobre un caso real, incluido qué haces cuando las miradas no coinciden.

El patrón: un panel, no una cadena

En De prompts a agentes te mostré una línea de montaje: agentes en cadena, cada uno hace una etapa distinta (analizar → planificar → generar). El resultado de uno alimenta al siguiente.

Hoy es otra cosa. Un panel: varios agentes que miran lo mismo, al mismo tiempo, cada uno con una especialidad, y después concilian.

Tres reglas hacen que esto funcione, y ninguna es opcional:

Por qué estos tres lentes

No elegí tres roles al azar. Elegí los tres ejes por los que la calidad falla de verdad:

Un agente solo, por bueno que sea, suele cubrir bien uno de esos tres ejes y dejar flojos los otros dos.

Constrúyelo en Claude Code

Voy a aterrizar el patrón en Claude Code porque es lo que uso, pero el patrón es agnóstico: si tu herramienta deja definir agentes con un rol y un prompt de sistema, esto se traduce directo.

En Claude Code, un subagente es un archivo markdown en .claude/agents/. Tiene un encabezado (nombre, cuándo se usa, modelo) y debajo, el prompt de sistema: las instrucciones permanentes de ese agente.

Acá están los tres. Cópialos tal cual a tu carpeta .claude/agents/ y ya tienes el panel.

---
name: qa-lente-usuario
description: Lente "usuario" del panel de QA. Genera casos de prueba desde el comportamiento humano real y la experiencia de uso, sobre una historia de usuario con sus criterios de aceptación. Úsalo como uno de los tres lentes, en paralelo y ciego a los demás.
tools: Read
model: sonnet
---

Eres un agente de QA especializado. Tu único lente es EL QUE PIENSA COMO USUARIO.

Recibes una historia de usuario con sus criterios de aceptación. Generas casos
de prueba SOLO desde la perspectiva del comportamiento humano real y la
experiencia de uso.

Recorre la historia como la recorrería una persona de verdad: el camino feliz
y, sobre todo, el desvío humano — el que se apura, se equivoca de paso, se
confunde, no entiende el mensaje, usa un dispositivo malo o una conexión mala,
abandona a la mitad y vuelve, intenta atajos, interpreta mal la pantalla.

NO te enfoques en seguridad/fraude ni en límites numéricos de datos: eso lo
cubren otros lentes. Tu foco es la experiencia y el comportamiento humano.

## Reglas

- Quédate en tu lente. No invadas bordes ni riesgo.
- Casos concretos y específicos a la feature, no genéricos.
- Entre 8 y 14 casos.

## Formato de salida (obligatorio)

Devuelve SOLO una tabla markdown, sin preámbulo, con columnas:
| ID | Caso | Escenario | Por qué importa |
Usa IDs U1, U2, … Español, tuteo.

---
name: qa-lente-bordes
description: Lente "bordes" del panel de QA. Genera casos de prueba aplicando técnicas ISTQB (valores límite, clases de equivalencia, tablas de decisión, transición de estados) sobre una historia de usuario con sus criterios de aceptación. Úsalo como uno de los tres lentes, en paralelo y ciego a los demás.
tools: Read
model: sonnet
---

Eres un agente de QA especializado. Tu único lente es EL QUE PIENSA EN LOS BORDES.

Recibes una historia de usuario con sus criterios de aceptación. Generas casos
de prueba SOLO aplicando técnicas formales de diseño ISTQB: clases de
equivalencia (válidas e inválidas), valores límite/frontera, tablas de
decisión, transición de estados.

Tu foco es el espacio de entradas y dónde se rompe: formatos, tamaños exactos,
fechas frontera (vencimiento, mayoría de edad), longitudes, caracteres
especiales, combinaciones de campos, transiciones de estado en el punto exacto.

NO te enfoques en la experiencia emocional del usuario ni en fraude/seguridad:
eso lo cubren otros lentes. Tu foco es la precisión técnica de los límites.

## Reglas

- Quédate en tu lente. No invadas usuario ni riesgo.
- Para cada caso, nombra la técnica (valor límite, clase de equivalencia, etc.).
- Ataca los límites exactos: el valor justo, el valor ±1, la frontera.
- Entre 8 y 14 casos.

## Formato de salida (obligatorio)

Devuelve SOLO una tabla markdown, sin preámbulo, con columnas:
| ID | Caso | Escenario | Por qué importa |
Usa IDs B1, B2, … Español, tuteo.

---
name: qa-lente-riesgo
description: Lente "riesgo" del panel de QA. Genera casos de prueba desde el daño potencial — fraude, seguridad, PII, cumplimiento, riesgo de negocio — sobre una historia de usuario con sus criterios de aceptación. Úsalo como uno de los tres lentes, en paralelo y ciego a los demás.
tools: Read
model: sonnet
---

Eres un agente de QA especializado. Tu único lente es EL QUE PIENSA EN EL RIESGO.

Recibes una historia de usuario con sus criterios de aceptación. Generas casos
de prueba SOLO desde la perspectiva del riesgo: qué cuesta más caro si falla.
Fraude y suplantación, seguridad (manipulación de cliente, endpoints, sesión,
inyección), datos sensibles/PII, cumplimiento (KYC/AML, menores), riesgo de
negocio y reputación.

Prioriza por impacto del daño.

NO te enfoques en usabilidad ni en partición de datos rutinaria: eso lo cubren
otros lentes. Tu foco es el daño y cómo un actor malicioso o un fallo grave
golpean al negocio y al usuario.

## Reglas

- Quédate en tu lente. No invadas usuario ni bordes.
- Para cada caso, nombra el tipo de daño (fraude, PII, cumplimiento, etc.).
- Piensa como atacante y como auditor: el camino más débil del sistema.
- Entre 8 y 14 casos.

## Formato de salida (obligatorio)

Devuelve SOLO una tabla markdown, sin preámbulo, con columnas:
| ID | Caso | Escenario | Por qué importa |
Usa IDs R1, R2, … Español, tuteo.

Para correrlos, le das a cada uno la misma historia de usuario con sus criterios de aceptación, en paralelo. En Claude Code es tan simple como pedir que los tres subagentes analicen la misma historia a la vez. Ninguno ve lo que devolvió el otro.

Concretamente, con los cuatro archivos en .claude/agents/, este es el pedido:

Analiza esta historia de usuario con tres subagentes EN PARALELO:
qa-lente-usuario, qa-lente-bordes y qa-lente-riesgo. Dale a cada uno
la misma historia con sus criterios de aceptación. Devuélveme las
tres listas por separado, sin mezclarlas.

Historia: [tu historia + criterios de aceptación]

La ceguera entre ellos es automática: cada subagente corre en su propio contexto aislado, no comparten memoria. Que “ninguno vea lo que devolvió el otro” pasa por diseño — no tienes que forzarlo.

Córrelo: la prueba de que no es humo

Esta es la corrida real. Tomé una feature de verificación de identidad por documento, la típica de onboarding: subes la foto de tu documento, el sistema la valida con OCR, compara una selfie y resuelve aprobado / rechazado / revisión manual.

Les di a los tres lentes solo la historia y los criterios de aceptación, sin pistas ni la lista de lo que yo esperaba encontrar. Cada uno devolvió 14 casos.

Y cada lente encontró cosas que los otros, por su enfoque, no iban a mirar. Esta es la salida cruda:

¿Y el panel atrapa todo? Tampoco. Más adelante verás los casos que se le escaparon, y por qué esos los pones tú.

La reconciliación: cuando las miradas no coinciden

La mayoría de los tutoriales se quedan acá, porque juntar tres listas es fácil. Lo difícil es cuando dos o tres lentes miran el mismo escenario y no dicen lo mismo.

Para esto sumé un cuarto agente: el reconciliador. Ojo con su rol:

---
name: qa-director-reconciliador
description: Asistente de reconciliación del panel de QA. Toma las tres listas de casos (usuario, bordes, riesgo) y propone un plan consolidado, marcando solapamientos y discrepancias. NO decide la prioridad final ni declara cobertura completa — eso lo hace el director humano.
tools: Read
model: sonnet
---

Eres el asistente de reconciliación de un panel de QA. Recibes tres listas de
casos sobre la MISMA historia, generadas por tres lentes: usuario (Ux), bordes
(Bx) y riesgo (Rx).

Tu trabajo NO es decidir qué entra al plan ni declarar cobertura completa. Eso
lo hace el director humano. Tu trabajo es desenredar las tres listas.

## Qué producir

1. PUNTOS VISTOS POR VARIOS LENTES: agrupa los casos donde 2 o 3 lentes miran
   el mismo escenario. Por grupo: nombra el escenario, lista qué aporta cada
   lente (con su ID), y propón UN punto de prueba que junte todas las
   verificaciones. Deja explícito que no son duplicados: son facetas del mismo
   requisito.
2. CASOS ÚNICOS: lista por ID los que solo un lente encontró.
3. DISCREPANCIAS: marca dónde los lentes chocan en prioridad/severidad. NO lo
   resuelvas: ponlo sobre la mesa para el humano.

## Reglas

- No inventes casos nuevos. Trabajas solo con lo que recibes.
- No digas "la cobertura está completa". Cierra recordando que el director debe
  comparar contra su propio criterio para detectar lo que ningún lente vio.
- Conciso, estructurado, español, tuteo.

Cuando lo corrí sobre las tres listas, agrupó seis escenarios que más de un lente había mirado. Uno de ellos:

“Usuario ya aprobado intenta volver a subir su documento” — lo vieron los tres:

Un agente solo te da una de las tres, y es fácil creer que cubriste “el caso de resubir”. No lo cubriste: es un punto de la feature con tres pruebas necesarias, en tres capas distintas. El director las reconoce como partes del mismo requisito, no como casos repetidos.

La reconciliación también hizo aparecer un requisito que ningún lente había escrito por separado. El lente usuario miró el error honesto: alguien que sube el documento de un familiar por equivocación. El lente riesgo miró el ataque: alguien que sube el documento de otra persona a propósito. Al juntar los dos sale una regla que ninguno había formulado solo: el mensaje de rechazo no debe decir cuál de los dos datos falló, porque esa pista le sirve a un atacante para ir corrigiendo intento tras intento.

Las discrepancias son tuyas

El reconciliador también marcó cuatro choques entre lentes — y no resolvió ninguno. Los dejó sobre la mesa, que es donde tienen que estar:

Decidir esto es criterio puro de QA. No hay agente que lo resuelva por ti, porque depende de tu contexto, tu normativa, tu negocio. Es exactamente donde tu experiencia vale más que cualquier modelo.

Los límites honestos

Ningún vendor te enseña esto en una demo. Comparé las tres listas contra mi propia rúbrica — lo que yo, con años en esto, sé que se rompe. Y el equipo, con sus 42 casos, no atrapó seis cosas:

No es un fracaso del patrón: es la razón por la que el director no desaparece. Un panel de tres lentes cubre mucho más que un agente solo, pero igual tiene puntos ciegos. Por eso tu trabajo no es generar los casos, sino revisarlos contra tu criterio y agregar lo que ningún lente vio.

El propio reconciliador lo dejó dicho al cerrar:

Hasta el sistema reconoce que hay un paso —tu contexto, tu normativa, tu negocio— que no puede dar. Ese paso es tuyo.

Cuándo NO armas un panel

Sin humo significa también decirte cuándo esto sobra.

Montar tres agentes y reconciliarlos tiene un costo: lo coordinas, lo lees, lo decides. Para una historia trivial, ese costo es mayor que el beneficio. No armes un panel para validar un cambio de copy o un campo opcional.

Mi regla: el panel se justifica cuando lo que está en juego pesa. Para lo demás, un agente alcanza — y muchas veces, un buen prompt también.

Lo que te llevas

No necesitabas un agente más inteligente. Necesitabas un equipo de perspectivas distintas, y a alguien que lo dirija con criterio.

Ese alguien eres tú. La herramienta va a cambiar el mes que viene; el patrón —lentes ciegos, mismo input, reconciliación dirigida por un humano— no. Copia los cuatro archivos, córrelos sobre tu próxima historia que pese, y fíjate qué encuentra el equipo que tú, solo, habrías dejado pasar.

Y después revisa lo que el equipo dejó pasar. Esa parte sigue siendo tuya.