Hablemos de agentes (IX): entorno, memoria y contexto

En los posts publicados de esta serie hemos visto una gran cantidad de aspectos de los agentes. 

Algunos, como la introspección, implican una forma de reflexión y análisis, otros como la planificación se vuelcan de alguna manera hacia el futuro y lo que hay que hacer y otros, en fin, como las herramientas, relacionan al agente con su entorno.

Sin embargo nos falta añadir algunos ingredientes más, unos ingredientes que añaden al agente una especie de conciencia global de entorno en que se mueve, de la situación en qué se encuentra, cómo ha llegado hasta ella y lo aprendido.

En este posts vamos a esbozar algunos de esos mecanismos, si se quiere, de visión más global y de una suerte de entendimiento de la situación.

Seguimos en lo fundamental, como siempre en esta serie, las aportaciones del libro 'Building Agentic AI systems' de Anjanava Biswas y Wrick Talukdar. 

Entorno y espacios de estados

Uno de los elementos que el agente debe conocer y modelar de alguna forma es el entorno con el que interacciona.

Los autores nos hablan de mantener un espacio de estados ('state space') para reflejar la situación del entorno. Nos hablan de estados aunque, cuando nos ejemplifican cómo puede ser ese modelado, vemos que no hablamos de estados en el sentido de etiquetas que resumen, en una sola calificación, la situación global del entorno sino que, en realidad, lo que nos muestran son una serie, no necesariamente pequeña, de variables que caracterizan la situación de ese entorno. 

Para que quede más claro, traigo ejemplos propuestos por ellos mismos en el caso de uso de la gestión de un viaje. Así, nos incluyen dentro del espacio de estados información sobre el cliente, como sus preferencias o presupuesto, información sobre hoteles como disponibilidad o sobre la previsión del tiempo.

Aunque hablamos de estado, se observa que en realidad son datos que caracterizan el entorno en que se mueve el agente.

Memoria del agente

El agente también debe de mantener alguna forma de memoria, información de lo que ha pasado hasta el momento y lo aprendido hasta ahora. Los autores nos proponen una estructuración de esa memoria en tres tipologías que, hasta donde se me alcanza reproducen unos tipos de memoria que son reconocidas, incluso con el mismo nombre, en los humanos y en el ámbito de la psicología cognitiva.

En concreto, nos hablan de:

• Memoria de trabajo (corto plazo): sirve como espacio de trabajo inmediato. Mantiene información sobre la tarea actual o la interacción actual.


• Memoria de largo plazo: Se trata de un almacenamiento de información y conocimiento permanente, conteniendo información que es valiosa más allá de una interacción o situación concreta y que debe de estar disponible y accesible durante largos periodos de tiempo. Es el soporte para el conocimiento acumulado o los patrones aprendidos. Puede ser útil, por ejemplo, y en el contexto de la atención a un cliente, para recordar sus características y preferencias y proporcionar un trato personalizado.


• Memoria episódica: Se trata de un tipo de memoria especial ligada a lo que se denominan episodios discretos. Los autores no dan una definición de lo que es un episodio pero podemos entender que vendrían a ser un conjunto de sucesos lógicamente enlazados. Así, se me ocurre decir que un episodio es, por ejemplo, todo lo que ocurre durante la gestión de una reclamación, durante la tramitación de un expediente, durante la gestión de un viaje o durante un ingreso hospitalario. Es decir, los episodios se extienden durante un tiempo acotado, tienen principio y fin y, durante el transcurso de cada episodio, se producen interacciones y eventos. Pues bien, la memoria episódica, precisamente, pone foco, sobre todo, en la secuencia temporal y el contexto de los eventos.

El contexto

Finalmente, los autores nos hablan de la gestión del contexto que permite al agente tener una conciencia adecuada de la situación actual y también de la información histórica relevante.

Gestionar el contexto no sería más, hasta donde se me alcanza, que mantener las informaciones que hemos visto, estado del entorno y memorias, y usarlas adecuadamente para guiar el comportamiento del agente.

Conclusiones

Para un adecuado funcionamiento, los agentes no sólo deben de disponer de capacidades para razonar o para interaccionar con el exterior. Además, deben tener un conocimiento cierto tanto de la situación actual propia y del entorno, como de la historia, incluyendo el conocimiento acumulado y aprendido.

