Hablemos de agentes (VI): herramientas

Aunque cuando hablamos de agentes en el entorno de la 'Agentic AI', tendemos destacar la inteligencia artificial y concentrarnos en sus capacidades de razonamiento y autonomía, lo que realmente convierte en agentes a ese tipo de software no es realmente su inteligencia, sino su capacidad de actuar.

Recordemos que agente proviene, etimológicamente, de 'agere' (hacer) y que desde una larga tradición que explicamos en el primer artículo de esta serie, hablamos de entes (sean de inteligencia artificial o sean seres vivos) con capacidad de percibir su entorno (sentirlo) y de actuar sobre él.

Sin actuación no hay agencia, por mucha inteligencia que tenga la entidad.

En el caso de los agentes de la 'Agentic AI', su capacidad de actuar sobre el contexto proviene del uso de las denominadas, simplemente, herramientas ('tools').

Vamos a comentar algunas ideas sobre estas herramientas apoyándonos, como hasta ahora en esta serie de posts, en el contenido del libro 'Building Agentic AI systems' de Anjanava Biswas y Wrick Talukdar.

¿Qué es una herramienta?

Sin ponernos demasiado académicos (la verdad es que tampoco hay mucho espacio para el 'academicismo'), una herramienta no es más que un mecanismo que permite a un agente ponerse en contacto con el exterior, pudiendo, de esa forma, obtener información externa, solicitar acciones a entes externos y, en fin, extender sus capacidades, fundamentalmente de actuación, hacia otros elementos digitales e, incluso, hacia elementos físicos.

Mediante herramientas, un agente puede leer de una base de datos externas, invocar un API en la nube, acceder a un fichero local o, incluso, recoger información de un sensor o activar alguna forma de actuador físico. 

Tipos de herramientas

Aunque, en el fondo, una herramienta puede ser casi cualquier cosa que podamos crear digitalmente y poner al alcance del agente, en la obra citada se nos ofrece una clasificación de herramientas que puede resultar ilustrativa.

• APIs: mecanismo fundamental y que casi recubre al resto. Mediante APIs podemos acceder a otros sistemas o a servicios locales o en la nube...un universo de posibilidades.


• Herramientas de bases de datos: permiten el acceso a bases de datos para el almacenamiento y recuperación de datos. Con esto, además, se consigue persistencia de la información y poder acceder a información del pasado.


• Funciones de utilidad: software personalizado que se ejecuta localmente en el mismo entorno que el agente y que pueden absorber tareas como el procesamiento y análisis de datos, cambios de formato o cálculos matemáticos.


• Herramientas de integración: Herramientas para interconexión de sistemas y que permiten tareas como sincronización de calendarios, procesamiento de documentos o gestión de ficheros.


• Herramientas de interfaz con hardware: herramientas que permiten la interacción con dispositivos físicos y que pueden ser usados en soluciones procesamiento de información de sensores, Internet de las Cosas o robótica, por ejemplo.

En realidad, diría que existe un cierto solape entre las tipologías propuestas y diría también que casi todas ellas se pueden considerar una forma más o menos especializada de API. Echo también en falta la inclusión de las soluciones de interacción con sistemas mediante sus pantallas, usando técnicas como 'screen scraping' tan comunes en RPA ('Robotic Process Automation') pero que han sido adoptadas también por agentes como en el famoso vídeo-demostración de 'Operator' de Open AI.

Sea como fuere, la clasificación vista nos ofrece una panorámica del tipo de cosas que las herramientas pueden poner al alcance de un agente.

El controlador

Desde que oí hablar por primera vez de este tipo de agentes, agentes cuyo cerebro es un gran modelo de lenguaje o un modelo fundacional, siempre me pregunté cómo se producía, ya en detalle, la invocación de, por ejemplo, una API por parte de un modelo de lenguaje.

Aunque calculo que pueden existir otras soluciones técnicas y que, incluso, en el futuro puedan aparecer otros planteamientos, en el libro mencionado al principio del post nos explican una solución que es muy sencilla y fácil de entender.

Lo que nos dicen es que, realmente, el modelo de lenguaje no invoca a las herramientas. Existe otra pieza, el controlador del agente, que realmente centraliza la lógica.

Es el controlador el que interacciona con las personas recogiendo sus peticiones (los 'prompts') y trasladándole a los usuarios la respuesta final del modelo de lenguaje. 

Es el controlador quien interactua con el modelo de lenguaje, trasladándole a su vez los 'prompts' del usuario y recibiendo, o bien las respuestas del modelo de lenguaje, o bien la petición de invocación a una herramienta.

