Cuando un agente toca producción, el prompt ya no es suficiente

Un artículo que el propio sistema no dejó publicar

Hace unos días terminé de montar una primera versión del flujo editorial autónomo de este blog. El agente puede investigar temas, contrastar fuentes, revisar el histórico, generar candidatos, puntuarlos y decidir si alguno merece convertirse en artículo.

En una de las primeras ejecuciones ocurrió algo que resume bastante bien el problema que intento resolver.

El sistema encontró un candidato sólido. Había superado los criterios editoriales, tenía evidencia suficiente y no duplicaba lo que ya había publicado. Desde el punto de vista del análisis, estaba preparado.

Pero la publicación estaba deshabilitada.

El resultado no fue un borrador a medias ni un commit que luego hubiera que deshacer. El flujo terminó como preparado pero no publicado, porque la capacidad de publicar estaba separada de la decisión editorial.

Ese detalle me interesa más que la puntuación del candidato o el artículo concreto. Durante bastante tiempo, al trabajar con agentes, muchas garantías se expresan de esta manera:

No publiques sin comprobar los tests.

No modifiques producción sin permiso.

Comprueba que la rama principal no haya cambiado.

Si algo falla, detente.

Son instrucciones razonables. El problema es que siguen siendo lenguaje natural que el mismo modelo debe interpretar mientras decide qué hacer.

Cuando el agente solo propone texto, el riesgo es limitado. Cuando puede escribir código, modificar datos, crear commits, invocar herramientas o activar un despliegue, esa diferencia deja de ser académica.

Una instrucción y una garantía no son lo mismo

En los sistemas que estoy construyendo intento separar cada vez más dos capas.

La primera es probabilística. Ahí quiero que el agente tenga libertad para investigar, comparar alternativas, detectar relaciones, proponer una arquitectura o decidir qué candidato editorial tiene más valor.

La segunda debe ser mucho menos interpretable. Ahí entran las reglas que deciden qué puede modificar, qué estado del proyecto es válido, qué pruebas deben existir y cuándo una operación puede considerarse terminada.

Por ejemplo, decirle a un agente «no integres si los tests fallan» es una instrucción.

Hacer que la integración sea imposible mientras una validación obligatoria esté en rojo es una garantía bastante distinta.

Lo mismo ocurre con Git. Puedo pedirle al agente que recuerde trabajar sobre el último estado de main, o puedo exigir que la integración compruebe que el SHA esperado sigue siendo el actual antes de avanzar. Si ha cambiado, el flujo se detiene y obliga a reevaluar.

La segunda opción introduce más infraestructura, pero reduce una clase entera de errores que no quiero resolver añadiendo otra frase al prompt.

Lo que estamos aplicando en este mismo blog

El sistema editorial es un buen banco de pruebas porque combina decisiones subjetivas con operaciones que sí pueden verificarse.

Elegir si un tema merece un artículo es una decisión editorial. No existe un test unitario capaz de resolverla. Por eso el agente usa señales, fuentes, histórico, criterios de encaje, originalidad, utilidad y evidencia para producir una evaluación.

Publicar, en cambio, tiene otra naturaleza.

Para que un artículo pase de candidato a producción, el flujo debe comprobar una cadena de condiciones: que la publicación esté habilitada, que exista cuota disponible, que el candidato haya superado los gates, que el estado de la rama principal sea el esperado, que post e imagen formen el mismo cambio, que la construcción sea válida, que exista una preview verificable y que producción termine mostrando el resultado correcto.

Además, hacer push no equivale a publicar.

El estado «publicado» solo tiene sentido después de verificar la producción real. Hasta ese momento no se consume el slot editorial como si el trabajo hubiera terminado.

Esto parece una distinción pequeña, pero cambia bastante la forma de diseñar el workflow. Obliga a pensar en estados intermedios, reintentos, auditoría, rollback y condiciones de carrera. También hace que el agente pueda tener mucha autonomía editorial sin recibir automáticamente autoridad operativa equivalente.

No considero este sistema terminado. Sigue teniendo límites y zonas mejorables. Lo interesante es que varias investigaciones y propuestas publicadas estos días están convergiendo sobre problemas muy parecidos.

Google: sacar las garantías críticas fuera del prompt

El 17 de agosto, Google publicó Build zero-trust AI agents with Google’s Agent Development Kit.