Artículos de este blog relacionados

• Hablemos de agentes (VIII): el modelo CWD para sistemas multiagente
• Hablemos de agentes (VII): algoritmos de planificación
• Hablemos de agentes (VI): herramientas
• 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

Hablemos de agentes (VIII): el modelo CWD para sistemas multiagente

Cuando hablamos de agentes en entornos relativamente sencillos tendemos a pensar en entes individuales con capacidad para razonar e interactuar con el exterior.

Y así es pero, en el caso de ciertas tareas, especialmente tareas complejas, puede ser interesante soluciones en que varios agentes colaboren en la resolución de un problema. De hecho, ya hablamos en el cuarto artículo de esta serie de los sistemas multi-agente.

Igualmente, y en el último post dedicado a la planificación, comentamos varias estrategias o algoritmos incluyendo HTN ('Hierarchical Task Network') en que, de manera jerárquica, se parte de unas tareas de más alto nivel que se van descomponiendo en tareas más concretas y detalladas.

En este artículo vamos a comentar brevemente un modelo que propone cómo estructurar una solución multi-agente, una solución que, aunque no necesariamente, podría implementar muy bien un algoritmo de tipo HTN.

Hablamos, en concreto, del modelo CWD ('Coordinator, Worker, Delegator') que se nos explica en el libro 'Building Agentic AI systems' de Anjanava Biswas y Wrick Talukdar que estoy siguiendo en esta serie de posts sobre agentes.

 

El objetivo del modelo CWD 

El modelo CWD es una propuesta sobre la estructuración de sistemas multi-agente que establece roles diferenciados y que pone el foco en la colaboración, la especialización y la distribución efectiva de tareas y recursos.

Aunque lo aplicamos en un ámbito técnico como son los agentes de la 'Agentic AI', en realidad se inspira en teorías de la organización (empresarial) y psicología organizacional.

Los tres roles: coordinator, worker, delegator

En este modelo se establecen tres roles diferenciados que le dan nombre:

• Coordinator (C): el papel de los agentes coordinadores es gestionar y supervisar el proceso o tarea de alto nivel en su conjunto. Eso incluye cosas como la priorización de trabajos, asignando tareas tendiendo en cuenta lo que es más urgente y la disponibilidad de recursos, monitorización del progreso, ajuste de asignaciones de tareas, etc. En cierto sentido, y trasladado a una organización humana, vendrían a ser algo así cómo los gerentes.


• Worker (W): Se trata de agentes que realizan las tareas propiamente dichas. En general, se trata de agentes especializados, con diferentes capacidades. Esa diversidad de capacidades o especializaciones permite una mejor división del trabajo asignando a cada agente aquella tarea o tareas para las que está mejor preparado. Trasladado a una organización humana, se trataría de los trabajadores o empleados de línea.


• Delegator (D): Actúa en un nivel intermedio entre el 'coordinator' y los 'worker'. Se ocupan del despacho de tareas y equilibrado de cargas de trabajo en los diferentes agentes 'worker'. Su tarea fundamental es la optimización del rendimiento asignando cada tarea al trabajador adecuado y en el momento adecuado. En esa labor de conseguir la máxima eficiencia, minimizan tiempos de espera (latencia), evitan cuellos de botella y maximizan la cantidad de trabajo realizado. En una organización humana vendrían a ser un suerte de capataces o jefes de equipo.

Principios

El modelo CWD sigue una serie de principios que los autores a los que seguimos en este post, concentran en:

• Separación de responsabilidades ('concerns'): Fundamental en este modelo, y como se aprecia ya por la existencia y descripción de los roles, es la separación de responsabilidades entre los diferentes agentes y tipos de agentes. Eso proporciona una optimización (cada agente se dedica a lo que mejor sabe hacer) a la vez que dota al conjunto de flexibilidad y escalabilidad.


• Organización jerárquica: con tres niveles, uno de naturaleza más de planificación y estrategia (desempeñado por el 'coordinator'), otro intermedio con foco en la eficiencia y coordinación de recursos (desempeñado por el 'delegator') y, finalmente, un nivel base, concentrado en la ejecución especializada de tareas (desempeñado por el 'worker').