Y es el controlador, finalmente, quien invoca realmente a las herramientas y quien devuelve al modelo de lenguaje la respuesta de esas herramientas.

En cierto sentido, el verdadero agente sería el controlador, aunque la inteligencia, y 'la magia', la ponga el modelo de lenguaje.

Aspectos a tener en cuenta

De cara a la implementación de unos agentes robustos, se nos sugiere tener en cuenta los siguientes aspectos:

• Composición y encadenado: Es decir, los agentes habitualmente no invocan a una herramienta aislada sino que conforman flujos de trabajo ('workflows'), encadenando diversas llamadas a herramientas.


• Selección y decisión: quizá, y como bien destaca la referencia en que nos apoyamos, uno de los elementos más críticos en los agentes. En el caso de sistemas más tradicionales y basados en reglas o flujos predefinidos, como es el caso de la ya mencionada RPA, esta selección se realiza, habitualmente, en tiempo de diseño y es el desarrollador quien la marca de acuerdo con las reglas de negocio y la lógica del robot/agente. Pero, en el caso de los agentes de la Agentic AI, dotados de una mayor inteligencia pero también que 'deciden sobre la marcha', la selección de la herramienta adecuada no es trivial y para realizarla los agentes deben evaluar el contexto y los requisitos en cada momento. En algunos casos, además, el agente se puede encontrar con la situación de que exista más de una herramienta adecuada y debe ser capaz de seleccionar la mejor.


• Manejo de errores: Como en cualquier forma de software, incluso cualquier forma de automatización, es necesario prever las situaciones de error y las necesidades y mecanismos de recuperación, algo que puede llegar a ser más complejo que la propia actuación en los casos 'happy path'.


• Gestión del estado de la herramienta: En algunos casos, las herramientas necesitan acciones de inicialización o de 'limpieza'. Por ello, los agentes deben manejar adecuadamente los estados de las herramientas y realizar correctamente, por ejemplo, la asignación y liberación de recursos.


• Actualizaciones y versionado de herramientas: Como toda forma de software, las herramientas evolucionan con el tiempo y aparecen nuevas versiones. Por ello, los agentes deben ser capaces de gestionar esas actualizaciones, incluyendo asuntos como la compatibilidad o el dejar de usar funcionalidades obsoletas, así como adaptarse a las nuevas interfaces de las herramientas.


• Seguridad y control de acceso: los agentes también han de tener en cuenta los aspectos de seguridad, como gestión de credenciales, especialmente cuando acceden mediante herramientas a datos sensibles o recursos críticos.

Agentes, RPA y herramientas

Como ya comentaba en su momento en el post 'La hibridación de los robots software: agentes frente a RPA y robots conversacionales', los agentes tiene diversos aspectos en común con los robots RPA ('Robotic Process Automation') y, probablemente, donde más coinciden e, incluso, en algunos aspectos se solapan, es precisamente en su uso de herramientas para la interacción con entornos digitales, aplicaciones y documentos, fundamentalmente, mediante APIs, conectores e, incluso, automatización de interfaz de usuario mediante 'screen scraping' como indicaba más arriba.

Conclusiones

Mediante el uso de herramientas, los agentes se puede poner en contacto con el mundo exterior y realizar todo tipo de acciones de lectura (datos o información de sensores), escritura y actuación.

Son las herramientas las que realmente convierten en agentes a este tipo de aplicaciones inteligentes.

Y la unión de la inteligencia del modelo de lenguaje, con las capacidades de actuación de las herramientas, abre unas inmensas posibilidades.

Artículos de este blog relacionados

• Hablemos de agentes (V): reflexión e introspección
• Hablemos de agentes (IV): sistemas multi-agente
• Hablemos de agentes (III): arquitecturas reactivas, deliberativas e híbridas
• Hablemos de agentes (II): auto-gobierno, agencia y autonomía
• Hablemos de agentes (I): concepto, contexto y tres características esenciales

La fábula del robot y la hormiga

Érase una vez un pequeño robot, alegre y entusiasta, que le gustaba trabajar con otros robots y colaborar para la consecución de grandes objetivos.

Había oído campanas sobre una disciplina, 'swarm robotics' (robótica de enjambre) que buscaba justo eso, la colaboración entre robots para alcanzar logros fantásticos.

Pero el pequeño robot no sabía cómo hacerlo, y vagaba despistado y un poco al azar, deseoso de colaborar con otros robots pero sin saber qué hacer.

