Refiner, Implementer, Verifier: un workflow práctico multiagente
En el artículo anterior de esta serie describía la especificación como el contrato que debería existir antes de que un agente escriba una sola línea de código. Lo que no conté fue cómo ejecutar de verdad los tres roles que usan ese contrato — Refiner, Implementer, Verifier — como algo más que tres roles que debéis adoptar simultáneamente durante una sesión larga.
Etiquetar secciones de un mismo prompt no es lo mismo que separar roles
Durante un tiempo, ejecuté los tres roles dentro de una única conversación: "convierte esto en una especificación, impleméntalo y luego verifícalo". Mismo contexto, mismo hilo continuo, solo tres encabezados en un prompt largo.
No funcionó como esperaba. El paso de refinar iba con prisas — el modelo claramente quería llegar a la parte de escribir código, así que trataba la especificación como un trámite en lugar de hacer un correcto razonamiento sobre la petición. Y el paso de verificación, ejecutado justo después de que el mismo agente hubiese terminado de implementar, era sospechosamente condescendiente. Tenía, estructuralmente, todos los incentivos para concluir que su propio trabajo estaba bien.
La solución no fue redactar mejor. Fue darle a cada rol su propio contexto separado — una invocación de subagente nueva, no un párrafo más en la misma conversación. En el momento en que el Refiner no tenía ni idea de cómo acabaría siendo la implementación, y el Verifier no tenía memoria de lo difícil que había sido implementar, los dos se volvieron notablemente más honestos.
Refiner Agent: solo lee y escribe la especificación
El Refiner recibe la petición original y el contexto de proyecto que necesita para entender qué se está pidiendo — no cómo se va a construir. Su única salida es la especificación descrita en el artículo anterior: objetivo, criterios de aceptación, casos esquina, dependencias, restricciones, fuera de alcance.
Lo que nunca debería hacer es proponer en silencio un enfoque de implementación. "Usaré un patrón repository aquí" no es una decisión que le corresponda al Refiner. Si la petición es genuinamente ambigua — dos lecturas válidas, sin forma de saber cuál es la buena — su trabajo es decirlo explícitamente, no elegir la más plausible y seguir adelante.
Por eso el punto de aprobación humana va justo después de este paso: detectar una ambigüedad aquí cuesta una frase. Detectarla tres pasos más tarde cuesta una reescritura.
Implementation Agent: lee la especificación, nunca la reescribe
Una vez aprobada la especificación, el Implementation Agent la recibe junto con el harness — el AGENTS.md, las skills relevantes, la arquitectura y los permisos ya establecidos. Su trabajo es construir exactamente lo que se ha especificado.
Si la especificación parece incorrecta o incompleta una vez empieza la implementación — y pasa —, lo correcto no es reinterpretarla en silencio y seguir adelante. Es parar y señalarlo. Un Implementation Agent que amplía el alcance "ayudando" o rellena un hueco de la especificación por su cuenta acaba de recrear exactamente el problema que Spec-Driven Development existe para evitar, un nivel más abajo.
Verification Agent: nunca se fía de lo que cuenta el Implementation Agent
Este es el rol donde más importa un contexto separado. El Verifier recibe la especificación y el diff real — no el resumen del Implementation Agent sobre lo que hizo, ni su explicación de por qué un atajo estaba bien.
Comprueba el resultado contra cada criterio de aceptación de forma individual, ejecuta o propone los tests que importan, y busca específicamente riesgos, deuda técnica y los casos esquina que señalaba la especificación. No tiene memoria de lo difícil que fue la tarea, ni ningún interés en que la implementación sea buena — que es exactamente lo que lo hace útil. Un agente que recuerda haber escrito el código ya ha decidido, hasta cierto punto, que el código está bien.
Evitar que los roles se mezclen entre sí
Los tres patrones de fallo con los que más me encuentro:
- El Refiner colando opiniones de implementación en lugar de quedarse en lo que se está pidiendo.
- El Implementation Agent "arreglando" o recortando en silencio la lista de casos esquina de la especificación en lugar de señalar el desajuste.
- El Verifier siendo indulgente porque tiene contexto de lo difícil que fue el trabajo — algo que no debería tener en primer lugar.
Ninguno de estos se arregla pidiendo las cosas más educadamente. Se arreglan acotando el contexto de cada agente a solo lo que su rol necesita, y escribiendo límites explícitos — no solo lo que cada rol debe hacer, sino lo que no tiene permitido decidir.
No necesitáis los tres siempre
Estos roles son útiles por sí solos, no solo como etapas de un pipeline.
A veces ejecuto solo el Refiner — para convertir una idea a medio formar y desordenada en algo revisable antes de dársela a nadie, humano o agente. A veces ejecuto solo el Verifier — para auditar código existente del que nadie se fía del todo, sin tocar ni una línea. Ninguno de los dos necesita a los otros dos para merecer la pena.
Conclusión
Un harness define el entorno. Un orquestador define la secuencia. Esta es la parte que realmente hace el trabajo dentro de cada etapa — y solo se sostiene si cada rol tiene su propio contexto, sus propios límites, y ningún acceso a los atajos que tomaron los demás.
En el próximo artículo de esta serie me centraré en la pieza que ata todo esto: Human-in-the-Loop AI Development — cuándo dejar que el pipeline avance solo, cuándo insistir en detenerlo, y cómo notar la diferencia antes de que os cueste algo.
Hasta entonces, la pregunta que merece la pena hacerse sobre vuestra propia configuración no es:
¿Tengo un Refiner, un Implementer y un Verifier?
Es:
¿Alguno de ellos todavía sabe cosas que no debería?
Si estáis ejecutando algo parecido a esto, me gustaría saber por dónde se filtran de verdad los límites entre vuestros agentes — no dudéis en escribirme.