Los agentes quieren compilar

Los agentes de IA están empezando a compilar. A lo largo del stack, a mediados de 2026, la misma separación aparece desde todas las direcciones: el modelo decide y algo que no es un modelo ejecuta. En lugar de actuar en vivo dentro del bucle del modelo, los agentes emiten un artefacto determinista —un plan, un DAG, un script de flujo de trabajo— y se lo entregan a un entorno de ejecución que lo reproduce, lo reanuda y lo audita como cualquier software corriente. El modelo se está convirtiendo en el front-end de un compilador que analiza la intención desordenada y la convierte en una representación intermedia. Los entornos de ejecución deterministas se están convirtiendo en el back-end. A la agencia en vivo se le está poniendo un nuevo precio, el del modo caro que reservas para la exploración, los fallos inéditos y el gusto. {.answer-block}

El 1 de julio apareció un Show HN con un título que se lee como una tesis: “Un agente de programación que compila la intención en un DAG determinista antes de ejecutarla.” El proyecto es Rigorix, un entorno de ejecución en Rust que se autodenomina “un entorno de ejecución determinista para agentes de programación, pensado para una ingeniería de software con IA repetible y auditable” y que enuncia su división del trabajo en una sola línea: “El LLM genera el código; Rigorix gobierna la ejecución.”³ Catorce puntos, un comentario, fácil de pasar de largo. Me detuve en él porque es la tercera vez en otras tantas semanas que veo la misma forma aparecer desde una dirección distinta, y la forma, no una herramienta concreta, es lo que importa.

TL;DR

• Anthropic trazó la línea canónica en diciembre de 2024: los flujos de trabajo se ejecutan “a través de rutas de código predefinidas”; los agentes “dirigen dinámicamente sus propios procesos”.¹ Esa era una bifurcación de tiempo de diseño que elegía una persona. Ahora se mueve al tiempo de ejecución, y quien elige es el modelo.
• Los flujos de trabajo dinámicos de Claude Code hacen que el modelo escriba un script de orquestación en JavaScript que un entorno de ejecución corre fuera de la conversación: se puede reanudar con resultados en caché, comparar con ejecuciones anteriores y guardar como un comando que vuelves a ejecutar.²
• La misma forma llega desde otras tres direcciones: herramientas independientes que compilan tareas en lenguaje natural en DAGs ejecutables (Rigorix)³, frameworks que se niegan a ejecutar un grafo sin compilar (LangGraph)⁴ e infraestructura de ejecución durable que envuelve los bucles de agentes en flujos de trabajo reproducibles (Temporal)⁵.
• La compilación aporta lo que siempre aporta: caché, recompilaciones incrementales, artefactos comparables, revisión antes de la ejecución. Y cuesta lo que siempre cuesta: criterio congelado en tiempo de compilación.
• La agencia en vivo sigue ganando en exploración, estados de error inéditos y gusto. La regla operativa: la primera ejecución es investigación; cada ejecución posterior quiere ser una build.

La bifurcación era de tiempo de diseño. Se está volviendo de tiempo de ejecución.

El antecedente aquí es “Building Effective Agents” de Anthropic, publicado el 19 de diciembre de 2024 y todavía la taxonomía estándar de este terreno. Define los flujos de trabajo como “sistemas donde los LLM y las herramientas se orquestan a través de rutas de código predefinidas” y los agentes como “sistemas donde los LLM dirigen dinámicamente sus propios procesos y el uso de herramientas, manteniendo el control sobre cómo cumplen sus tareas”. Su consejo para elegir: “los flujos de trabajo ofrecen previsibilidad y consistencia para tareas bien definidas, mientras que los agentes son la mejor opción cuando se necesita flexibilidad y toma de decisiones guiada por el modelo a escala”.¹

Durante dieciocho meses esa frase se leyó como un menú. Tú, quien diseña el sistema, elegías la columna izquierda o la derecha antes de escribir una sola línea. El giro de 2026 es que el menú se está colapsando en un pipeline. El agente hace la pasada flexible y guiada por el modelo exactamente una vez, en el momento de planificar, y el resultado de esa pasada es un flujo de trabajo: rutas de código predefinidas, generadas bajo demanda, para esta tarea. Obtienes la flexibilidad del agente en tiempo de compilación y la previsibilidad del flujo de trabajo en tiempo de ejecución, del mismo sistema, por fases.

La pregunta “¿flujo de trabajo o agente?” se está respondiendo igual que los compiladores respondieron a “¿flexibilidad o velocidad?”: ambas, separadas por un artefacto.

