AgentRun a prueba: flujos de trabajo con IA bajo control

Flujos de trabajo con IA: qué es AgentRun en realidad

AgentRun es el intérprete de flujos de trabajo en TypeScript de Parcha. Su propósito es imponer una estructura determinista alrededor de herramientas, decisiones acotadas del modelo y llamadas a agentes. Parcha publicó el código fuente el 23 de septiembre de 2026. El documento del flujo define los contratos de estado, los pasos, las ramas, los límites y la ruta de escalamiento; la aplicación aporta las herramientas, el acceso al modelo, los permisos, el almacenamiento y la entrega. No es el producto homónimo de Alibaba Cloud, ni el antiguo paquete de Python que ejecuta código generado por modelos, ni el juego móvil de 2014 que todavía aparece en los resultados de búsqueda. El paquete principal actual es @parcha/agentrun-dsl versión 0.1.0-beta.4, publicado bajo Apache-2.0.

Para quién es Parcha AgentRun y quién debería descartarlo

AgentRun está pensado para equipos de TypeScript que ya cuentan con un runtime de agentes y pueden señalar una tarea recurrente cuyo código convencional se ha vuelto difícil de inspeccionar. El triaje de soporte encaja bien: primero se busca, después se decide si la respuesta basta, se consume una sola llamada al agente únicamente cuando hace falta investigar y, por último, se responde o se entrega el caso a una persona. El filtrado de evidencias, el enrutamiento de aprobaciones y los pipelines de investigación comparten esa misma forma. El mayor valor aparece cuando una persona responsable de producto, operaciones o riesgo necesita leer el flujo de control sin recorrer una maraña de callbacks.

No conviene usar AgentRun cuando la tarea cabe en una función fija con dos o tres ramas evidentes. La implementación de control empleada en este análisis reprodujo los cuatro resultados de soporte con un cuerpo de función de 31 líneas, mientras que el archivo del flujo de ejemplo de AgentRun ocupa 93 líneas antes de integrar el host. En brevedad pura, gana la función.

Conviene elegir LangGraph.js cuando el problema central sea un agente con estado y de larga duración que necesite persistencia, streaming e intervención humana. Temporal es la opción adecuada cuando el requisito irrenunciable sea mantener la ejecución de la aplicación pese a caídas, fallos de red y esperas prolongadas. AgentRun expone hooks de recuperación, pero no incluye un planificador duradero. Si el equipo necesita Python, ejecución en navegador, un panel alojado o un SLA de soporte para producción, beta.4 tampoco es una elección adecuada: esta versión no ofrece nada de eso.

Capacidad 1 de AgentRun DSL: el estado tipado detecta contratos que se desvían

AgentRun DSL suma su primer punto al rechazar un valor final que ya no cumple el contrato declarado. Puede parecer elemental hasta que un flujo combina un resultado de búsqueda, una decisión semántica y el envío a un agente. Sin un validador final único, un cambio en la estructura de cualquier rama puede llegar al consumidor como si fuera un éxito parcial.

El flujo de soporte distingue un Candidate flexible del Answer final. La búsqueda puede devolver texto vacío o ninguna fuente porque esa condición está permitida para activar una investigación. El cierre es más estricto: la respuesta final exige texto no vacío y al menos una fuente. La guía de creación también valida los contratos declarados de entrada y salida, mientras que las rutas del estado intermedio se comprueban durante la ejecución.

La prueba del contrato añadió un campo obligatorio sin modificar la salida del fixture:

schemaWorkflow.schemas.Answer.properties.resolutionCode = {
  type: 'string',
  minLength: 1,
};
schemaWorkflow.schemas.Answer.required.push('resolutionCode');

La ruta de contraseña siguió consultando la ayuda y tomando la primera decisión. El cierre falló después con WorkflowOutputInvalidError, código output_invalid, porque faltaba resolutionCode. No se devolvió una respuesta inválida. Ese es el modo de fallo correcto: el sistema se detiene en su frontera en vez de aceptar como completo un objeto que solo parece válido desde el punto de vista semántico.

La protección tiene un límite preciso. Una cadena válida en text y un arreglo válido en sources todavía pueden contener una respuesta equivocada. Validar el esquema demuestra que el código posterior puede consumir el valor, no que un cliente deba confiar en él. El análisis complementario sobre el enrutamiento de tickets de soporte con Jev aborda esa capa de decisión: las probabilidades y las salidas tipadas siguen necesitando casos etiquetados y una alternativa humana.