• Flujos de información y realimentación: Existe una comunicación entre los diferentes roles con dos direcciones de flujo: una de arriba a abajo (del 'coordinator' al 'worker' pasando por el 'delegator') en que se establece la asignación de tareas, las prioridades y las restricciones, y otro flujo de abajo arriba ( realimentación desde el 'worker' hasta el 'coordinator' pasando por el 'delegator') en que se actualiza la información del trabajo realizado, el progreso, los resultados y la utilización de recursos.


• Adaptabilidad y resiliencia: CWD es un modelo inherentemente flexible y adaptable, lo que se concreta en las siguientes características y mecanismos:
  
  
  • Asignación dinámica de recursos: El sistema está constantemente evaluando las demandas de tareas y puede redistribuir cargas de trabajo y recursos optimizando la eficiencia y evitando cuellos de botella.
  
  
  • Redundancia y tolerancia a fallos: El uso de múltiples agentes, algunas de cuyas capacidades se solapan, permite reasignar tareas en caso de fallos de uno o varios de los agentes, permitiendo así la actuación de emergencia y la recuperación ante fallos, consiguiendo una alta disponibilidad y una operación ininterrumpida
  
  
  • Balanceo de carga: Las tareas se distribuyen de manera inteligente e informada entre los agentes disponibles con lo que se mejora la respuesta del conjunto y se evitan degradaciones de prestaciones
  
  
  • Re-asignación de roles en tiempo de ejecución: La asignación de roles puede ser dinámica pudiendo, si es necesario, asumir los agentes otros roles en busca de una mejor respuesta conjunta y una operación más continua.

Conclusiones

Vemos que el modelo CWD replica bastante la estructura de una organización humana y lo que se consigue con ello es un sistema multi-agente que, aunque pueda de primeras parecer complejo, favorece tanto la eficiencia (optimización del trabajo) como la flexibilidad (adaptación a situaciones diferentes) y la resiliencia (disponibilidad y tolerancia a fallos).

Artículos de este blog relacionados

• Hablemos de agentes (VII): algoritmos de planificación
• Hablemos de agentes (VI): herramientas
• 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

Hablemos de agentes (VII): algoritmos de planificación

Y llega el momento de tratar lo que, quizá, sea el elemento más diferencial de los nuevos agentes: la planificación que, como veremos, tiene mucho que ver con el razonamiento y, de alguna manera, la 'inteligencia'. 

Planificación y algoritmos de planificación

Intuitivamente todos tenemos una idea de lo que es la planificación: ante un problema o una labor, definimos las acciones a realizar y establecemos de alguna manera la secuencia lógica de esa realización.

En la vida corriente, o también en el ámbito de la dirección de proyectos, la planificación implica también otros aspectos como la asignación de recursos, estimación de presupuestos y el establecimiento de plazos temporales.

En el caso de los agentes inteligentes, prescindimos, al menos habitualmente, de lo que tiene que ver con presupuestación y con el marco temporal.

La planificación, en el mundo de la inteligencia artificial y la robótica, tiene mucho más que ver con la decisión de las tareas a realizar y su secuenciación. En cierto sentido, se trata más de definir una estrategia de actuación para resolver un problema o conseguir un objetivo que de una verdadera planificación y, por tanto, tiene tiene una estrecha relación con la resolución de problemas, el razonamiento y la 'inteligencia'.

Los algoritmos de planificación son esenciales desde hace muchos años en la inteligencia artificial, quizá la inteligencia artificial más clásica y, por ejemplo, ocupa numerosos capítulos del famosísimo libro de texto: 'Artificial Intelligence: a modern approach' de Stuart Russell y Peter Norvig.

En lo que sigue, vamos a revisar una panorámica de los algoritmos o estrategias de planificación orientados hacia los nuevos agentes de la 'Agentic AI' en cuyo núcleo se encuentra un gran modelo de lenguaje (LLM, 'Large Language Model').