Tres señales, una dirección

Primero el entorno se volvió determinista

La capa del arnés llegó ahí antes que los agentes. Los hooks se disparan en eventos del ciclo de vida con códigos de salida que el modelo no puede negociar. Las reglas de permisos se evalúan antes de la llamada a la herramienta, no después. Toda la disciplina de la arquitectura de agentes en 2026 es un caparazón determinista alrededor de un núcleo estocástico, y su reconocimiento sin rodeos: para todo lo que tiene que ocurrir siempre, dejamos de preguntarle al modelo y empezamos a imponerlo en la frontera. El determinismo llegó primero a los bordes.

Luego el artefacto durable le ganó a la conversación

La segunda señal es lo que sobrevive a una sesión. Las conversaciones se evaporan; la comprobación, la especificación y la prueba perduran, y los agentes optimizan contra ellas con tal intensidad que la comprobación se convierte en la especificación. La lección de fondo: la transcripción no es el resultado. El artefacto sí lo es, porque es lo único que la siguiente sesión, el siguiente agente y el siguiente ingeniero pueden sostener. Una vez que aceptas eso para la verificación, aceptarlo para los planes de ejecución es un paso corto. Si la comprobación durable sobrevive a la conversación que la produjo, también lo hace el plan durable.

Ahora el plan mismo es el artefacto

La tercera señal es la nueva, y es el tema de este ensayo. Los agentes han empezado a emitir su ejecución como un artefacto de primera clase en lugar de realizarla en vivo.

Claude Code lo lanzó como una superficie de producto. Un flujo de trabajo dinámico es “un script de JavaScript que orquesta subagentes a escala”: Claude escribe el script para la tarea que describes, y un entorno de ejecución lo corre en segundo plano mientras la sesión sigue respondiendo. La documentación es explícita sobre lo que cambió de manos: “Un flujo de trabajo lleva el plan al código”. En su propia tabla comparativa, la respuesta a “quién decide qué se ejecuta a continuación” no es Claude. Es el script. Cada ejecución escribe ese script en un archivo que puedes abrir, comparar con el script de una ejecución anterior, editar y relanzar. Interrumpe una ejecución y reanúdala, y “los agentes que ya se completaron devuelven sus resultados en caché, y el resto se ejecuta en vivo”.²

Rigorix construye la misma forma desde el lado independiente, y su arquitectura se lee como un libro de texto de compiladores: la planificación avanza por clasificación de la intención, luego extracción de parámetros y después generación del DAG; un motor basado en plantillas ejecuta el grafo bajo controles de riesgo, presupuestos y permisos, con sobres de auditoría firmados con HMAC para dejar rastro. Su definición del beneficio es precisa: “Repetible significa que la misma intención produce la misma estructura de ejecución bajo las mismas plantillas y políticas”.³

Los frameworks ya estaban ahí, escondiendo la misma idea en un verbo de API. LangGraph modela la lógica del agente como nodos (“funciones que codifican la lógica de tus agentes”) unidos por aristas, y su documentación enuncia el requisito en negrita: “DEBES compilar tu grafo antes de poder usarlo”. Compila con un checkpointer y “LangGraph guarda checkpoints en los límites de cada super-step”, que es lo que hace reanudable una ejecución a medio terminar.⁴

Y la capa de infraestructura llegó desde abajo. Temporal, la plataforma de ejecución durable, envuelve los bucles de razonamiento del agente en flujos de trabajo cuyo progreso persiste fuera de cualquier proceso: “Temporal lleva la cuenta del progreso de la aplicación y almacena todos los resultados de las Activities”, de modo que un agente que se cae “retoma donde se quedó” en lugar de volver a razonar desde cero. Su integración con el Agents SDK de OpenAI, anunciada el 30 de julio de 2025, convirtió ese envoltorio en una vía soportada en lugar de un patrón que armas a mano.⁵

Herramienta independiente, superficie de producto, framework, infraestructura. Cuatro direcciones, una forma: el modelo decide, el artefacto ejecuta.

Toma literalmente la analogía del compilador

Las analogías en la escritura sobre IA suelen ser decorativas. Esta es estructural, porque de ella se desprenden las predicciones.

El front-end de un compilador analiza el código fuente, verifica la semántica y emite una representación intermedia. Eso es exactamente la fase de planificación que corren estos sistemas: la clasificación de la intención de Rigorix es el análisis sintáctico, la extracción de parámetros es el análisis semántico, la generación del DAG es la generación de código. El script del flujo de trabajo es la IR. El back-end hace entonces lo que hacen los back-ends: planifica el paralelismo, impone límites de recursos (Claude Code limita una ejecución a 16 agentes concurrentes y 1.000 en total²) y memoiza. De ahí se siguen cuatro consecuencias.