Capacidad 2 de AgentRun: controlar las ramas limita las llamadas al agente

El control de flujos de AgentRun hizo exactamente lo que prometía el grafo en los cuatro casos de soporte: dos solicitudes terminaron después de la búsqueda y una decisión; las otras dos entraron en una investigación acotada y pasaron por una segunda decisión. La unidad útil no es un agente autónomo. Es una ruta determinista con un único punto en el que se permite llamar a un agente.

Cada ejecución directa de los fixtures terminó tal como estaba documentado. Los casos de contraseña, factura y pago fallido devolvieron el código 0. El pago no resuelto devolvió el código 2 y explicó que la respuesta seguía siendo insuficiente o incierta después de una investigación. Los cuatro escribieron cero bytes en stderr. Además, las 31 pruebas específicas de soporte del repositorio se completaron correctamente en 2.92 segundos, incluidos los casos de envíos inválidos, decisiones de baja confianza, cancelación y errores de adaptador.

Estos resultados demuestran disciplina en las llamadas, no calidad de atención al cliente. Las respuestas de búsqueda, las decisiones de Jev y los resultados de la investigación eran fixtures fijos. Cambiar un prompt no los vuelve adaptativos y no se envía ninguna respuesta a un cliente real. La prueba demuestra algo más acotado, pero útil: cuando la primera respuesta supera la validación, el intérprete no gasta una llamada al agente; cuando falla, permite exactamente una investigación; si la segunda comprobación tampoco pasa, el caso no se cuela como completo.

Esta es la razón más sólida para adoptar el runtime. Un bucle de agente general puede decidir buscar otra vez, revisar de nuevo o llamar a otra herramienta porque la conversación todavía parece inconclusa. AgentRun hace que el trabajo permitido sea finito dentro del propio flujo. Así, el operador obtiene un presupuesto de llamadas que puede inspeccionar antes de ejecutar, aunque el host aún deba imponer los límites de gasto del proveedor y los permisos de las herramientas.

Capacidad 3: el escalamiento es código, no un deseo dentro del prompt

AgentRun convierte el escalamiento en un estado del runtime que incluye una razón, no en una frase enterrada en el prompt del agente. El flujo probado solo acepta una respuesta cuando la decisión es yes, la respuesta cumple su contrato y la confianza alcanza 0.8. De lo contrario, abre una cola que admite cero o una investigación, vuelve a comprobar el resultado y escala el caso si sigue sin superar el mismo umbral.

Para comprobar si el número realmente gobernaba el comportamiento, ambas comparaciones se elevaron de 0.8 a 0.98. La decisión predefinida del fixture de contraseña se mantuvo en yes con 0.97. Con el flujo original, el caso terminaba de inmediato sin llamar al agente. Con el flujo más estricto, entró en investigación, recibió la misma respuesta válida, volvió a obtener yes con 0.97 y se escaló después de una llamada al agente y dos decisiones.

Ese pequeño cambio modificó la rama sin tocar el prompt, la respuesta del fixture ni el adaptador. Esta es la ventaja práctica de mantener la política de confianza en código. Un equipo puede revisar el ajuste del umbral como cualquier otro cambio de comportamiento, ejecutar casos etiquetados y observar la tasa de derivación resultante antes del lanzamiento.

El escalamiento también permanece separado de la entrega. El runtime devuelve complete o escalated; el host decide si abre un ticket de soporte, avisa a una persona o no hace nada. Esa separación impide que un documento de flujo se conceda a sí mismo permiso para contactar a un cliente o modificar una cuenta.

Capacidad 4: la inspección resulta útil, pero la integración sigue siendo responsabilidad del equipo

La inspección de AgentRun permite entender el flujo antes de ejecutar código, pero no elimina el trabajo de integración que lo rodea. En el ejemplo generado de triaje, agentrun inspect devolvió un digest del flujo, los nodos judge, escalate y code, el adaptador obligatorio runJudge y executableCode: true. validate devolvió ok: true. dry-run también devolvió ok: true, aunque indicó con claridad que se había omitido la ruta sintética de escalamiento.

Esa omisión importa. Un dry run en verde demuestra que las piezas están conectadas, no que todas las ramas estén cubiertas. Los cuatro fixtures de soporte aportaron la prueba de comportamiento porque forzaron deliberadamente las rutas de respuesta, investigación y revisión. Conviene conservar esa distinción en CI: la inspección comprueba la estructura, la validación comprueba los contratos y los casos fijos comprueban el comportamiento.

