Los flujos de trabajo empresariales no deberían ser ejecutados por LLMs en un loop. Esa es la tesis central de Decisional, una plataforma que propone una arquitectura radicalmente diferente: dos tipos de agentes donde el código, no el prompt, es el ciudadano de primera clase.
El problema: los LLMs en loops no resuelven flujos reales
Hace unos seis meses, el equipo de Decisional construyó un agente RAG para flujos de ingreso de datos en finanzas. La precisión era un dolor constante, y cuanto más trabajaban en ello, más se daban cuenta de que un agente (un LLM en un loop) no estaba resolviendo el problema real.
Un flujo de trabajo empresarial real nunca era solo un loop de uso de herramientas. Era ingreso de datos, algo de ETL, ingestión de documentos, un email al final, y todo sostenido por una ejecución determinista en la que el agente era malo. La automatización “de medio a medio”, donde el agente empieza desde un prompt y termina en algún lugar que aún necesita un humano para terminar el trabajo, nunca iba a llevar a nadie al 100%.
“Un flujo de trabajo empresarial real nunca era solo un loop de uso de herramientas. Era ingreso de datos, ETL, ingestión de documentos, un email al final — todo sostenido por ejecución determinista que el agente manejaba mal.”
La solución: dos tipos de agentes
Decisional se ejecuta sobre una arquitectura de dos agentes:
01. Manager Agent — Mantiene la flota saludable
Un agente que supervisa toda la flota de agentes de automatización. Revisa sus ejecuciones, te involucra cuando algo falla, y mantiene las automatizaciones saludables a lo largo del tiempo. Es el “cerebro de operaciones” del sistema.
02. Automation Agent — Construye y prueba el flujo
Un agente de codificación que construye y prueba un flujo de trabajo a partir de un objetivo definido por el usuario. Organiza cada automatización como un grafo de flujo de trabajo legible compuesto por nodos de código y nodos de agente.
El usuario habla con Dex (el manager). Dex genera agentes de automatización, cada uno propietario de un flujo de trabajo.
Por qué el código gana al prompt
La intuición clave es simple: un nodo es código. Cuando necesitas leer un Excel de 10,000 filas, usar Python es más confiable que pedirle a un LLM que lo haga. Cuando necesitas generar un documento, más Python. Cuando el formateo requiere razonamiento (como agrupar filas y resaltar decisiones para un revisor), ahí entra un nodo de agente: un nodo dentro del grafo que ejecuta un LLM con su propio modelo y herramientas.
El resto del flujo trata al nodo de agente como cualquier otro nodo. Cuando ocurren rate limits o errores, la ejecución determinista del grafo los maneja sin colapsar toda la tarea.
Las ventajas de este enfoque
1. Código gestionado por IA, no solo IA
En lugar de que un LLM intente ejecutar todo el flujo (donde es frágil y costoso), el código hace lo que hace bien: ejecución determinista, transformación de datos, llamadas a APIs. La IA solo interviene donde se necesita razonamiento.
2. El grafo es lo que los humanos revisan
Cada automatización es un grafo de nodos visual y legible. Puedes ver exactamente qué hace cada paso, aprobar cambios, y entender el flujo completo sin leer logs.
3. Un manager, muchos agentes de automatización
El Manager Agent orquesta múltiples Automation Agents. Cada uno es responsable de un flujo específico, aislado de los demás. Si un agente falla, no afecta al resto.
4. Credenciales aisladas del agente
Las credenciales y secretos se gestionan por separado, no incrustados en el prompt o el código del agente. Esto mejora significativamente la seguridad.
El caso de uso real
El equipo trabajó con una empresa de flujo complejo que necesitaba:
- Leer un Excel de 10,000 filas → código Python
- Generar un documento desde los datos extraídos → código Python
- Enviar un email desde el documento → código Python
- Devolver un Excel formateado con filas agrupadas y decisiones resaltadas → nodo de agente (donde se necesita razonamiento LLM)
Cuando llegaron los rate limits de APIs de terceros, el grafo lo manejó con reintentos deterministas — no con loops de LLM intentando “razonar” su salida.
“La automatización ‘de medio a medio’, donde el agente empieza desde un prompt y termina en algún lugar que aún necesita un humano, nunca iba a llegar al 100%.”
Implicaciones para la industria
Este enfoque representa un cambio importante en cómo pensamos la automatización con IA:
- Los agentes no deberían ejecutar flujos completos — deberían orquestar código que ejecuta los flujos
- La confiabilidad viene del código determinista, no del razonamiento del LLM
- La revisión humana es más fácil cuando puedes ver un grafo, no un log de llamadas LLM
- El aislamiento de fallos evita que un error en un flujo derribe todo el sistema
Fuente: Adaptado del blog oficial de Decisional. Publicado originalmente por Dhruv Tandon, Abril 2026.