Hormigas y búsqueda de alimento

Y deambulando andaba cuando se topó con un hormiguero. Dirigió su cámara hacia la entrada del hormiguero y, no sin forzar para ello su algoritmo de detección de objetos, se admiró al ver enormes cantidades de pequeños seres que interactuaban entre sí, cuidaban larvas y a la hormiga reina, defendían el hormiguero y, sobre todo, establecían largas filas en búsqueda, exitosa por cierto, de alimento.

Este último aspecto fue lo que más llamó la atención de nuestro pequeño robot. ¿Cómo eran capaces las hormigas de deambular por grandes espacios de terreno, comunicarse entre sí los hallazgos y, de forma eficiente, establecer esas largas filas de pequeñas obreras en busca de los preciados nutrientes? Parecía magia.

Así que, ni corto ni perezoso, el robot 'se plantó' delante de una hormiga y se lo preguntó. Dime admirada hormiga, ¿Cuál es vuestra magia? ¿Cómo os organizáis para encontrar el mejor camino hasta vuestro alimento?

Y lo que le contó la hormiga le fascinó, por lo eficaz y por lo sencillo.

Querido y metálico robotito, le dijo la hormiga, el secreto no está en la masa, como las pizzas, sino en las feromonas.

¿Y qué es eso de una feromona? volvió a la carga el robot

Pues las feromonas son sustancias químicas específicas que 'soltamos por ahí' y que otras hormigas detectan y así permanecen a modo de rastro durante un tiempo aunque hay que reconocer que poco a poco se evapora. Pero eso tampoco nos viene mal.

Vale pero ¿y cómo lo hacéis? ¿Cuál es vuestro algoritmo?

No tengo ni idea de lo que es un algoritmo, replicó la hormiga, pero sí te puedo contar cómo trabajamos.

Cuando no tenemos ni idea de dónde hay alimento, cuando 'partimos de cero' por decirlo de alguna manera, simplemente nos movemos al azar, a ver qué encontramos. Pero si tenemos suerte, si una de nosotras encuentra alimento, no se queda ahí admirándolo o 'poniéndose morada' sino que retorna al hormiguero, y por el caminos vamos soltando nuestro rastro de feromonas. Además, si el camino es cortito, dejamos un rastro más grueso de feromonas, para indicar a las compañeras que esa localización es 'guai' porque por muy obreras y 'hormiguitas' que seamos, si nos cuesta poco llegar al alimento, pues mejor ¿No te parece?

Y claro, como no somos tontas, si cuando vamos a salir en búsqueda de alimentos ya hay rastros de feromonas, pues nada de búsqueda al azar, sino que seguimos los rastros que ya existen, que para algo otras nos han hecho el trabajo. Eso si. no nos olvidamos de hacer nuestra aportación y depositar nuestras propias feromonas en ese camino..

¿Te das cuenta de lo simple que es esto, pequeño ingenio metálico?

Si al grueso del rastro que dejamos, mayor cuanto más corto el camino, unimos la evaporación, los caminos cortos tenderán a tener más feromonas que los largos, tanto porque depositamos más feromonas como porque da menos tiempo a que se evaporen antes de que lleguen nuevas compañeras. Sin embargo, los rastros de feromonas en los caminos más largos, tenderán a desaparecer. Y claro, las nuevas hormigas refuerzan, con sus propias fermonas, esas feromonas de los caminos más cortos.

Y de esa forma tan tonta, al final, es como optimizamos la búsqueda de alimento, porque, casi sin querer, sólo depositando 'como Dios manda' nuestras feromonas y siguiendo adecuadamente el rastro de feromonas de otras que nos precedieron, acabamos encontrando el camino óptimo hasta nuestro alimento.

¿Cómo lo ves?

El algoritmo ACO ('Ant Colony Optimization')

Muy admirado quedó el robot de la habilidad de las hormigas y de cómo, con mecanismos muy sencillos, habían resuelto y optimizado un problema complejo. 

Se despidió amablemente y se dijo: yo tengo que hacer lo mismo con otros robots.

Pero ¿Cómo lo hago, si yo no tengo feromonas?

Vale, feromonas no, pero sí que tengo estructuras de datos, algoritmos y capacidad de comunicación. Y otros robotitos como yo también los tienen.