Y seguimos principalmente, como en toda esta serie de posts sobre agentes, el contenido del libro 'Building Agentic AI systems' de Anjanava Biswas y Wrick Talukdar. En dicho libro, los autores nos presentan siete algoritmos / estrategias, estructurados conforme a una clasificación un poco paradójica de 'practicidad'. A falta de una mejor clasificación, también los revisaremos aquí de esa forma, por orden creciente de practicidad.

Algunos algoritmos no muy prácticos

En esta no muy lucida categoría de algoritmos poco prácticos, los autores nos presentan bastante brevemente, cuatro algoritmos, en general muy famosos.

• STRIPS ('Stanford Research Institute Problem Solver'): Un algoritmos que se remonta ya a 1971 y que está respaldado por un lenguaje formal del mismo nombre. En STRIPS se trabaja con estados y acciones definidas mediante predicados lógicos. Hay un estado inicial y varios posibles estados objetivo. Además están definidas la serie de acciones con las precondiciones para que se puedan llevar a cabo y las poscondiciones tras su aplicación. En él, una plan es una secuencia de operadores que deben conducir a un estado final. Este algoritmo resulta poco adecuado para trabajar con los LLMs de los modernos agentes, ya que las interacciones en lenguaje natural no se reducen fácilmente a las condiciones cierto/falso que precisa STRIPS.


• A^*: Un algoritmo muy habitual en robótica para definición de caminos en el caso de robots móviles. Se apoya en grafos, existiendo un nodo inicial y un nodo objetivo. Asociado a los diferentes arcos existe un peso (o coste) y el algoritmo se ocupa de encontrar el recorrido en el grafo que representa el menor coste (donde, con frecuencia, el coste es la distancia y, por tanto, lo que hace es calcular el camino más corto). Estos algoritmos necesitan esa estimación clara del coste de una acción y una heurística para estimar el resto del coste en un punto dado (el uso de heurísticas es para hacer más eficiente computacionalmente el algoritmo). Esa estimación de costes, muy numérica, resulta problemática en el caso de interacciones basadas en lenguaje natural.


• GraphPlan: Otro algoritmo basado en grafos donde se representan en capas las acciones y sus efectos en el tiempo. En el caso de uso de modelos basados en lenguaje, no es fácil encajar las interacciones en capas ni establecer relaciones causa-efecto claras.


• MCTS ('Monte Carlo Tree Search'): Un método donde el árbol de planificación se va creando y expandiendo mediante muestreo aleatorio en el espacio de búsqueda y tomando las ramas más prometedoras. No resulta práctico para su uso en agentes basados en LLMs por dos motivos: porque cada simulación requeriría invocaciones al LLM, haciéndolo muy costoso computacionalmente, y porque en el caso de interacciones en modelos de lenguaje el espacio de estados es tan enorme que no resulta eficiente su exploración aleatoria.

Para el lector avezado en inteligencia artificial, algunos o todos los nombres de algoritmos anteriores le resultarán familiares, porque se trata de algoritmos clásicos, con notable éxito en ciertos campos de aplicación o ciertos momentos de la historia de la inteligencia artificial. Sin embargo, para trabajar con los modernos agentes de la 'Agentic AI', cuyo 'núcleo' es un gran modelo de lenguaje, quedan descartados.

Algunos algoritmos moderadamente prácticos

En esta categoría intermedia de algoritmos moderadamente prácticos, los autores nos hablan de un único algoritmo: Fast Forward planning o FF planning.

Se trata de un algoritmo que hereda algunas ideas de otros como STRIPS o GraphPlan. Utiliza una búsqueda heurística en una versión simplificada del problema.

Los autores estiman que su orientación a objetivos pudiera  ser usada en el caso de agentes basados en LLM, aunque requeriría adaptaciones para un manejo efectivo del lenguaje natural.  De todas formas, también presenta dificultades ya que las heurísticas que utiliza son de tipo numérico que, como ya hemos comentado en otros algoritmos, no se adaptan bien al tratamiento mediante lenguaje natural.

Resumiendo bastante, los autores entienden que FF planning se puede utilizar en agentes basados en LLM pero sometiéndolo a una serie de modificaciones.

Los algoritmos más prácticos

Y llega el momento de ver las opciones mejores o más prácticas. En este caso se nos habla de dos opciones: una planificación basada en LLMs y HTN. Veámoslas brevemente

