Los agentes y el martillo de oro (III): soluciones híbridas y ecosistemas de agentes

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

• Los agentes y el martillo de oro (II): agentes y medio ambiente
• Los agentes y el martillo de oro (I): ¿por qué no un workflow?

Los agentes y el martillo de oro (I): ¿por qué no un workflow?

Leo mucho y también le doy muchas vueltas en los últimos meses, seguro que no soy el único, a todo lo relativo a los agentes de IA.

Por un lado, me resulta excitante el concepto y la posibilidad de que seamos capaces de construirlos y, además, con cierta facilidad.

Por otro, me generan dudas, no de manera general, sino en aspectos particulares o casos de uso particulares.

Voy a recoger algunas de esas consideraciones en una mini-serie de posts, entre tres o cuatro artículos, comenzando por el de hoy.

En concreto hoy hablaré de lo que tiene que ver con la automatización, la repetitividad y la calidad, un tema al que de alguna forma ya me he aproximado en algún artículo anterior.

Martillos y clavos. El martillo de oro

En cierto modo, y más allá de que creo que los agentes IA constituyen todavía una tecnología y un tipo de solución que tiene que mejorar mucho en cuanto a fiabilidad, pruebas y gobernanza, podría decir que mis cuitas con respecto a los agentes tienen que ver, sobre todo, con que los estemos tratando como un martillo de oro. ¿A qué me refiero? ¿Qué es un martillo de oro? En su entrada en wikipedia se expresa de una forma muy simple

Un martillo de oro (o martillo dorado) es cualquier herramienta, tecnología, paradigma o similar cuyos partidarios ensalzan de manera exagerada. Predicen que resolverá múltiples problemas, incluso aquellos para los que obviamente no es adecuada.

Aunque, quizá su formulación más conocida, también para mí, sea la que se atribuye al muy afamado psicólogo Abraham Maslow y que se denomina por ello, a veces, como martillo de Maslow, a saber:

Si sólo tienes un martillo, todo parece un clavo.

Y, en efecto, tengo la sensación de que estamos considerando a los agentes, en ocasiones a toda la IA, como un martillo y que, por tanto, sólo vemos clavos, queriendo decir con ello que todo lo queremos resolver mediante agentes, sean o no adecuados, y existiendo o no mejores soluciones alternativas.

Agentes y Agentic AI

Simplificando, y como ya he explicado en algún otro post, y como probablemente muchos lectores de este blog conozcan, los agentes (en la acepción de agente referida a los agentes IA que conforman la denominada Agentic AI) no son más (bueno, ni menos) que aplicaciones construidas alrededor de un gran modelo de lenguaje de tipo razonador, unas aplicaciones que, aunque pueden interactuar con el usuario, en general funcionan de manera autónoma y que, además, pueden realizar tareas especiales y, sobre todo, interactuar con el exterior, mediante las denominadas herramientas ('tools').

Mediante estas herramientas, el agente es capaz, por ejemplo, de leer un correo electrónico, leer datos de una pantalla, consultar datos en una aplicación y un larguísimo, casi infinito, etcétera. Y no sólo leer, también escribir o invocar acciones.

¿Hemos descubierto la pólvora?

Sin embargo, existen ya desde hace años, muchos otros tipos de aplicaciones que hacen algo similar, en el sentido de aplicar una cierta lógica para automatizar un proceso o tarea funcionando de manera autónoma e interactuando con el exterior haciendo uso, fundamentalmente, de APIs y conectores.

Cabe decir, además, que con independencia de los cambios de nombre, las herramientas funcionan de forma similar a, y de hecho se suelen apoyar en, APIs y conectores. Los afamados servidores MCP no dejan de ser una implementación algo especial de los conectores de toda la vida.

Entre ese tipo de soluciones que aplican de forma autónoma una lógica interrelacionándose vía conectores con el exterior, tenemos los chatbots basados en reglas y, sobre todo los robots RPA sobre todo en su variante no atendida, protagonistas ambos de mi libro 'Robots en la sombra'. Y, hasta cierto punto, aunque normalmente con menor autonomía, también podríamos incluir en este apartado las soluciones BPMS ('Business Process Management System').

¿Qué pasa entonces? ¿Es que con los agentes hemos 'descubierto la pólvora' o el Mediterráneo? ¿Es que no son más que un nuevo nombre o una nueva implementación de algo que ya teníamos?

Elementos diferenciales de los agentes IA

No, aunque comparten elementos comunes, bastante elementos comunes de hecho, con otras formas de automatización, tienen algunas características diferenciales, alguna tremendamente diferencial.

Me voy a centrar en dos.

La primera que, con ser importante, casi la veo secundaria, es que a un agente IA sus objetivos o la tarea a realizar se le indican en lenguaje natural, no mediante código, ni mediante reglas o flujos expresadas en un lenguaje más o menos formal. Simplemente, lenguaje natural.