El punto de partida es reconocible: en cuanto un agente puede modificar bases de datos, ejecutar código o interactuar con sistemas reales, confiar únicamente en instrucciones del modelo deja demasiada responsabilidad dentro del propio contexto del LLM.

La arquitectura que propone Google combina distintos tipos de control: identidad verificable para operaciones de escritura, ejecución aislada y validaciones deterministas antes de aceptar determinadas acciones.

No necesito replicar literalmente su stack para quedarme con el patrón. La parte transferible es que una política importante no debería depender exclusivamente de que el modelo la recuerde y la interprete correctamente.

Una regla como «este agente solo puede escribir bajo estas condiciones» gana fuerza cuando el sistema que recibe la escritura puede comprobar esas condiciones por sí mismo.

Eso encaja con la dirección que estoy tomando en mis workflows: el agente razona; la infraestructura decide qué consecuencias de ese razonamiento pueden convertirse en estado real.

Más contexto tampoco resuelve todo

Otra tentación habitual es corregir los fallos de un agente añadiendo más documentación.

Un AGENTS.md más largo. Otra sección en la spec. Más ejemplos. Más contexto inicial.

Todo eso puede ser útil, pero el paper The Working Set of a Coding Agent: Coherence Debt in Repository-Scale Tasks, publicado el 17 de agosto, introduce una distinción bastante práctica.

Los autores prueban siete modelos y cinco harnesses y observan que el resultado depende de que los hechos necesarios estén disponibles cuando el agente realiza la edición. Gastar más tokens no recupera una información que no está disponible. Y hay un resultado todavía más incómodo: una convención obsoleta puede perjudicar más que no proporcionar esa convención.

Esto conecta directamente con el problema de las especificaciones vivas.

No basta con acumular documentación. Hay que saber qué documento manda, qué versión está vigente y qué hechos necesita realmente una operación concreta.

Para mí, esa es una razón adicional para mantener fuentes de verdad explícitas y estados versionados. Si varias instrucciones se contradicen, el agente no debería tener que resolver siempre el conflicto mediante intuición. En los puntos críticos quiero una precedencia clara y, cuando sea posible, verificable.

La documentación sigue siendo necesaria, pero deja de ser un almacén indiscriminado de reglas y pasa a formar parte del contrato operativo del proyecto.

Un segundo agente tampoco convierte una opinión en verdad

El 16 de agosto apareció otro trabajo interesante: Adversarial Review: Structured Disagreement for Grounded Agentic Code Review.

La propuesta utiliza un agente principal, un reviewer y un critic. Los resultados muestran mejoras frente a varios baselines, pero el propio paper identifica un modo de fallo relevante: los agentes pueden alcanzar falso consenso sin evidencia suficiente.

Me parece especialmente útil porque evita una respuesta demasiado cómoda al problema del QA agentic: «si un agente puede equivocarse, pongamos otro agente a revisarlo».

Yo también utilizo separación de responsabilidades y revisión independiente. Tiene valor. Un reviewer puede detectar supuestos, inconsistencias, cambios de alcance o riesgos que el agente que implementó no vio.

Pero sigue siendo una revisión probabilística.

Si un cambio debe compilar, prefiero comprobar que compila. Si una URL debe responder correctamente, prefiero abrirla. Si un commit debe partir de un SHA concreto, prefiero comparar los SHA. El reviewer sirve para razonar sobre aquello que no puedo reducir a una comprobación determinista; no debería sustituir una comprobación que sí puedo ejecutar.

Esta separación está haciendo mis flujos algo más claros: usar modelos donde necesito criterio y usar mecanismos verificables donde ya conozco la condición correcta.

El proyecto persiste; los agentes pueden cambiar

Hay una cuarta referencia que encaja con otra decisión que vengo tomando alrededor de Git y la documentación del proyecto.

Persistent Recursive Worlds Enable Autonomous Software Evolution presenta Genesis, un sistema que mantiene persistente el proyecto mientras permite que los agentes que trabajan sobre él tengan una vida finita. Los cambios propuestos avanzan el estado persistente solo cuando son aceptados.

Es un preprint y sus resultados deben leerse como evidencia de los propios autores, no como una validación independiente. Aun así, la idea arquitectónica me parece útil.

