Y con este post remato la pequeña serie dedicada a los agentes como martillos de oro. Y lo hago ofreciendo algunas soluciones intermedias o híbridas al problema planteado.
Pero vamos a ir poco a poco, recapitulando primero algunos conceptos y recordando la definición del problema.
Un paso atrás: los agentes de la Agentic AI
Damos, pues, un paso a atrás para recordar conceptos. Y lo primero es recordar de qué hablamos cuando hablamos de un agente. Y antes de hacerlo, insistir en que el término 'agente' se lleva utilizando desde hace décadas, e incluso siglos, y no sólo en tecnología. Así que, de los que hablamos son de los agentes de que hablamos bajo el paraguas de la Agentic AI.
Y se trata, como vimos, de programas construidos alrededor de un modelo de lenguaje razonador que son capaces de funcionar de manera autónoma, recibir sus tareas u objetivos mediante una especificación en lenguaje natural y, con base en sus capacidades razonadoras, decidir por sí mismos, y en tiempo de ejecución el plan a ejecutar para conseguir el objetivo. Un plan que puede ser revisado conforme avanza y se obtienen resultados intermedios, y un plan en cuyos diferentes pasos se puede incluir la selección y ejecución de una herramienta externa que le permite, entre otras cosas, interactuar con el mundo exterior.
Agentes versus workflows
Estructura de un agente
 |
| Estructura de un agente |
Conforme a lo comentado, la estructura de alto nivel de un agente es la que se muestra en la figura. En el núcleo tenemos un modelo de lenguaje razonador y, como apoyo, una serie de herramientas con las que puede interactuar y que, aparte de alguna posibilidad adicional, fundamentalmente le ayudan a entrar en contacto con aplicaciones y recursos externos (una web, un sistema empresarial, el correo electrónico, etc)
En la figura dibujo a trazos la unión entre el modelo de lenguaje y las herramientas queriendo indicar que, según el plan generado, se invocan o no.
Estructura de un workflow
Y es importante comparar a estos agentes basados en modelos de lenguaje razonadores con otro tipo de soluciones anteriores que funcionan bajo un paradigma de reglas y, sobre todo flujos o workflows. Denomino genéricamente 'workflows' a ese tipo de soluciones que incluye, por ejemplo, los robots RPA ('Robotic Process Automation'), a los a veces denominados workflows en la nube o IPaaS (como Make, N8N o Zapier) e, incluso, forzando un poco, a los BPMS ('Business Process Management System') y los CMS ('Case Management System').
 |
| Estructura de un workflow |
A alto nivel estas soluciones que agrupo bajo la etiqueta 'workflows' exhiben patrones estructurales muy similares entre sí, e incluso con los agentes.
En el caso de los workflows, el plan está predefinido en tiempo de desarrollo y adopta la forma de un flujo con sus pasos y, eventualmente, bifurcaciones y/o bucles. Y también pueden interactuar con aplicaciones y recursos exteriores, en este caso haciendo uso, habitualmente, de conectores que recubren un API generalmente de tipo REST.
Comparativa
En el fondo, estructuralmente hablando, se trata de soluciones muy similares. En la figura inferior, los ponemos frente a frente.
 |