Así que, pensando, pensando, llegó a conclusión de que podía representar mediante grafos las posibles opciones y los caminos entre ellas y que los diferentes robots compartiesen esa información. ¿Y las feromonas? ¿Qué serían? ¿Cómo marcarían los caminos? Pues nada, unos simples valores numéricos asociados a cada arco del grafo, e inicializados a cero al principio.

Al inicio, los robots elegirían recorrer el grafo de forma aleatoria o probabilista y cada robot, al recorrer el grafo, aumentaría un poco ese nivel de las feromonas numéricas de los arcos recorridos.

Pero claro, con eso sólo no valía, porque tendríamos más y más feromonas hasta el infinito. Así que el robot pensó en simular la evaporación mediante una función parametrizada mediante una tasa de evaporación, y que se ocupase de poco a poco disminuir el nivel de feromonas de los arcos (el numerito en cada arco) si no se producían nuevas aportaciones de feromonas.

Y así lo hizo. Y convenció a otros robots para que colaborasen con él usando el mismo algoritmos. Y fueron felices resolviendo colaborativamente problemas y consiguiendo grandes objetivos.

Moraleja

Cuando tienes que resolver un problema computacional complejo, no dejes de observar por si acaso la naturaleza por si algún ser vivo, o la propia naturaleza, lo ha resuelto ya, porque si es así, probablemente te inspire una solución válida y eficiente, y, lo que es más, con frecuencia basada en mecanismos sorprendentemente simples.

Nota

Aunque hemos atribuido a nuestro robot la invención del algoritmo ACO ('Ant Colony Optmization'), lo cierto es que esté fue diseñado por Marco Dorigo ya en los años noventa y que yo he tenido noticia de él y me he inspirado en el libro 'Robotic algortihms' de Gareth Morgan Thomas.

Hablemos de agentes (V): reflexión e introspección

Algunas de las características que exhiben los agentes, los agentes artificiales basados en AI me refiero, emulan, aunque sea a grandes rasgos, las características cognitivas humanas e, incluso, suelen adoptar el nombre de éstas.

Tal es el caso de la reflexión ('reflection') e introspección ('introspection') de que nos ocupamos en este post, el quinto ya que dedico a los agentes de la Agentic AI y para cuyo desarrollo me apoyo en gran medida en el contenido del libro 'Building Agentic AI systems' de Anjanava Biswas y Wrick Talukdar.

Veamos ambos conceptos.

Reflexión ('reflection')

Respecto a la reflexión ('reflection'), los autores nos dicen

Reflection in LLM agents refers ​to their ability to examine their own thought processes, evaluate their actions, and adjust their approach.

Aunque los autores hablan de reflexión en el ámbito de agentes basados en LLMs ('Large Language Models'), que en el fondo son los que más nos interesan, en realidad creo que la definición vale para cualquier tipo de agente: la reflexión es la capacidad de un agente para examinar su propio proceso de pensamiento, evaluar sus propias acciones y ajustar su comportamiento futuro en consecuencia.

En ese proceso de reflexión el agente puede, de alguna manera, repetir ('replay') deliberaciones pasadas y los resultados obtenidos, con lo que puede tomar decisiones más informadas en el futuro.

Con base en ese análisis, se produce una adaptación ('adaptation') del agente, lo que significa que el agente cambia su estrategia con base en esa información.

Introspección ('introspection')

Muy relacionado con la reflexión, yo diría que casi se confunde con ella, tenemos el concepto de introspección ('introspection'). Los mismos autores definen introspección (referida a agentes inteligentes) como 

Introspection refers ​to the process by which an intelligent ​agent examines and analyzes its own cognitive processes, decisions, and behaviors.

Cunado un agente aplica introspección evalúa su propio razonamiento lo que le permite detectar errores, sesgos o ineficiencias. 

Aparte de, en general, la mejora en su desempeño, la introspección ayuda a un agente a gestionar la incertidumbre y la ambigüedad.

Implementación de capacidades reflexivas

A la hora de implementar esas capacidades de reflexión o introspección, es decir, de monitorizar, evaluar y mejorar su propio desempeño, los autores nos muestran cuatro grandes estrategias o técnicas para hacerlo, a saber:

• Razonamiento tradicional: Aplica estrategias tradicionales basadas en reglas, algoritmos o patrones. Más que en el proceso de razonamiento, se centran en los objetivos y resultados


• Metarazonamiento ('metareasoning'): En este caso sí que el foco se pone realmente en el razonamiento.


