¿Cómo se organiza una fábrica de agentes gobernados? Con tres piezas: cada agente entra por un rol, ese rol carga un paquete de skills, y el trabajo solo avanza cuando cruza una compuerta de madurez. Fuera de eso no hay magia ni improvisación. Hay una línea de producción con puestos, herramientas y controles de calidad, igual que cualquier fábrica seria.
Durante un tiempo hicimos lo que hace casi todo el mundo: pedirle a la IA "a ver qué sale". Eso tiene nombre, se llama vibe coding, y funciona hasta que necesitas repetir el resultado, auditarlo o poner a varios agentes a trabajar juntos sin pisarse. Ahí se cae. La fábrica Qirava nació para reemplazar esa improvisación por un método: primero la especificación, luego la ejecución.
01 · el planoPrimero la spec, después el agente
El método se llama SDD, Spec-Driven Development, desarrollo guiado por especificación. La regla es simple y no admite atajos: antes de que un agente toque nada, existe una spec que dice qué hay que hacer, con qué criterios se considera hecho y qué límites no se cruzan. La spec no es documentación que se escribe después. Es el plano que se escribe antes, y es quien gobierna al agente.
Esto no es una manía nuestra. Amazon lleva más de veinte años trabajando "hacia atrás" (working backwards): antes de construir un producto, escriben la nota de prensa y el FAQ como si ya existiera, y solo si ese documento convence, se ejecuta [1]. La comunidad de ingeniería con IA ha llegado al mismo lugar por otro camino: herramientas como GitHub Spec Kit formalizan que la especificación, no el prompt improvisado, sea la fuente de la que sale el código [2].
Un prompt improvisado produce una sorpresa. Una spec produce un resultado que puedes repetir.
02 · los puestosCada rol carga su paquete de skills
En una fábrica nadie hace de todo. Hay puestos. En la fábrica Qirava, cada agente entra por un rol, y ese rol define qué sabe hacer y qué no puede tocar. Lo hace cargando un paquete de skills con cuatro capas: una skill universal que todos comparten (el gobierno común, qirava-llm-governance), una skill primaria propia del rol, skills secundarias de apoyo, y una lista de skills prohibidas que ese rol no puede invocar aunque quiera.
Esa última capa es la que casi nadie pone y la que más protege. No basta con decirle a un agente qué puede hacer; hay que decirle qué tiene vetado. El agente de marketing no despliega código. El de QA no aprueba su propio release. El límite es parte del diseño, no una corrección posterior.
| Rol (agente) | Universal | Primaria | Prohibido |
|---|---|---|---|
| natalia.marketing.ai | gobernanza | marketing/SEO | desplegar, aprobar releases |
| santiago.architect.ai | gobernanza | arquitectura | certificar QA, firmar legal |
| sofia.qa-sprint.ai | gobernanza | validación de sprint | aprobar su propio trabajo |
| martin.legal.ai | gobernanza | legal | escribir código de producto |
| beatriz.ciso.ai | gobernanza | seguridad | saltar compuertas por urgencia |
| marcos.scrum.ai | gobernanza | facilitación de sprint | decidir alcance de producto |
| libaniel.ceo.human | gobernanza | decisión y aprobación | (humano: aprueba las compuertas) |
A un agente no lo defines por lo que puede hacer. Lo defines por lo que le prohíbes.
Hay un detalle que sostiene todo esto: la fuente documental de verdad es un DOCUMENT_INDEX, un índice único. Las skills viven en un toolkit, el gobierno vive en un vault, y los agentes los consumen por symlink en lugar de copiar. Así, cuando cambia una regla, cambia en un solo lugar y todos los agentes la heredan. No hay diez versiones del gobierno flotando por ahí.
03 · los controlesCompuertas de madurez: nada avanza sin cruzar la suya
Tener roles y skills no basta. Falta el control de calidad, y aquí es donde la fábrica se vuelve fábrica de verdad. Todo lo que produce un agente atraviesa cuatro compuertas de madurez, y no pasa a la siguiente sin cumplir la anterior:
G0, especificada. Existe la spec. Sin plano no arranca nada. G1, borrador. El agente produjo una propuesta y pasó la validación básica. G2, operativa. El CEO aprobó: recién aquí el trabajo puede tocar la realidad. G3, consejo. Lo que ya opera y merece elevarse a decisión de consejo. Cada salto es una compuerta con un dueño, y la más importante, G2, la aprueba una persona.
Aquí está el principio que evita el desastre más común con agentes: los borradores deliberan, pero no simulan ejecución. Deliberar es proponer, evaluar y decidir. Ejecutar es hacer el cambio real. Un agente en G1 puede argumentar hasta el cansancio por qué habría que desplegar algo, pero no despliega nada. Esa línea, entre pensar en voz alta y actuar, es lo que separa una fábrica gobernada de un enjambre de bots haciendo cosas que nadie autorizó.
04 · el cierre del bucleQA que certifica, no que aprueba a la fuerza
Falta el último control, el que muchos equipos maquillan: la calidad. En la fábrica Qirava, QA es un bucle con regresión profesional que corre hasta certificar. La diferencia con la práctica común es brutal. No se re-testea lo justo para que pase; se prueba en serio, y si algo falla vuelve al bucle. Certificar no es "ya no encontré errores buscando poco". Es "esto aguanta la regresión completa".
Esa disciplina existe fuera de nosotros: el propio ciclo de trabajo ágil separa la construcción de la validación precisamente para que quien prueba no sea quien tiene prisa por entregar [3]. En una fábrica de agentes, donde es tentador dejar que un modelo "se apruebe solo", esa separación es la única defensa real.
Junta las cuatro piezas y tienes la fábrica: una spec que gobierna (G0), agentes que nacen bajo gobierno con su paquete de skills, compuertas que nadie salta (G1 a G3), y un QA que certifica de verdad. Cada agente delibera dentro de su rol, propone dentro de su spec, y solo ejecuta cuando una persona abrió la compuerta. No es burocracia: es lo que hace que el trabajo de diez agentes sea confiable en lugar de ser diez sorpresas.
La próxima vez que veas a alguien pedirle a la IA "a ver qué sale", recuerda que eso no es una fábrica. Es un taller de una sola persona con suerte. Una fábrica tiene planos, puestos y controles. Y en la de Qirava, ningún agente cruza una compuerta que no le corresponde.
Fuentes
- Amazon. Working Backwards y el proceso PR/FAQ (nota de prensa y preguntas frecuentes antes de construir). Descrito por Colin Bryar & Bill Carr en Working Backwards: Insights, Stories, and Secrets from Inside Amazon (St. Martin's Press, 2021).
- GitHub. Spec Kit: toolkit de código abierto para Spec-Driven Development, donde la especificación es la fuente ejecutable del trabajo. github.com/github/spec-kit.
- Schwaber, K. & Sutherland, J. (2020). The Scrum Guide. Separación entre el trabajo del Sprint y su validación; el incremento debe cumplir la Definición de Terminado. scrumguides.org.