Planificación basada en LLMs

Esta forma de planificación prescinde de estados y acciones formales, costes, grafos y otros elementos habituales en los algoritmos de planificación tradicionales que hemos revisado más arriba. En su lugar, trabajan en lenguaje natural y los estados y acciones se describen en lenguaje natural.

Cuando planificamos con grandes modelos de lenguaje, estamos asumiendo que estos modelos son capaces de entender objetivos complejos, generar los pasos adecuados para conseguirlos y adaptar esos pasos según cambia el entorno o la situación.  

Aunque hace un tiempo esta posibilidad hubiera podido parecer poco creíble, lo cierto es que si se atiende a lo ya conseguido en modelos razonadores, parece un opción muy válida, al menos para ciertas situaciones o tipos de problemas. 

De todas formas hay que tener en cuenta que también tiene sus limitaciones de las que nos advierten los autores: los LLMs no acaban de adaptarse bien a planes en que hay elementos o restricciones numéricas o temporales y tienden a ser demasiado optimistas y poco prácticos si no se establecen las debidas restricciones.

A cambio se desenvuelven bien, o al menos mejor que los tradicionales, en situaciones con incertidumbre, información incompleta o estados nuevos.

HTN ('Hierarchical Task Network')

Es una estrategia de planificación que trabaja mediante la descomposición jerárquica de tareas en subtareas aunque, eso si, a diferencia de algoritmos clásicos como STRIPS que trabaja con unas acciones primitivas muy claramente definidas, HTN trabaja con tareas más abstractas y luego va descomponiendo en otras más concretas.

Se trata de un enfoque flexible, que tiende a reflejar el modo de planificar humano y que escala y se adapta bien a problemas complejos 

La asignación de recursos: las herramientas, de nuevo

Al inicio de este post, al comparar el concepto de planificación del ámbito de la dirección de proyectos con el significado de planificación en inteligencia artificial, decíamos que no se tenía en cuenta ni tiempos ni costes y sólo parcialmente recursos. Estrictamente hablando, no es imposible incluir de alguna forma tiempos y costes en una planificación de inteligencia artificial, pero no es lo más habitual ni definitorio.

¿Y los recursos? Bueno, no suelen usarlos tanto en el sentido, por ejemplo, de las personas, equipos o empresas necesarias para realizar una tarea. Pero sí hay otros recursos que hay que tener en cuenta: las herramientas.

En efecto, hemos visto los mecanismos de planificación que son, en cierto sentido, mecanismos de pensamiento y razonamiento. Pero para que esto resulte útil en la mayoría de los casos, y para que el agente sea realmente un agente, debe poder actuar, cosa que, como explicábamos en el post anterior, lo hacen a través de las denominadas herramientas ('tools') que, de esta forma, se constituyen en los recursos necesarios para realizar una tarea.

Así que los agentes, también deben de ser capaces de conocer y razonar sobre las herramientas que tienen a su disposición, sabiendo de alguna forma lo que pueden y no pueden hacer. Y la propia planificación debe utilizar ese conocimiento sobre las capacidades disponibles para definir las acciones a llevar a cambo.

La planificación en la práctica de desarrollo

¿Y cómo se lleva todo esto a cabo en tiempo de desarrollo? ¿Cómo se construyen este tipo de soluciones?

Bien, en la obra citada, los autores ejemplifican casi todos los aspectos usando el framework CrewAI.

Además, y para aumentar un poco el abanico de posibilidades, también dan como opciones el uso del conocido LangGraph (parte de LangChain) o AutoGen.

O sea, que no sólo disponemos de grandes modelos de lenguaje, también existen ya frameworks que permiten construir el resto de elementos de un agente, incluyendo la planificación.

Conclusiones

Hemos visto cómo una parte nuclear de un agente es la planificación, algo ya tradicional en el campo de la inteligencia artificial pero que es necesario revisar, aportar nuevos algoritmos y estrategias, para realizar una planificación expresada en lenguaje natural y que se crea con el apoyo de un gran modelo de lenguaje. 

Artículos de este blog relacionados

• Hablemos de agentes (VI): herramientas
• 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

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