Autoexplicación ('self-explanation'): La auto explicación es el proceso por el que los agentes verbalizan su proceso de razonamiento. Esto, por un lado, y de cara al usuario humano, facilita la trasparencia ya que genera explicaciones sobre cómo ha llegado a una conclusión. Sin embargo, esta explicación también puede ser usada por el propio agente para reflexionar sobre su modo de funcionamiento (no olvidemos que los agentes de la Agentic AI se suelen basar en grandes modelos de lenguaje, que trabajan muy bien con información verbal).


Automodelado ('self-model'): El automodelo no deja de ser un modelo interno que el agente mantiene acerca de su conocimiento, objetivos y creencias. Este modelo sirve de base para el razonamiento. Como consecuencia de la reflexión o la introspección dicho modelo puede ser actualizado, modificando así el comportamiento futuro del agente

Aunque así descritas estas cuatro grandes técnicas puedan parecer abstractas y quizá algo teóricas, decir que en el libro que utilizo como base sus autores, no sólo detallan más estas capacidades sino que, además, muestran código python que las implementa para un caso de uso concreto y utilizando el framework CrewAI.

Conclusiones

Una de las características de los agentes, de varios tipos de agentes pero en este caso específicamente de los agentes de la AgenticAI, es su capacidad para la reflexión y la introspección que les permite monitorizar, evaluar y mejorar su desempeño basándose en el examen y mejora de sus propios mecanismos de razonamiento.

Una capacidad cognitiva avanzada que les confiere capacidad de adaptación y de manejo de la incertidumbre y que no se queda en un planteamiento meramente teórico, puesto que ya hay implementaciones reales para los mismos.

Hablemos de agentes (IV): sistemas multi-agente

En este post, el cuarto de la serie dedicada a hablar de agentes, vamos a dar el salto de considerar un agente individual, como hemos hecho hasta ahora (y como, con frecuencia, haremos en futuros artículos), a mirar hacia una multitud de agentes interaccionando entre sí.

Y, como en los posts anteriores de esta serie, la argumentación fundamental la obtendremos del libro  'Building Agentic AI systems' de Anjanava Biswas y Wrick Talukdar.

Un paradigma que viene de antiguo

Antes no puedo evitar una consideración. Esta idea de los sistemas distribuidos, integrados por unos módulos (que ahora llamamos agentes) que colaboran entre sí para resolver un problema o conseguir un objetivo, no es algo nuevo ni mucho menos.

Es un paradigma recurrente, que aparece una y otra vez a lo largo de la historia de la computación.

Por poner un ejemplo, cuando surgió con fuerza el paradigma de la programación orientada a objetos, allá hacia finales los años noventa (¡Uf! el siglo pasado), a veces se hablaba de los objetos precisamente como módulos que colaboraban entre sí para resolver un problema. No se me olvida una conferencia que pronunció en la ya desaparecida Telefónica Investigación y Desarrollo, allá por el año 94 o así, el mismísimo Grady Booch, a la sazón reconocido como experto en metodología de orientación a objetos, y cómo utilizó, como metáfora visual, la de las hormigas, precisamente por ese trabajo en colaboración entre los objetos.

Un poco en esa línea, surgió poco después la ya muy olvidada arquitectura CORBA ('Common Object Request Broker Architecture') que daba la base para un sistema de objetos distribuidos que podían colaborar entre sí.

Lo cierto es que aunque, en efecto, los objetos como tales han sido un éxito, no lo han sido tanto como sistemas colaborativos, sino mediante paradigmas de invocación y respuesta (una especie de cliente/servidor) con una lógica dirigida y que se aleja de la visión colaborativa de igual a igual. 

Y como estos, hay seguro muchos más ejemplos.

A pesar de esa recurrencia, creo que el éxito práctico de estos sistemas distribuidos de módulos colaborativos, entendiendo como éxito que se trate de un paradigma dominante y muchas implantaciones, yo lo juzgo, al menos hasta ahora, como bastante limitado.

¿Y por  qué sucede esto?

Pues, a bote pronto, diría que porque esos sistemas distribuidos son de un ámbito de aplicación más de nicho y porque creo que son inherentemente más complejos, así que, aunque como idea es muy atractiva (y tiene y tendrá ámbitos de aplicación interesantísimos) la mayor parte de las veces seguimos recurriendo a sistemas no distribuidos / colaborativos bastante más sencillos en la práctica.

Definición

En cualquier caso, el paradigma de los módulos que colaboran de igual a igual, vuelve con cierta fuerza en la Agentic AI en forma de sistemas multi-agente.

Los autores citados arriba, definen un sistema multiagente (MAS, 'Multi-Agent System') como:

un sistema compuesto por múltiples agentes autónomos que pueden interactuar, colaborar y cooperar para alcanzar objetivos compartidos.

Como se observa de la definición, lo importante no es sólo la modularidad sino, mucho más importante, la autonomía de esos agentes y la cooperación en la consecución de objetivos

Características

Los autores identifican las siguientes como las características fundamentales de los sistemas multi-agente:

• Autonomía: Cada agente es independiente y se autogobierna con base en su percepción del entorno y sus objetivos. No existe un control centralizado.


• Interacción: Los agentes se comunican entre sí mediante protocolos establecidos que les permiten intercambiar información, negociar tareas y coordinarse.


• Adaptabilidad: Estos sistemas exhiben la capacidad de adaptarse y cambiar su comportamiento como respuesta a cambios en el entorno o en los objetivos de los agentes individuales.


• Control distribuido: Como decíamos, el control no es central, sino distribuido entre los agentes. Esta forma de actuar proporciona resiliencia al conjunto frente a un eventual mal funcionamiento de un agente concreto.


• Escalabilidad: Se trata de un planteamiento inherentemente escalable mediante la adición o eliminación de agentes en el sistema.


• Heterogeneidad: Los agentes individuales dentro de un sistema multi-agente pueden ser diferentes entre sí, con diferentes capacidades y diferentes objetivos. Esto permite añadir nuevas posibilidades al conjunto.


• Conocimiento y datos distribuidos: No sólo el control, también el conocimiento y los datos se encuentran distribuidos entre los agentes, proporcionando robustez al conjunto al evitar puntos únicos de fallo.

Mecanismos de interacción

Existen, tres esquemas o mecanismos básicos de interacción entre los agentes de un sistema multi-agente, a saber:

• Cooperación: Los agentes trabajan conjuntamente para conseguir un objetivo común, un objetivo que, además, normalmente no pueden alcanzar por separado. Un ejemplo sería la cooperación de personas, drones y vehículos robóticos en la localización y rescate de víctimas de una catástrofe natural como un terremoto.


• Coordinación: En este caso, existen interdependencias debido a solapes e incluso conflictos entre las responsabilidades y acciones de los diferentes agentes y es necesaria esa mayor coordinación. Algunos mecanismos de coordinación pueden ser la planificación de tareas, la asignación de recursos, etc. Podría ser el caso de robots colaborando en un proceso de producción.


• Negociación: En este mecanismo los agentes alcanzan acuerdos entre ellos para la compartición de recursos, reparto de tareas, etc. Implica que los agentes hagan ofertas, contraofertas y alcancen compromisos. Utilizan técnicas como votaciones, subastas, etc. Tienden a aplicarse en situaciones de recursos limitados u objetivos que compiten entre sí.

Se observa que, como esquemas de trabajo e interacción, son muy genéricos y aplican a todo tipo de agentes, no sólo los agentes de la Agentic AI, aunque sea en ese contexto en que se mencionan en la obra citada y en que los traemos a colación en este post..

Además, y aunque no lo veremos aquí, esos mecanismos se pueden (y deben) concretar en protocolos específicos y detallados de interacción, algo de lo que seguramente hablemos en otro momento en esta serie.

Una conexión a explorar: swarm robotics

Hay una conexión, o un caso particular, si se quiere que, antes o después, espero explorar en este blog. 

Se trataría de la relación de esto que estamos viendo como sistemas multi-agente con la denominada robótica de enjambre ('swarm robotics').

Desde un punto de vista conceptual, sin ninguna duda esos enjambres de robots son sistemas multi-agente. Lo que quiero explorar es ya en el detalle de protocolos y algoritmos y comprobar cuántas coincidencias hay o si vemos realizaciones especializadas.

Conclusiones

Como vemos, el paradigma de los sistemas multi-agente viene de antiguo y existen planteamientos interesantes sobre su realización, aunque, quizá, todavía de no mucha implantación.

Quizá, el interés más inmediato sea comprobar hasta qué punto los nuevos agentes de la Agentic AI basados en LLMs o modelos fundacionales nos pueden permitir construir sistemas multi-agente prácticos y efectivos y de una manera relativamente sencilla.

Artículos de este blog relacionados

• Hablemos de agentes (III): arquitecturas reactivas, deliberativas e híbridas
• Hablemos de agentes (II): auto-gobierno, agencia y autonomía
• Hablemos de agentes (I): concepto, contexto y tres características esenciales