La continuidad de un sistema agentic no tiene por qué residir en mantener al mismo agente, la misma conversación o una memoria infinita.

Puede residir en el proyecto: repositorio, commits aceptados, tests, documentación vigente, decisiones registradas y estado auditable.

Ese enfoque reduce también la dependencia de conversaciones largas. Un agente nuevo puede llegar, reconstruir el contexto relevante desde fuentes persistentes, trabajar sobre un estado conocido y dejar consecuencias que el siguiente agente pueda verificar.

Git deja entonces de ser solo un mecanismo para guardar código. Pasa a ser una pieza del contrato entre ejecuciones.

Qué controles estoy intentando sacar del modelo

No todas las reglas merecen convertirse en infraestructura. Hacerlo con absolutamente todo produciría un sistema rígido, lento y probablemente más difícil de mantener que el problema original.

La frontera que estoy usando es bastante práctica.

Mantengo dentro del razonamiento del agente aquello que requiere interpretación: relevancia editorial, alternativas de arquitectura, calidad de una explicación, posibles riesgos, priorización o necesidad de investigar más.

Intento sacar fuera aquello cuya respuesta correcta puedo expresar de forma objetiva: permisos, estado de Git, límites de publicación, presencia de artefactos, resultados de tests, construcción, URLs de preview, estado del despliegue o confirmación de que producción contiene el cambio esperado.

También intento que el sistema registre el camino seguido. Si una publicación falla, quiero poder distinguir entre un candidato rechazado, un fallo de build, una preview no verificable, un cambio concurrente en main o un despliegue que no llegó correctamente a producción.

Sin esa trazabilidad, la autonomía puede ahorrar trabajo en el happy path y devolverlo multiplicado cuando algo sale mal.

El coste de poner límites de verdad

Esta arquitectura no sale gratis.

Hay más estados, más validaciones y más infraestructura. Aparecen situaciones que un script lineal no necesita contemplar: reservar y liberar recursos, volver a comprobar el estado justo antes de integrar, mantener operaciones idempotentes, diferenciar un commit creado de una publicación verificada o recuperar el sistema después de una ejecución interrumpida.

También hay una tensión real entre velocidad y control. Si cada acción pequeña atraviesa diez gates, el sistema termina siendo burocrático.

Por eso el nivel de control debería seguir el riesgo de la operación. Leer información no necesita las mismas garantías que modificarla. Crear una preview no tiene el mismo impacto que promover un cambio a producción. Proponer un artículo no es equivalente a publicarlo.

El objetivo no es eliminar la autonomía del agente. Es poder aumentarla sin convertir cada nueva herramienta en una ampliación implícita de autoridad.

De prompts más largos a sistemas más verificables

Sigo usando prompts, skills, documentación viva y contexto. Son una parte fundamental del sistema porque explican intención, dominio, criterios y forma de trabajar.

Lo que está cambiando es la responsabilidad que les asigno.

No quiero que una frase dentro de una especificación sea la única barrera entre una decisión probabilística y un cambio irreversible. Cuando una condición es suficientemente importante y suficientemente objetiva, prefiero convertirla en algo que el sistema pueda comprobar fuera del modelo.

El propio flujo editorial de este blog ya me ha dado un ejemplo pequeño pero útil: el agente pudo decidir que había un artículo preparado y, al mismo tiempo, carecer de permiso operativo para publicarlo.

Esa separación me parece una base más sana para construir agentes con acceso a repositorios, datos, APIs, MCP y despliegues.

La investigación reciente está aportando nombres, experimentos y arquitecturas alrededor del mismo problema. Mi interés ahora está en seguir llevándolo a casos reales: menos reglas que solo esperamos que el modelo recuerde y más controles cuyo cumplimiento podamos demostrar.

Referencias

• Google Developers Blog, 17 de agosto de 2026: Build zero-trust AI agents with Google’s Agent Development Kit.
• Bardia Mohammadi et al., 17 de agosto de 2026: The Working Set of a Coding Agent: Coherence Debt in Repository-Scale Tasks.
• Eric S. Qiu y Joyce Gill, 16 de agosto de 2026: Adversarial Review: Structured Disagreement for Grounded Agentic Code Review.
• Beichen Huang et al., 11 de agosto de 2026: Persistent Recursive Worlds Enable Autonomous Software Evolution.