Pero lo que creo que cambia radicalmente el planteamiento es que el 'cerebro', quien decide el plan y, por tanto la lógica, a aplicar, es un modelo de lenguaje razonador, no un desarrollador humano. Y esto tiene varias implicaciones muy importantes:

• Decide la IA, no el humano, la lógica a aplicar en cada caso. 
• Por lo anterior, eventualmente un agente podría atacar la automatización de una tarea que un humano no sabe exactamente cómo resolver.
• La lógica, el plan a aplicar, se decide en tiempo de ejecución, no en tiempo de diseño o desarrollo
• El plan, la lógica a aplicar, es flexible, dinámico y adaptativo
• El plan que se aplica puede variar de una instancia de tarea (un caso que se diría en proceso so automatización) a otra.

Son características, muy diferenciales y muy potentes, que diferencian claramente a los agentes de otras formas de automatización que, exteriormente se puedan manifestar de forma parecida.

En general, son de una potencia espectacular...pero a lo mejor eso nos lleva a considerarlos martillos de oro y es posible que, pese a su potencia, no siempre constituyan la mejor opción 

Automatización

Cuando automatizamos tareas, es decir, cuando eliminamos la participación de un humano (o eventualmente un animal) de un proceso, solemos buscar los siguientes objetivos:

• Ahorro de costes, ya que el trabajo humano es caro
• Alta disponibilidad
• Reducción de tiempos de proceso
• Eliminación de errores
• Control del proceso y predecibilidad de sus resultados (calidad)
• Cumplimiento normativo

Los sistemas basados en reglas y workflows

Los sistemas de automatización de procesos y tareas, típicamente los BPMS (Appian, Pega, etc) , RPA (UiPath, Blue Prism, Automation Anywhere, Power Automate, etc)  o workflows en la nube (Make, Zapier, N8N, etc) o incluso soluciones de automatización construidas como un desarrollo a medida, definen el flujo en tiempo de desarrollo con lo cual su lógica en producción está perfectamente determinada, perfectamente conocida por anticipado.

Por tanto, las aplicaciones de automatización construidas con estas herramientas cumplen con todos los objetivos expresados acerca de la automatización. 

Sólo un matiz respecto a la frase anterior: como hoy en día estas soluciones incluyen también la posibilidad de invocar a grandes modelos de lenguaje usando APIs y conectores, la certeza en cuanto a su lógica se podría debilitar un tanto, pero esto no deja de ser una primera manifestación de las limitaciones que pueden exponer los agentes, basados precisamente en modelos de lenguaje y que expongo en la siguiente sección.

Alguna desventaja de los agentes

Paradójicamente, creo que, de todos los objetivos de la automatización mencionados más arriba, en el único en que los agentes pueden superar a otras opciones de automatización más tradicionales es en el ahorro de costes.

En principio, igualan a las soluciones tradicionales puesto que, para una tarea dada, si ambas soluciones eliminan el trabajo humano, el ahorro es el mismo. Sin embargo, a priori los agentes permiten automatizar tareas que otras soluciones no pueden, precisamente por su capacidad de decidir 'ellos mismos' qué hacer en cada momento, siendo capaces de acometer automatizaciones de tareas que un humano no sabe definir bien o tareas sometidas a muchas incertidumbres o variantes que son difíciles de reflejar en un workflow. 

En cuanto al segundo punto, probablemente podamos considerar que los agentes proporcionan la misma escalabilidad que los sistemas tradicionales, quizá con una cierta penalización por su alto consumo computacional, del que me ocuparé en otro post.

Hasta aquí vamos bien con los agentes, pero en los siguientes puntos, cambian las tornas.

Así, aunque no siempre de manera grave, los agentes suelen ser más lentos de ejecución que una solución basadas en workflow. Es decir, sí que reducen el tiempo de proceso, pero algo menos que las soluciones basadas en workflow. Según el caso, la diferencia puede ser casi irrelevante o puede importar.

Pero, sobre todo, los agentes no son completamente previsibles con lo cual perdemos una parte del control y predecibilidad de otro tipo de automatizaciones. Además, podemos esperar que se produzcan algunos errores porque el agente 'alucine' o no reaccione correctamente a un escenario dado.

Exactamente por lo mismo, introducimos algún riesgo, si bien creo que pequeño, de no conseguir el cumplimiento normativo.

¿Por qué no un workflow?

Estando así las cosas, ¿Por qué, en lugar de liarnos a hacer agentes, no automatizamos directamente al modo tradicional, mediante una solución basada en un workflow?