La integración requiere tres adaptadores principales. runEffect despacha las herramientas y otros efectos. runJudge aporta decisiones tipadas, de forma opcional mediante Jev. runNode conecta el runtime del agente y debe reenviar el esquema, las herramientas, la señal de cancelación y cualquier callback de revisión. El host también controla la autenticación, los secretos, la elección del modelo, los límites de turnos, los presupuestos, los logs, la redacción de datos, la entrega y los comprobantes duraderos.

La función de control sin framework deja más claro el intercambio. Su cuerpo de 31 líneas utilizó los mismos adaptadores predefinidos y reprodujo todos los estados y conteos de llamadas de referencia. Para una sola ruta de soporte, esa función es más fácil de leer y publicar. A cambio, las 62 líneas adicionales del archivo de flujo de AgentRun aportan un documento reutilizable, inspección genérica, semántica compartida entre nodos, contratos de salida, escalamiento estructurado y una superficie que un agente de creación puede generar. No reducen el código por defecto.

Es la misma frontera que aparece en la decisión más amplia de crear o comprar agentes de programación para flujos internos: conviene adoptar infraestructura compartida cuando el trabajo operativo recurrente supera el costo de mantenerla.

Precio de AgentRun beta: el intérprete es gratuito, el runtime no

AgentRun beta tiene un único precio de software: $0 por el código Apache-2.0. En beta.4 no existe un plan de pago de AgentRun ni un runtime alojado. El paquete npm, el código fuente, la CLI, el intérprete de flujos y los ejemplos constituyen el producto. Parcha no incluye tokens de modelos, ejecución de herramientas, almacenamiento, observabilidad ni soporte de producción dentro de esa licencia.

Jev supone un costo aparte y opcional como modelo de decisión. Según la página activa de modelos de TypeSafe, verificada el 24 de septiembre de 2026, Jev 1.13 cuesta $0.042 por cada millón de tokens de entrada y los tokens de salida son gratuitos. Con el supuesto declarado de 500 tokens de entrada por decisión, una comprobación cuesta $0.000021 y dos comprobaciones, $0.000042. Para 100,000 casos, esas llamadas de decisión sumarían $2.10 o $4.20, respectivamente.

Ese cálculo no incluye la investigación del agente. AgentRun puede conectarse al runtime de agentes que aporte el host, por lo que no existe una cifra universal honesta por caso. Un caso de soporte que termina después de una comprobación de Jev tiene un perfil de costos distinto del que invoca un agente, herramientas, una segunda comprobación, almacenamiento, logs y revisión humana. El análisis con fixtures no realizó llamadas a modelos en vivo; por eso, el gasto de inferencia observado fue de $0 y la evidencia sobre costos de producción fue igualmente nula.

Temporal muestra por qué el alojamiento duradero se compra por separado. Temporal Cloud comienza actualmente en $50 por cada millón de acciones, más almacenamiento, y ofrece $150 en créditos durante 90 días. AgentRun no cobra esa tarifa de plataforma porque no ofrece una capa comparable de ejecución alojada.

Las limitaciones reales

Las limitaciones de AgentRun son lo bastante importantes como para introducir la beta mediante un único flujo acotado, no como arquitectura predeterminada.

1. Los artefactos de la versión no coinciden entre sí

El manifiesto publicado del paquete identifica el paquete instalado como 0.1.0-beta.4, pero su README incluido dice Beta: 0.1.0-beta.3. El README raíz de la etiqueta beta.4 también presenta la versión como beta.3 y su changelog marca beta.4 como no publicada. La rama main actual corrige el README raíz a beta.4, pero quien fije la etiqueta publicada encontrará mensajes de estado contradictorios.

Esto no rompe el intérprete, pero sí resulta relevante en un sistema de flujos donde importa la procedencia de las versiones. Fije la versión de npm, guarde el resumen del flujo y registre por separado las versiones de los adaptadores y las políticas. No dependa de una insignia de texto para reconstruir una ejecución de producción.

2. La carga del host define la frontera del producto

AgentRun aporta el flujo de control, no un sistema de soporte terminado. Todavía hacen falta herramientas autenticadas, un adaptador de agentes, acceso a Jev si se utiliza, secretos, límites de presupuesto, cancelación, diagnósticos privados, una política para datos de clientes, entrega, monitoreo y gestión de la revisión humana. Los 30.48 segundos de preparación del código fuente no dicen nada sobre ese esfuerzo de integración.

