Dry run de agentes de IA: cómo revisar un plan antes

Cuando un agente puede crear archivos, editar una página o modificar un registro, «hazlo primero en modo simulación» parece una garantía sencilla. No lo es por sí sola. Un dry run solo tiene sentido si la herramienta concreta ofrece un modo que calcula el resultado sin realizar la escritura prevista, devuelve un plan comprensible y permite comprobar después que el estado no cambió. La palabra en un prompt no impide que una llamada real escriba.

Un ejemplo verificable es la integración propuesta en los PR #38141 y #38142 de Elementor, fusionados el 12 de noviembre de 2026. El servidor prepara un plan con dry_run; la herramienta del editor puede aplicar ese plan al lienzo local sin guardar la base de datos. Esa distinción muestra por qué «el servidor no guardó» no significa «no pasó nada»: el documento abierto sí puede haber cambiado. La fusión del código tampoco acredita que esa modalidad esté disponible en la versión instalada de cada sitio.

Gráfico original de Gaia Genis Hub basado en documentación de Elementor, MCP y OpenAI Agents SDK. No representa la ejecución de un agente real.

Tres estados que no se deben confundir

Planificado significa que la herramienta devuelve qué objetos pretende crear, modificar o borrar. Aplicado localmente significa que el editor o la sesión actual ya muestran cambios, aunque aún no se hayan guardado. Persistido significa que el sistema de destino ha aceptado la escritura; incluso entonces conviene leer el objeto resultante. En la integración de Elementor descrita arriba, una llamada local de composición puede pasar por los tres conceptos en momentos diferentes. En otro producto el contrato puede ser distinto: hay que leer su esquema y probarlo, no copiar la semántica del nombre.

El MCP publica prácticas de seguridad para implementaciones con servidores, permisos y proxies. Esos controles importan también cuando se planifica: la respuesta del plan puede provenir de un servidor equivocado, incluir recursos que el usuario no autorizó o quedar obsoleta si otra persona edita el mismo objeto. Un plan verosímil no es un permiso. Tampoco sustituye el respaldo o una vía de recuperación cuando la operación es importante.

Una ficha de plan que se puede revisar

Antes de ejecutar, anota el objeto exacto y su versión, la identidad que actuará, el propósito, el alcance y las precondiciones. Pide después un resultado de simulación estructurado: lista de creaciones, modificaciones y eliminaciones, advertencias y elementos que no pudo resolver. Compara cada eliminación con el objeto realmente elegido; no aceptes «reemplazar el contenido» si la herramienta devuelve un conjunto de IDs más amplio que el bloque previsto. La revisión debe referirse a esa versión del objeto. Si cambia mientras llega la respuesta, vuelve a leer y planificar.

Plantilla original de Gaia Genis Hub. Es un ejemplo de proceso, no un resultado de una herramienta comercial probada.

Por ejemplo, para actualizar una sección de una página, una ficha hipotética podría señalar «sustituir solo los tres hijos del contenedor 42 por dos bloques nuevos». Si el plan enumera cuatro IDs eliminados, la operación no está lista: hay que localizar la discrepancia antes de aplicar. El ejemplo no describe una página real ni acredita que una herramienta concreta soporte sustitución atómica.

La aprobación es otro control

La documentación oficial del OpenAI Agents SDK sobre intervención humana describe herramientas que pueden detener la ejecución hasta recibir una aprobación o rechazo de una llamada sensible. Ese mecanismo pregunta si se permite ejecutar; el dry run intenta explicar qué ocurriría. Se complementan, pero ninguno garantiza por sí solo que el resultado final sea correcto. Tras la aprobación, la aplicación debe verificar la respuesta real y volver a leer el estado del sistema.

Ante un timeout, no repitas de inmediato una mutación que podría haberse aplicado. Primero consulta el objeto: repetir una creación puede duplicar y repetir una sustitución puede borrar ediciones nuevas. Si hay conflicto de versión, faltan permisos o el modo de simulación no está soportado, detén esa ruta y documenta el bloqueo. Quitar dry_run para «hacer que funcione» cambia el riesgo de la operación.

Un agente útil no se limita a producir un plan convincente. Hace explícito qué sabe del estado actual, qué no ha podido comprobar y qué prueba posterior demostraría el resultado. Esa disciplina reduce errores repetibles sin prometer que una simulación sea una transacción segura.

Fuentes y agradecimientos

• Model Context Protocol, prácticas de seguridad: riesgos de proxies y autorizaciones. Agradecemos la documentación pública; no implica aval de esta plantilla.
• OpenAI Agents SDK, intervención humana: pausa, aprobación y reanudación de herramientas sensibles. Agradecemos la guía técnica; no se ha ejecutado aquí un agente de prueba.
• Elementor PR #38141 y PR #38142: ejemplo concreto de simulación de servidor y aplicación local. Agradecemos el código abierto; la disponibilidad depende de la versión y conexión reales.