En el fondo, y esto es lo que origina todo el post, es porque a veces parece que sólo tenemos un martillo, un martillo de oro que son los agentes, y nos parece que todo son clavos. Pero no es así, disponemos de destornilladores, llaves inglesas y mucho más, y podemos no solo clavar, sino atornillar, poner tuercas o pernos y muchas más tareas.

Probablemente, lo sensato sea diferenciar el tipo de procesos y tareas que queremos automatizar, saber si son clavos o tornillos y, con criterio, seleccionar la herramienta adecuada, no sólo el martillo.

Me reservo una posible solución

Me reservo para el último post de la serie una idea que se me ocurre, que no tengo claro cómo es de viable ni si ya se está trabajando en ella y que reconciliaría un poco las diferentes visiones y podría convertir a nuestro martillo, los agentes, en una especie de navaja suiza.

Conclusiones

Los agentes de IA son una forma de automatización que, si bien comparte bastantes ideas con otras formas de automatización existentes, aportan sobre todo su planificación y decisión en tiempo de ejecución con base en un modelo de lenguaje razonador.

Esto es enormemente potente y diferencial pero, sin embargo, puede que no sea siempre la mejor solución. A lo mejor, hay casos en que siguen siendo preferibles soluciones basadas en reglas y workflows.

Workflows, agentes y una automatización de baja intensidad

Ya desde hace muchos años, desde que la informática tomó cierta presencia en las organizaciones, uno de sus objetivos ha sido la automatización de procesos, una tarea esencial para lograr calidad, escalabilidad y eficiencia.

En busca de este objetivo, muchas son las tecnologías o tipologías de soluciones que se han aplicado.

Algunas soluciones tradicionales de automatización 

En mi segundo libro, 'Robots en la sombra', hago un repaso de las tecnologías de automatización de procesos. De entre ellas, dos son las grandes protagonistas.

Por un lado, y dentro de las soluciones que denomino 'conscientes de proceso' (implementan procesos de negocio aunque éste no es editable y se refleja de manera implícita) las grandes protagonistas son los sistemas empresariales, los ERP ('Enterprise Resource Planning') y los CRM ('Customer Relationship Management') tan importantes en los mapas de sistemas de las empresas y administraciones ya desde los años ochenta y primeros noventa del siglo pasado y aún en plena forma hoy en día, generalmente en forma de soluciones SaaS ('Software as a Service') desde la nube.

Por otro, tenemos los sistemas orientados a proceso (sistemas en que el proceso de negocio se modela y gestiona de forma explícita y ese modelo de  proceso es la base de la digitalización y automatización). En este campo caen los BPMS ('Business Process Management Systems'), inicialmente denominados sistemas de worfklow y actualmente con frecuencia denominados, de manera incorrecta, simplemente BPM.  También se incluyen los 'Case Management Systems' (CMS) habitualmente integrados como producto con los anteriores.

Por el camino, muchas otras soluciones de nicho o alcance menor como las soluciones ITSM (implementando procesos ITIL) o, a pequeña escala, las macros. 

Llegan los robots software

Hace unos años surgió una solución alternativa de automatización, más orientada a tareas y pequeños procesos que a procesos de negocio extremo a extremo, y más orientadas también a complementar la infraestructura IT y de automatización ya existente que a crear soluciones completas extremo a extremo. 

Hablo, fundamentalmente, de la Automatización Robótica de Procesos, RPA ('Robotic Process Automation') en que se crean unos módulos software, los robots, que implementan pequeños procesos basados en un flujo (con sus pasos o actividades, sus condiciones, ramificaciones y bucles y con sus variables de proceso) pero capaces, sobre todo, de interactuar con todo tipo de recursos IT externos, documentos y aplicaciones, bien sea interaccionando con pantallas (lo que constituye el origen de RPA) o mediante APIs y conectores.

Los robots RPA se constituyen así en una suerte de orquestadores o integradores de otros recursos y aplicaciones, uniendo y dando continuidad a las capacidades de automatización o almacenamiento de información de cada uno de esos recursos.

Los robots RPA eran protagonistas principales de mi libro 'Robots en la sombra' ya citado.

Pero en ese libro había otros protagonistas, los chatbots, otra forma de robots software pero estos fundamentalmente orientados a interactuar con humanos aunque luego, en background, también acceden, y hasta cierto punto orquestan, otros recursos como sistemas y servicios.  

Por detrás de los BPMS y, sobre todo, de los robots RPA, existe un flujo, un workflow que contiene la lógica que enlaza las diversas actividades, tareas y acciones.

La automatización visual de flujos

Y, precisamente alrededor de ese concepto de flujo o workflow surgen otro tipo de soluciones que es de las que fundamentalmente quería hablar aquí, una serie de soluciones que tienen mucho en común con RPA, pero con alguna pequeña, aunque notable, diferencia.

