Deliberar sin simular ejecución: el gobierno de agentes bajo SDD

La respuesta corta, para quien tiene prisa: un agente de IA puede deliberar (proponer, evaluar, decidir qué haría) sin ejecutar (hacer el cambio real en el mundo). Y la regla que sostiene todo el gobierno de agentes en Qirava es que un borrador delibera pero nunca simula que ejecutó. Confundir las dos cosas es la fuente número uno de trabajo fantasma: entregas que parecen listas y no tocaron nada.

Nos hemos acostumbrado a pedirle a la IA "a ver qué sale". Le lanzas una tarea, te devuelve un texto seguro de sí mismo, y tú asumes que algo pasó. Muchas veces no pasó nada: solo describió, con mucha confianza, lo que habría hecho. Ese hueco entre decir y hacer es donde nacen los problemas caros.

01 · la líneaDeliberar no es ejecutar (y por qué se confunden)

Deliberar es todo lo que ocurre antes de tocar el mundo: proponer un plan, comparar opciones, estimar riesgos, decidir un camino. Ejecutar es el acto que deja huella: escribir el archivo, mandar el correo, mover el registro en la base de datos. Un humano rara vez confunde las dos cosas, porque para él "lo pensé" y "lo hice" se sienten distinto.

Un modelo de lenguaje no siente esa diferencia. Genera texto, y el texto de "voy a crear el archivo" se produce igual que el de "creé el archivo". Si no le pones una frontera dura, el agente redacta un cierre triunfal ("listo, ya quedó actualizado") sobre una acción que nunca ocurrió. No miente por malicia: completa el patrón más probable de un trabajo terminado.

El texto de "lo haré" y el de "lo hice" salen de la misma picadora. La diferencia la pones tú, no el modelo.

Por eso en Qirava la regla se escribe al revés de como suena intuitiva. No decimos "que el agente ejecute bien". Decimos: mientras esté en modo borrador, tiene prohibido fingir ejecución. Puede entregar la propuesta completa, el plan, el diff sugerido, la decisión razonada. Lo que no puede es narrar como hecho algo que sigue siendo una intención.

02 · el métodoSDD: primero la especificación, luego la ejecución

Esa frontera no se sostiene con buena voluntad. Se sostiene con método. En Qirava trabajamos con SDD (Spec-Driven Development, "desarrollo guiado por especificación"): antes de que cualquier agente actúe, existe una especificación que dice qué se busca, con qué límites y cómo se sabrá que quedó bien. Se abandona el vibe coding, ese "pídele a la IA a ver qué sale", y también el prompting básico de una sola instrucción suelta.

La spec no es un documento decorativo: gobierna al agente. Cada agente nace bajo gobierno, cargando una skill universal (la de gobierno) más la skill de su rol. Así, natalia.marketing.ai, santiago.architect.ai, sofia.qa-sprint.ai o martin.legal.ai no improvisan su alcance: heredan lo que su especificación les permite y les prohíbe. Un rol es, en la práctica, un paquete de habilidades: una universal, una primaria, alguna secundaria y una lista explícita de lo prohibido.

La fuente de verdad no es la memoria del modelo ni la última conversación: es un índice documental (un DOCUMENT_INDEX). Las skills viven en un toolkit, el gobierno vive en un vault, y se consumen por enlace. Si quieres entender por qué esa separación importa tanto, ayuda tener claros los niveles de contexto en IA: la spec es contexto gobernado, no un prompt más.

03 · las compuertasGates de madurez: nada avanza sin pasar el suyo

Aquí es donde deliberar y ejecutar se ordenan en el tiempo. Un artefacto no salta de la idea a producción de un tirón. Sube por compuertas de madurez, y cada compuerta es un permiso que hay que ganarse.

G0, especificada. Existe la spec. Se sabe qué se quiere y cómo se medirá. Todavía no hay nada hecho.

G1, borrador. El agente delibera y produce la propuesta. Pasa una validación. Y aquí opera la regla de oro: el borrador propone, no ejecuta, y jamás reporta como hecho lo que no hizo.

G2, operativa. Llega la aprobación del CEO. Solo entonces la deliberación se convierte en ejecución real, con huella verificable.

G3, consejo. El nivel donde el artefacto ya opera con respaldo colectivo.

Esta idea no es un invento de Qirava. Amazon lleva años escribiendo primero el comunicado de prensa y el documento de preguntas frecuentes de un producto que aún no existe (el método "working backwards" y el PR-FAQ): deliberan el resultado antes de construir nada [1]. La comunidad de ingeniería la ha formalizado bajo el nombre de spec-driven development, con herramientas como Spec Kit de GitHub que ponen la especificación por delante del código [2]. En todos los casos el patrón es el mismo: decidir bien en papel, ejecutar después.

04 · el buclePor qué esto le importa a tu negocio

Cuando un agente puede fingir ejecución, tu QA se vuelve teatro. El sistema "dice" que hizo el trabajo, alguien lo da por bueno, y el error aparece tres pasos más abajo, cuando ya es caro. Separar deliberar de ejecutar corta ese teatro de raíz: si no hay huella verificable, no hubo ejecución, punto.

Por eso el control de calidad en Qirava es un bucle con regresión profesional hasta certificar, no un retest apurado para "pasar". La diferencia es de fondo: no se prueba para aprobar, se prueba para saber. Un borrador que deliberó bien y fue honesto sobre lo que no hizo es infinitamente más útil que uno que se declaró terminado por cortesía con el patrón.

La próxima vez que un asistente te diga "listo, ya quedó", hazte la pregunta de gobierno: ¿dónde está la huella? Si no la hay, no ejecutó. Deliberó. Y deliberar, bien hecho y sin fingir, ya es la mitad del trabajo. La otra mitad tiene compuerta, y la compuerta tiene dueño.