3. Los mecanismos de recuperación no equivalen a ejecución duradera

El runtime expone interfaces de checkpoints, memos, recibos y recuperación, pero el host implementa el almacenamiento y la conciliación. Una clave de idempotencia ayuda a eliminar duplicados; no garantiza una entrega exactamente una vez. Un efecto externo que agota el tiempo puede completarse de todos modos, y el host debe comprobar su resolución final antes de reintentarlo. Si la recuperación tras una caída es el requisito principal, use Temporal. Si lo prioritario son los grafos persistentes de agentes con estado, evalúe LangGraph.js.

4. JavaScript de confianza es una frontera de seguridad estricta

Los nodos de código ejecutan JavaScript con los privilegios del proceso y la validación puede ejecutar pruebas. La opción --trusted de la CLI es un reconocimiento del riesgo, no un sandbox. Un equipo que acepte flujos de usuarios, artefactos generados o contenido de otro dominio de confianza debe aislarlos mediante fronteras de proceso, sistema de archivos, red y credenciales controladas por el host.

5. Los resultados tipados todavía pueden equivocarse con seguridad

La prueba de esquema falló exactamente como debía, pero no puede detectar una respuesta incorrecta con la forma adecuada. Una decisión yes con confianza alta sigue siendo el resultado de un modelo. El flujo necesita casos etiquetados, umbrales específicos para la tarea, monitoreo de producción y una ruta de revisión. Las 31 pruebas de soporte superadas validan los escenarios incluidos, no la precisión de Jev en vivo.

6. Las opciones de plataforma y soporte son limitadas

Beta.4 es una biblioteca ESM para Node.js que exige como mínimo Node 22.19 y, para quienes usan TypeScript, TypeScript 5.4. Python, la ejecución en navegador y un runtime alojado quedan fuera del alcance. La beta no incluye un SLA de soporte para producción, y los cambios en la API o la ejecución pueden exigir migraciones entre versiones beta.

7. Una función fija sigue siendo, con sorprendente frecuencia, la mejor abstracción

La función de control de 31 líneas no es un contraejemplo de juguete. Reprodujo el flujo en los cuatro casos predefinidos. Si la tarea tiene una búsqueda, una condición, una llamada opcional al agente y un traspaso gestionado por un solo equipo, una función ofrece mejor localidad y menos conceptos. AgentRun se justifica cuando el propio flujo debe poder inspeccionarse, generarse, versionarse, componerse o evaluarse de manera independiente de la aplicación que lo rodea.

Para llevarlo a operaciones, conviene acompañar este análisis con un plan de evidencias ante fallos. La guía de herramientas para analizar fallos de agentes de IA explica qué logs y trazas hacen falta cuando el grafo del camino feliz deja de ser suficiente.

Veredicto: cuándo se justifica AgentRun

AgentRun es una beta creíble para convertir la parte repetible de una tarea de agente en software explícito. El intérprete fue fácil de instalar, el grafo de soporte respetó todas las ramas acotadas, el contrato de salida falló de forma segura y el umbral se comportó como código. El proyecto es inusualmente claro sobre todo lo que queda fuera de la biblioteca.

El veredicto sigue sujeto a condiciones. Elija AgentRun solo si se cumplen las cuatro afirmaciones: el flujo se repite; al menos una rama de modelo o agente necesita un límite visible; más de una persona o sistema debe inspeccionar o generar el flujo; y el host puede asumir los adaptadores, los permisos, la recuperación, la evaluación y la entrega. Si alguna no se cumple, empiece con una función de TypeScript.

Use LangGraph.js cuando el producto sea, ante todo, un grafo persistente de agentes. Use Temporal cuando el flujo sea, ante todo, un proceso distribuido duradero. AgentRun ocupa el espacio entre ambos y una función: es más acotado que cualquiera de esos runtimes, pero más estructurado que el control escrito a mano.

El próximo paso es concreto. Tome una tarea de agente existente y marque cada paso como código determinista, decisión tipada, investigación del agente o revisión humana. Si el diagrama contiene una sola línea fija, conserve la función. Si contiene una rama recurrente cuyo gasto de agente o política de escalamiento requiere revisión, codifique solo esa ruta en AgentRun, fije beta.4 y prepare cuatro fixtures antes de conectar modelos en vivo.

Preguntas frecuentes sobre AgentRun