Estoy hablando de un tipo de soluciones que, hasta donde se me alcanza, no han cristalizado en un nombre de categoría de producto, aunque algunos de los que he podido ver que se les aplican son iPaaS ('integration Platform as a Service'), plataformas de automatización de workflow ('workflow automation platoforms') o, incluso, automatización visual. En sus orígenes, y para versiones que creo simples, también se aplicaba el término IFTTT ('If This Then That') significando que lo que hacían es, ante un estímulo o evento, ejecutar una acción.

¿En qué consisten?

Básicamente, permiten construir flujos de trabajo ('workflows') mediante en enlazado en serie o bien con ramificaciones, condiciones y bucles, de una serie de tareas, actividades o pasos. Esas tareas, en general, se realizan mediante la lectura, escritura o invocación de datos y capacidades externas a las que se accede mediante conectores que recubren las APIs correspondientes. Estos flujos pueden ser invocados externamente por un usuario o por otros programas, pero también pueden programarse para ejecución planificada o lanzarse automáticamente ante la detección de un evento. Internamente manejan variables y, sobre todo, lo que se suele denominar 'contenido dinámico' que son variables generadas de forma automática por el flujo sin que el desarrollador deba ocuparse de definirlas (y sólo tenga que usarlas).

¿Cuál es el valor que ofrecen este tipo de herramientas?

• Por un lado, son herramientas en que el desarrollo de un flujo es muy sencillo porque se apoyan en entornos visuales conforme a las filosofías 'Low Code / No Code'.


• Por otro, ofrecen una amplísima colección de conectores que permiten, de forma simple, el acceso a todo tipo de aplicaciones (prácticamente cualquier aplicación conocida) y recursos (correo, sistemas empresariales, documentos ofimáticos, redes sociales, etc) incluyendo los modernos modelos de lenguaje o soluciones de IA.


• Además, ofrecen una larguísima y creciente colección de plantillas ('templates') con flujos ya construidos y casi listos para ser usados.

El lector avezado se dará cuenta de que se parecen mucho a RPA. En efecto, son soluciones muy similares. La diferencia habitual entre ambos tipos de herramientas es que estas de que hablamos ahora,  normalmente sólo se pueden ejecutar en la nube, no pudiendo acceder a recursos o ficheros locales del ordenador del usuario (sólo pueden acceder a ficheros en la nube, típicamente en OneDrive o Google Drive) y tampoco siendo capaces de interactuar con las pantallas de aplicaciones. Por su parte las soluciones RPA sí que son capaces de acceder a recursos locales y pantallas y tienden a ser herramientas algo más sofisticadas.

Entre las herramientas de esta categoría algo indefinida tenemos soluciones como Make, Zapier o N8N e, incluso Power Automate Cloud, la parte de Power Automate que opera en la nube.

Agentes

Y ahora tenemos también los famosos agentes de la agentic AI, que también se parecen mucho a RPA. La gran diferencia de los agentes de la Agentic AI respecto a RPA, y también respecto a las soluciones de automatización de workflow que acabamos de ver, es que, en los agentes el flujo, el workflow, no es explícito, sino que se realiza conforme a planes que genera de forma dinámica un modelo razonador y que la forma de especificar los objetivos de esos agentes suele basarse en lenguaje natural.

Hibridación

Existe, no obstante un gran solape e hibridación entre las soluciones que acabamos de ver: soluciones de automatización de flujos, robots RPA, agentes, chatbots (especialmente los chatbots modernos basados en modelos generativos) e, incluso, soluciones BPMS.

De hecho, en uno de sus últimos cuadrantes mágicos, Gartner habla de 'Business Orchestration and Automation Technologies (BOAT)' y en ese cuadrante mágico vemos soluciones que normalmente encuadraríamos como BPMS, junto con otras de tipo RPA y alguna de automatización de workflows.

La automatización de baja intensidad... que puede ser todo lo contrario

En efecto, lo que se ve en este tipo de soluciones (RPA, workflows y agentes) es el foco en la automatización muy sencilla, no de grandes procesos de negocio, sino de tareas concretas o de procesos muy sencillitos pero que involucran a dos o tres sistemas.

Por eso en mi mente surge la idea de una automatización de baja intensidad, aunque el nombre correcto sería, mas bien, el de una automatización de baja complejidad, porque, en efecto, son herramientas sencillas, al alcance de personas no desarrolladoras, poniendo la automatización al alcance de cualquiera y, por tanto, lo que creo que están consiguiendo, o pueden conseguir, es una altísima intensidad de automatización, especialmente en PYMEs e incluso autónomos, es decir, automatizaciones sencillas...pero en gran cantidad.

Conclusiones

Desde hace unos pocos años tenemos un conjunto de nuevas soluciones de automatización, centradas en flujos y tareas relativamente simples y que, además, son de uso muy sencillo, lo que puede llevar a una automatización básica, pero masiva.