| Comparativa Agente-Workflow |
En esa figura, e intencionadamente, he eliminado la mención explícita a herramientas (en el caso de agentes) y a conectores (en el caso de workflows). ¿Por qué? Pues porque, a despecho de alguna diferencia en cuanto a la definición, y algunas variantes en cuanto a implementación, su rol es exactamente el mismo y, por tanto, de cara a la comparativa estructural prefiero que no se muestre ninguna diferencia.
La diferencia fundamental es que, en el caso de los agentes, el plan de acción se decide y revisa de forma dinámica en tiempo de ejecución por el propio agente, mientras que en los workflows el plan de acción se define en tiempo de desarrollo por el desarrollador humano y es estático. Esta diferencia es fundamental, tanto para lo bueno de los agentes, la flexibilidad, potencia e inteligencia de los agentes, como para lo malo de los agentes: incertidumbre y consumo computacional.
Sólo por apuntar alguna otra diferencia, se puede observar en la figura que, en el caso de los agentes, y como mencioné más arriba, dibujo con trazos la unión con los nodos herramienta, mientras que en los workflows esa flecha la dibujo con trazo continuo. Lo que esto trasmite es una consecuencia del dinamismo del plan de los agentes: a priori no podemos estar seguros de qué herramientas va a invocar ni de qué forma. En el caso de los workflows sí se sabe, porque está definido en el flujo.
Podríamos apuntar algunas otras diferencias de menor calado, pero prefiero quedarme con estas que son nucleares.
Aunque me preocupan un poco las connotaciones de la palabra 'determinismo' en el ámbito de la inteligencia artificial, diría, por expresarlo de una forma aún más compacta que:
Un agente es una solución muy flexible y potente pero no determinista, mientras que un workflow es una solución más rígida y acotada, pero determinista.
Estableciendo el enunciado del problema
Llegados hasta aquí, y antes de pasar a la soluciones que propongo, recordar cuál es el problema a que me refiero (y que puede que el lector identifique como tal o no).
Mi argumentación parte de la idea de que, al menos a nivel de discurso, parece que los agentes son la solución a cualquier problema, especialmente de automatización de tareas y procesos. Es decir, se considera a los agentes como un martillo de oro, capaz de soluciones cualquier problema que, por tanto, vemos siempre como un clavo.
Salvo que alguien me demuestre lo contrario, creo que los agentes, al menos en su estado de arte actual, no deben ser la solución única, que todavía hay muchas tareas que se automatizan mejor mediante una solución más clásica basada en un workflow.
En concreto, cuando la solución al problema la tengamos clara y sepamos claramente las reglas que la gobiernan, un workflow parece mejor solución que un agente, por los siguientes motivos:
- Dado que un workflow es determinista, es mucho más sencillo de probar y, una vez probado, garantiza un comportamiento correcto, conocido y reproducible, cosa que en un agente nunca podemos estar 100% seguros.
- El coste computacional de ejecutar un agente, para una tarea similar, es muchísimo más alto que el de la misma tarea ejecutada por un workflow
- Dado que el coste computacional es mucho más alto, el coste económico es también más elevado y, además, no del todo predecible (no podemos saber con seguridad los tokens que se necesitarán).
- Finalmente, ese coste computacional se traduce en consumo eléctrico y de refrigeración, incrementando la huella de carbono y el impacto medioambiental
El razonamiento es, pues, resumiendo, que aunque los agentes son de una potencia extraordinaria y nos abren unas grandísimas posibilidades, no siempre son la mejor solución, y por lo tanto, no debemos considerarlos martillos de oro, sino elegir en cada momento la solución de automatización más adecuada.
Algunas posibles soluciones intermedias e integradoras
La verdad es que, hasta aquí, casi que lo que he hecho es nada más que resumir e ilustrar, el contenido de los dos posts anteriores. Vamos ahora con algunas soluciones o planteamientos que se me ocurren. En concreto, y aunque es posible que existan otras soluciones, o que las que propongo se puedan combinar, voy a proponer cuatro opciones, a saber:
- Solución 0: seleccionar la solución caso a caso
- Solución 1: el modelo generador de workflows
- Solución 2: orquestadores
- Solución 3: ecosistemas híbridos
En lo que sigue, comento brevemente cada una.
Solución 0: seleccionar la solución caso a caso
Esta solución le llamo solución 0, porque, en realidad, es casi trivial.
Si se admite que no todos los problemas se resuelven mejor con un agente pues entonces, simplemente, antes de lanzarse a desarrollar un agente o un workflow decidir conscientemente y con criterio cuál es la solución adecuada para ese caso concreto
Solución 1: el modelo generador de workflows
La solución 1 consistiría en que el propio modelo razonador que genera el plan fuese capaz de detectar, por sí mismo o con asistencia humana, qué tipo de solución es mejor y si, al inicio de su resolución detecta que es un problema basado en reglas y resoluble mediante un flujo, simplemente que genere ese flujo.
Me parece perfectamente viable técnicamente puesto que casi todas las herramientas de tipo workflow expresan ese workflow mediante un lenguaje de marcado (tipo YAML) o mediante JSON, dos formatos que un modelo de lenguaje domina muy bien.
Eso sí, no eliminamos al 100% el no determinismo, puesto que el agente puede equivocarse y no darse cuenta de que un problema se resuelve mejor mediante workflow. Tampoco es óptimo computacionalmente, porque la propia decisión de si vale la pena crear un workflow, e incluso la creación del workflow propiamente dicho sigue usando los mecanismos propios de un modelo de lenguaje.
No es pues, creo, una solución absoluta, pero alivia el problema.
Solución 2: orquestadores
La siguiente solución se apoya en la idea de que la relación de agentes entre sí, y de workflows entre sí puede hacerse jerárquica e incluso recursiva. Es decir, un agente puede invocar a otro agente (que actúa como herramienta) y un flujo puede invocar a otro flujo (usando una especie de conector).
Esta opción, que no sólo es viable, sino que ya hay plataformas que permiten su creación, es hacer automatizaciones en que exista un nodo orquestador, y otros nodos que realizan tareas. Y, para aquellas tareas en que la solución mejor sea un workflow, pues se utiliza un workflow y para aquellas en que la mejor solución sea un agente y es el orquestador quien lo decide. El esquema de esta opción se muestra en la figura.
 |