Los planes obtienen cachés de build. La semántica de reanudación es compilación incremental. Claude Code devuelve resultados de agentes en caché al reanudar; el argumento de venta de Temporal para quienes construyen agentes es que recuperarse desde el punto del fallo conserva tokens en lugar de volver a ejecutar el modelo para regenerar el trabajo perdido.⁵ El siguiente paso son las etapas de plan direccionadas por contenido: volver a ejecutar un flujo de trabajo cuyas etapas iniciales no cambiaron las saltará igual que make salta los objetos que no cambiaron.

Los planes se comparan. La documentación de los flujos de trabajo te invita a comparar el script de una ejecución con el de una anterior.² Una vez que el plan es texto, la deriva del plan se vuelve visible igual que la deriva del código, y “la orquestación de esta migración cambió desde el trimestre pasado” se convierte en un evento revisable dentro de un pull request, en lugar de un proyecto de arqueología a través de transcripciones.

El plan se convierte en la superficie de revisión. Antes de que un flujo de trabajo se ejecute, Claude Code muestra las fases planificadas y ofrece “Ver script en crudo” antes de pedir tu consentimiento.² Esta es la pieza que conecta con hacia dónde va la revisión. Sostuve que los agentes reemplazaron al revisor, no la revisión: el trabajo humano se trasladó de inspeccionar diffs a apropiarse de la intención. El plan compilado es el artefacto donde ocurre esa revisión reubicada, porque es el único lugar donde la intención es legible antes de que la ejecución gaste nada. No puedes revisar diez mil decisiones en vivo. Sí puedes revisar un script de cuarenta líneas. Espera que la aprobación de grandes operaciones de agentes migre de aprobar el diff después a aprobar el plan antes.

La deriva dispara recompilación, no parches. Cuando un plan compilado falla porque el mundo cambió —una API que cambió de nombre, una dependencia que subió de versión—, el movimiento equivocado es editar el DAG a mano. Eso es parchear código objeto. El bucle correcto vuelve a ejecutar el front-end: misma intención, nuevo entorno, plan nuevo. Los entornos de ejecución durables ya absorben el fallo transitorio dentro del artefacto con reintentos; la deriva del entorno es la clase de fallo que se escapa hasta el compilador. Los arneses desarrollarán detectores de deriva que invalidan planes igual que los sistemas de build invalidan cachés, y “recompilar ante la deriva” se convierte en un bucle permanente en lugar de un rescate manual.

Dónde gana cada modo

La tabla es una frontera, no un ranking. Todo lo que está por debajo de la frontera está a punto de volverse mucho más barato y mucho más confiable. Todo lo que está por encima sigue siendo caro porque debe serlo.

Lo que la compilación no aporta

Tres cosas siguen en vivo, y fingir lo contrario es como se sobrevenderá este patrón.

La exploración. En una base de código desconocida o un problema genuinamente nuevo, el plan es el descubrimiento. Todavía no hay nada que compilar porque decidir es el trabajo. Compilar antes de entender produce un artefacto seguro de sí mismo hecho de tu ignorancia, y el entorno de ejecución lo ejecutará a la perfección.

Los estados de error inéditos. Un plan compilado maneja los fallos que su autor anticipó. Las políticas de reintento son respuestas deterministas a problemas esperados. Cuando el problema es inesperado, el reintento determinista es un bucle, no un arreglo, y el movimiento correcto es escalar de vuelta al front-end, donde un modelo puede mirar el error real y pensar.

El gusto. Un flujo de trabajo es criterio congelado en tiempo de compilación, y el criterio congelado envejece. El criterio fresco ejecutado con descuido le gana al criterio rancio ejecutado a la perfección, porque la versión rancia falla con seguridad. Nadie debería compilar la decisión sobre cómo debería sentirse un producto.

Hay también una advertencia que trasladar desde el lado de la verificación. Un DAG es una superficie de comprobación, y todo lo que el plan omite deja silenciosamente de ser parte del trabajo, la misma dinámica que hace que las pruebas visibles se conviertan en la especificación de facto. La compilación concentra todo el criterio del modelo sobre una tarea en un solo artefacto, lo que concentra el trabajo humano en apropiarse de ese artefacto. La revisión no desaparece cuando el plan se compila. Se mueve al momento de la planificación, y le queda una sola página de alto apalancamiento con la que trabajar.