| Orquestadores |
Se puede ver que, además, esta solución tiene una doble vertiente: que el orquestador sea un agente o que el orquestador sea un workflow. Además, y aunque en la figura se muestra que un agente sólo invoca workflows y un workflow sólo invoca agentes, en realidad, ya sea orquestado por un agente o por un workflow, los nodos que ejecutan las tareas pueden ser cualquier tipo.
Como digo, este tipo de esquemas ya se pueden hacer hoy en día, no sólo en código, sino en herramientas como Make.
Solución 3: el ecosistema híbrido
La solución 2 ya anticipa un poco lo que es la solución 3 (realmente es un caso particular de la solución 3).
La solución 3, el ecosistema, parte de concebir las automatizaciones como una interacción entre unos nodos que pueden ser agentes o workflows y que se combinan en interaccionan entre sí según la naturaleza del problema. Es lo que intento mostrar en la siguiente figura:
 |
| Ecosistemas de agentes, con workflows como forma de agente |
Es una solución muy similar a la del orquestador pero sin que haya nodos con ese rol especial, sino que interactúen en un esquema más P2P. En el fondo, esta solución se basa en la idea de los ecosistemas de agentes, pero reconociendo a los workflows también como agentes.
Para que está solución sea óptima, como en el fondo también en el caso anterior, ha de cumplirse que cuando el orquestador seleccione un nodo para delegar una tarea, o cuando un agente del ecosistema delegue en otro la ejecución de una tarea, se 'acierte' siempre, en el sentido de identificar siempre cuándo una tarea se resuelve mejor mediante un workflow.
No voy a profundizar más en ello, pero se me ocurre que sino conseguimos que un modelo de lenguaje acierte siempre en la elección de workflows, se le 'podría ayudar' mediante alguna forma de catálogo de tareas que se resuelven mejor mediante workflows.
Algún pequeño 'disclaimer'
Antes de cerrar este post, hacer algún pequeño 'disclaimer'.
El primero es que las propuestas que hago no dejan de ser eso, propuestas, hechas un poco 'a bote pronto', aunque es un tema al que le doy vueltas con cierta frecuencia últimamente.
Por otro lado, ni reclamo ni dejo de reclamar la 'autoría' u originalidad de estas propuestas. No renuncio a esa supuesta 'autoría' u 'originalidad', porque es fruto de mi propia reflexión, no es nada que haya visto en ningún sitio salvo, hasta cierto punto, la idea del orquestador. Pero tampoco me atrevo a reclamar la autoría y, sobre todo, originalidad, porque me cuesta pensar que no haya ya mucho pensado e incluso escrito sobre estos temas y que existan propuestas, implementadas y/o publicadas, iguales o muy parecidas a las que hago..
Finalmente, apostaría a que hay más soluciones que yo no he planteado aquí y puede que mejores... así que me encantará o bien descubrir en alguna publicación o bien que se me ocurran a mi en un proceso de indagación y reflexión.
Conclusiones
El considerar a los agentes como martillos de oro, como la única solución para todos los problemas fundamentalmente de automatización, puede ser un error, ya que existen soluciones, especialmente las basadas en workflows, eventualmente más adecuadas y, además, más seguras, eficientes, baratas y sostenibles.
En este post, tras, revisar conceptos y la naturaleza del problema, se proponen cuatro estrategias de solución híbridas.
Artículos de este blog relacionados