La postura

La regla por la que me guío ahora es simple: la primera ejecución de cualquier tarea es investigación y merece un agente en vivo; la segunda ejecución es una build y merece un artefacto. Claude Code implementa esa regla como UX: haz que Claude escriba el flujo de trabajo una vez, guarda el script de la ejecución como un comando y vuelve a ejecutarlo para siempre.² Rigorix la implementa como gobernanza. Temporal la implementa como infraestructura. LangGraph la implementó años antes como un verbo de API que nadie leyó como un manifiesto.

Los agentes quieren compilar por la misma razón que los programadores. Decidir es caro y precioso. Ejecutar debería ser aburrido, inspeccionable y libre de repetir. La industria pasó 2024 y 2025 demostrando que los modelos pueden decidir. El trabajo de 2026 es asegurarse de que solo tengan que decidir una vez.

Puntos clave

• La primera ejecución es investigación; la segunda es una build. Ejecuta una tarea nueva con un agente en vivo; en cuanto se repita, congélala en un artefacto y deja de pagar por criterio fresco sobre un problema ya resuelto.
• Compila primero el 80 % aburrido. Tareas rutinarias de publicación, barridos de migración, lotes de traducción, pasadas de auditoría: mucha repetición, verificación barata. La exploración, la depuración y el gusto siguen en vivo.
• Adopta el bucle de recompilar ante la deriva. Cuando un flujo de trabajo compilado se rompa porque el mundo cambió, no parchees el artefacto a mano. Manda al modelo de vuelta a regenerar el plan contra la nueva realidad, revisa el diff y vuelve a congelarlo.
• Revisa el plan, no la transcripción. Una vez que la ejecución es determinista, el plan es la página de mayor apalancamiento del sistema. Léelo como leerías un script de migración, porque es exactamente lo que es.

Preguntas frecuentes

¿Qué significa que un agente de IA compile su plan?

Significa que la salida del agente es un artefacto determinista e inspeccionable —un script de flujo de trabajo o un DAG— en lugar de una secuencia de acciones en vivo. El modelo hace su razonamiento en el momento de planificar y emite el artefacto; un entorno de ejecución que no es un modelo lo ejecuta con semántica de reproducción, reanudación y auditoría. Los flujos de trabajo dinámicos de Claude Code (un script de JavaScript escrito por el modelo y ejecutado por un entorno de ejecución) y Rigorix (tareas en lenguaje natural compiladas en DAGs ejecutables) son ejemplos que ya están disponibles.

¿Cuál es la diferencia entre un flujo de trabajo de IA y un agente de IA?

Las definiciones canónicas de Anthropic de 2024: los flujos de trabajo son “sistemas donde los LLM y las herramientas se orquestan a través de rutas de código predefinidas”, mientras que los agentes “dirigen dinámicamente sus propios procesos y el uso de herramientas”. La actualización de 2026 es que la frontera se está volviendo una fase dentro de un solo sistema en lugar de una elección entre dos sistemas: el agente hace su pasada dinámica una vez, en el momento de planificar, y genera él mismo las rutas de código predefinidas.

¿Los flujos de trabajo de agentes compilados son mejores que los agentes autónomos?

Para tareas repetidas y bien definidas, sí: un flujo de trabajo compilado es más barato por ejecución, se puede reanudar con resultados en caché y se puede revisar antes de que se ejecute. Para la exploración, los estados de error inéditos y las decisiones de criterio, no: un plan compilado es criterio congelado en tiempo de compilación, y esas tareas necesitan criterio aplicado en el momento. La división práctica es por número de ejecuciones: mantén en vivo la primera ejecución y compila todo lo que vayas a ejecutar dos veces.

¿Qué herramientas compilan hoy la intención de los agentes en artefactos deterministas?

Cuatro ejemplos verificados a julio de 2026. Flujos de trabajo dinámicos de Claude Code: el modelo escribe un script de orquestación en JavaScript, un entorno de ejecución lo ejecuta y los scripts guardados se convierten en comandos reutilizables. Rigorix: un entorno de ejecución en Rust de código abierto que compila tareas en lenguaje natural en DAGs ejecutados bajo restricciones de política, presupuesto y permisos. LangGraph: los grafos deben compilarse antes de ejecutarse, con checkpointing en los límites de cada super-step. Temporal: flujos de trabajo de ejecución durable que persisten el progreso del agente y se reanudan desde el punto del fallo.

Fuentes