En los artículos anteriores hemos ido construyendo las diferentes piezas que forman un agente de inteligencia artificial. Comenzamos diferenciando un agente de un chatbot y posteriormente analizamos cómo puede razonar, planificar y utilizar herramientas para realizar tareas.
Después vimos cómo funcionan la memoria, las APIs, la búsqueda en internet, la ejecución de código con Python, las bases de datos y el procesamiento de documentos. También analizamos los agentes multimodales y las bases de datos vectoriales como una forma de proporcionar memoria persistente.
Todas estas capacidades son importantes, pero todavía queda una pregunta fundamental: ¿cómo decide un agente qué hacer cuando necesita utilizar varias herramientas para resolver un problema?
Una posible respuesta es el patrón ReAct, un enfoque que combina razonamiento y acciones dentro de un ciclo. El agente analiza el problema, decide qué herramienta necesita, ejecuta una acción, observa el resultado y vuelve a analizar la situación.
Este patrón es especialmente importante porque nos ayuda a comprender cómo un agente puede pasar de simplemente generar texto a realizar procesos en los que debe pensar, actuar, observar y volver a decidir.
1. ¿Qué es ReAct?
ReAct viene de Reasoning and Acting, que significa razonamiento y acción.
La idea principal es combinar dos capacidades que normalmente consideramos por separado.
Por un lado, tenemos el razonamiento. El agente necesita analizar la situación y determinar qué debería hacer.
Por otro lado, tenemos las acciones. El agente necesita utilizar herramientas para obtener información o modificar algo en el mundo exterior.
En lugar de intentar resolver todo el problema de una sola vez, el agente puede trabajar mediante ciclos.
Un flujo simplificado sería:
Pregunta → razonamiento → acción → observación → nuevo razonamiento → nueva acción → resultado
Este proceso puede repetirse varias veces hasta que el agente considera que tiene suficiente información para responder o completar la tarea.
2. ¿Por qué necesitamos este patrón?
Imaginemos que un usuario pregunta:
"¿Cuál es la temperatura actual de la máquina 3 y está dentro del rango permitido?"
El agente no puede responder correctamente si no tiene acceso a la temperatura actual.
Necesita utilizar una herramienta.
Primero debe entender que necesita consultar el sensor.
Después realiza la consulta.
Supongamos que obtiene:
"Temperatura: 78 °C."
Ahora necesita interpretar ese resultado.
Si el rango permitido es de 0 a 80 °C, puede concluir que la temperatura está dentro del límite.
Pero imaginemos que obtiene:
"Temperatura: 95 °C."
Ahora el agente debe tomar una decisión diferente.
Podría informar al usuario de que existe una condición anormal.
Este ejemplo muestra por qué es útil separar el proceso en pasos.
El agente no sabe necesariamente toda la información desde el principio. Actúa para obtener información y después utiliza esa nueva información para decidir qué hacer.
3. El ciclo básico de ReAct
Podemos dividir el proceso en cuatro elementos principales:
Razonamiento
El agente analiza qué necesita hacer.
Acción
Utiliza una herramienta disponible.
Observación
Recibe el resultado de la herramienta.
Nuevo razonamiento
Utiliza el resultado para decidir cuál será el siguiente paso.
Este ciclo puede repetirse.
Por ejemplo:
Usuario:
"¿Cuál es el estado de mi servidor?"
El agente razona que necesita consultar el servidor.
Acción:
Ejecuta una herramienta de monitoreo.
Observación:
"CPU: 92 %, memoria: 85 %."
Nuevo razonamiento:
La carga es elevada, por lo que necesita revisar qué proceso está consumiendo recursos.
Nueva acción:
Consulta los procesos.
Nueva observación:
"Proceso X utiliza 80 % de CPU."
Finalmente, el agente puede presentar una conclusión.
Esta interacción entre pensamiento, herramientas y observaciones es la esencia del patrón.
4. Razonamiento antes de actuar
Uno de los puntos importantes es que el agente no debería utilizar herramientas sin una razón.
Si tiene acceso a una calculadora, una API, una base de datos y un buscador web, necesita decidir cuál es apropiada para cada problema.
Supongamos que el usuario pregunta:
"¿Cuánto es 248 × 37?"
No tiene sentido realizar una búsqueda en internet.
La herramienta adecuada sería una calculadora o Python.
Si pregunta:
"¿Cuál es el precio actual de este componente?"
una búsqueda web o una API podría ser más apropiada.
El agente debe relacionar la intención del usuario con la herramienta disponible.
Esto es precisamente parte del razonamiento.
5. La acción
Después de decidir qué necesita, el agente ejecuta una acción.
La acción puede ser muy sencilla o bastante compleja.
Puede consistir en:
- realizar una búsqueda;
- consultar una base de datos;
- llamar a una API;
- ejecutar código;
- leer un documento;
- consultar un sensor;
- enviar una notificación.
Lo importante es que la acción produce información o un cambio que el agente puede utilizar posteriormente.
Por ejemplo:
Razonamiento: necesito conocer el inventario.
Acción: consultar la base de datos.
Resultado: quedan 12 unidades.
A partir de ahí, el agente puede continuar.
6. La observación
Después de ejecutar una herramienta, el agente recibe un resultado.
Ese resultado se convierte en una observación.
Por ejemplo:
"El servidor respondió con código 200."
"El sensor registra 72 °C."
"El producto tiene 15 unidades disponibles."
"El documento indica que la alimentación requerida es de 24 V."
La observación es importante porque proporciona nueva información.
El agente no debería ignorarla.
Tiene que utilizarla para determinar cuál es el siguiente paso.
7. Un ejemplo sencillo con búsqueda web
Imaginemos que un usuario pregunta:
"¿Cuál es la versión más reciente de una biblioteca de Python?"
El agente necesita información actualizada.
Primero identifica que su conocimiento interno podría no ser suficiente.
Decide utilizar una herramienta de búsqueda.
Realiza una consulta.
Obtiene diferentes resultados.
Después analiza las fuentes.
Si encuentra una página oficial que indica una versión determinada, puede utilizar esa información.
Pero todavía podría existir una situación en la que los resultados sean contradictorios.
En ese caso, el agente puede realizar otra búsqueda.
Aquí aparece nuevamente el ciclo:
razonamiento → búsqueda → observación → razonamiento → nueva búsqueda → observación → respuesta
No es una única acción.
Es un proceso.
8. ReAct con una base de datos
Ahora imaginemos un agente conectado a una base de datos.
El usuario pregunta:
"¿Qué productos tuvieron más ventas este mes?"
El agente necesita consultar los datos.
Su proceso podría comenzar así:
Razonamiento: necesito consultar las ventas correspondientes al mes actual.
Acción: ejecutar una consulta en la base de datos.
Observación: la base devuelve los productos y sus cantidades.
Razonamiento: necesito ordenar los resultados para encontrar los productos con mayor número de ventas.
Acción: procesar los resultados.
Observación: los tres productos principales son A, B y C.
Resultado: presentar la información al usuario.
El agente utiliza los resultados de una acción para determinar la siguiente.
9. ReAct y Python
También podemos utilizar este patrón con ejecución de código.
Supongamos que un usuario proporciona un archivo con datos de sensores y pregunta:
"¿Cuál fue la temperatura promedio y cuál fue el momento de mayor temperatura?"
El agente puede determinar que necesita procesar los datos.
Utiliza Python.
El código calcula los valores.
Después recibe los resultados.
Si el usuario también pregunta:
"¿Hubo algún momento en que la temperatura superara los 80 °C?"
el agente puede realizar otro análisis.
De esta manera, Python se convierte en una herramienta dentro del ciclo de razonamiento.
Esto es mucho más flexible que pedirle al modelo que intente hacer todos los cálculos directamente.
10. ReAct no significa que el agente tenga que actuar siempre
Es importante aclarar algo.
Un agente puede decidir que no necesita ninguna herramienta.
Si el usuario pregunta:
"¿Qué es un microcontrolador?"
probablemente pueda responder directamente.
No tendría sentido consultar una API o una base de datos si la información necesaria ya está disponible.
Por eso, una parte importante del razonamiento consiste precisamente en decidir si una acción es necesaria.
Un agente eficiente utiliza herramientas cuando aportan valor.
11. ReAct y manejo de errores
Una de las ventajas de este patrón es que permite reaccionar ante errores.
Imaginemos que el agente intenta consultar una API.
La API responde:
"Error 500."
El agente recibe esta observación.
Puede entonces decidir:
- intentar nuevamente;
- utilizar otra herramienta;
- modificar los parámetros;
- informar al usuario;
- detener el proceso.
Por ejemplo:
Razonamiento: la API no respondió correctamente.
Acción: realizar un segundo intento.
Observación: la API continúa fallando.
Razonamiento: no tiene sentido continuar intentando indefinidamente.
Resultado: informar al usuario de que el servicio no está disponible.
Esto evita que el agente quede atrapado en un proceso infinito.
12. Evitar ciclos infinitos
Cuando un agente puede tomar decisiones y utilizar herramientas, existe el riesgo de que continúe actuando indefinidamente.
Por ejemplo:
"Intentar búsqueda."
"Resultado insuficiente."
"Intentar otra búsqueda."
"Resultado insuficiente."
"Intentar otra búsqueda."
Y así sucesivamente.
Por eso, los sistemas deben establecer límites.
Puede existir un número máximo de acciones.
Por ejemplo:
"El agente puede realizar como máximo cinco llamadas a herramientas para resolver una tarea."
También pueden existir límites de tiempo o de costo.
Esto permite mantener controlado el comportamiento.
13. ReAct y la selección de herramientas
Cuando un agente tiene muchas herramientas disponibles, la selección se vuelve importante.
Imaginemos que tiene acceso a:
búsqueda web,
base de datos,
Python,
calculadora,
API de inventario,
sistema de correo,
sistema de mantenimiento.
Si el usuario pregunta:
"¿Cuántas unidades quedan?"
probablemente necesite la API de inventario.
Si pregunta:
"¿Cuál fue el promedio de temperatura?"
podría utilizar Python o una base de datos.
Si pregunta:
"¿Cuál es la información más reciente sobre este componente?"
puede utilizar búsqueda web.
La calidad del agente depende en parte de que las herramientas estén claramente descritas.
14. Una herramienta debe tener un propósito claro
Una mala práctica sería proporcionar una herramienta gigantesca que pueda hacer absolutamente cualquier cosa.
Por ejemplo:
hacer_cualquier_cosa()
Este tipo de herramienta sería difícil de controlar.
Es mejor crear herramientas con responsabilidades claras.
Por ejemplo:
consultar_inventario()
obtener_temperatura()
buscar_documento()
crear_reporte()
enviar_notificacion()
De esta manera, el agente tiene opciones más claras.
Además, resulta más sencillo establecer permisos y validar cada operación.
15. ReAct aplicado a un sistema IoT
Imaginemos ahora un sistema de monitoreo industrial.
Tenemos sensores de temperatura y presión.
El usuario pregunta:
"¿Existe algún problema con la máquina 2?"
El agente no puede responder solamente utilizando conocimiento general.
Necesita consultar datos.
Primero consulta los sensores.
Obtiene:
Temperatura: 92 °C.
Presión: 7.8 bar.
Después consulta los límites establecidos.
Encuentra:
Temperatura máxima: 80 °C.
Presión máxima: 8 bar.
Ahora tiene suficiente información para detectar que la temperatura está fuera del rango.
Podría entonces consultar el historial.
Encuentra que la temperatura comenzó a aumentar hace aproximadamente 30 minutos.
Finalmente puede generar una alerta.
Este proceso puede representarse conceptualmente como:
Pregunta → consultar sensores → analizar datos → consultar límites → revisar historial → generar conclusión
Eso es un flujo ReAct.
16. ReAct y memoria
En artículos anteriores vimos cómo los agentes pueden utilizar memoria persistente.
ReAct puede trabajar junto con esa memoria.
Imaginemos que un agente recibe una nueva alerta.
Puede consultar primero si existe un incidente similar en el historial.
Si encuentra uno, puede utilizar esa información para decidir qué hacer.
Por ejemplo:
Observación actual: temperatura elevada.
Memoria: una situación similar ocurrió anteriormente después de una falla en el sistema de refrigeración.
Nuevo razonamiento: revisar información relacionada con refrigeración.
Esto demuestra que la memoria puede convertirse en otra herramienta dentro del proceso de razonamiento.
17. ReAct y documentos
También podemos utilizar documentos como fuente de información.
Supongamos que un técnico pregunta:
"¿Qué procedimiento debo seguir para este código de error?"
El agente puede:
Primero identificar el código.
Después buscarlo en los manuales.
Encontrar la sección correspondiente.
Leer las instrucciones.
Finalmente proporcionar el procedimiento.
Si el documento indica que debe comprobarse un sensor, el agente podría utilizar otra herramienta para consultar el sensor.
Así tenemos:
Documento → instrucción → herramienta → resultado → nuevo razonamiento
El agente conecta diferentes fuentes de información.
18. Un ejemplo de varias herramientas
Imaginemos un agente de soporte técnico que dispone de cuatro herramientas:
Base de datos: historial de equipos.
Documentos: manuales.
API: información actual del dispositivo.
Python: análisis de datos.
Un usuario pregunta:
"¿Por qué el equipo X está consumiendo más energía que la semana pasada?"
El agente podría comenzar consultando los datos actuales.
Después puede recuperar el historial.
Puede utilizar Python para comparar los valores.
Finalmente puede consultar el manual para determinar si el comportamiento está fuera de los parámetros normales.
El resultado podría ser:
"El consumo promedio aumentó aproximadamente un 18 % respecto a la semana anterior. El incremento comenzó después del cambio registrado el martes. El manual indica que este comportamiento puede estar relacionado con una condición de operación específica."
El agente no necesitó utilizar todas las herramientas necesariamente.
Utilizó las que consideró relevantes.
19. Razonamiento, herramientas y resultados
Una forma útil de entender ReAct es imaginar que el agente tiene tres tipos de información:
Lo que sabe.
Información proporcionada por el usuario o disponible mediante el contexto.
Lo que puede hacer.
Las herramientas a las que tiene acceso.
Lo que acaba de descubrir.
Los resultados obtenidos después de utilizar esas herramientas.
El agente combina estas tres fuentes para decidir qué hacer después.
Esta es una de las razones por las que los agentes pueden resolver tareas que serían difíciles de completar con una única respuesta generada de una vez.
20. ¿ReAct es lo mismo que pensar paso a paso?
No exactamente.
Aunque ambos conceptos están relacionados con el razonamiento, ReAct introduce explícitamente la interacción con herramientas y observaciones.
No se trata únicamente de pensar sobre un problema.
El agente también actúa sobre el entorno y utiliza los resultados de esas acciones.
Por ejemplo:
"Necesito conocer la temperatura."
No es suficiente pensar en la temperatura.
Debe consultar el sensor.
Después:
"El sensor indica 90 °C."
Ahora tiene nueva información.
Puede tomar una decisión basada en ese dato.
Esta interacción es una parte fundamental del patrón.
21. ReAct y autonomía
El patrón también ayuda a entender cómo aumenta la autonomía de un agente.
Un sistema poco autónomo puede requerir que el usuario indique cada paso.
Por ejemplo:
"Consulta el sensor."
"Ahora revisa el manual."
"Ahora compara los resultados."
Un agente más autónomo puede decidir esos pasos por sí mismo.
El usuario solamente proporciona el objetivo:
"Investiga por qué la temperatura aumentó."
El agente determina qué herramientas necesita y en qué orden utilizarlas.
Sin embargo, mayor autonomía también significa mayor necesidad de controles.
22. Controlar las acciones del agente
Un agente no debería tener acceso ilimitado solamente porque utiliza ReAct.
Las herramientas deben tener permisos definidos.
Por ejemplo, podemos permitir:
leer sensores;
consultar documentos;
leer bases de datos.
Pero bloquear inicialmente:
modificar configuraciones;
eliminar registros;
apagar equipos;
realizar compras;
enviar mensajes externos.
Las acciones de mayor impacto deben requerir controles adicionales.
Esto permite aprovechar la autonomía sin perder supervisión.
23. Registro de las acciones
En aplicaciones reales es importante saber qué hizo el agente.
Podemos registrar:
qué pregunta recibió;
qué herramientas utilizó;
qué parámetros envió;
qué resultados recibió;
qué decisiones tomó;
cuánto tiempo tardó.
Estos registros permiten analizar errores.
También facilitan la depuración.
Si el agente genera una respuesta incorrecta, podemos revisar el proceso y descubrir en qué punto ocurrió el problema.
Por eso, un sistema de agentes bien diseñado no debería ser una caja negra imposible de analizar.
24. ReAct y los costos
Cada acción puede tener un costo.
Una consulta a una API puede consumir recursos.
Una búsqueda web puede requerir tiempo.
Una llamada a un modelo puede tener un costo.
Una ejecución de código puede utilizar recursos computacionales.
Por eso, un agente debe evitar realizar acciones innecesarias.
Si puede resolver una pregunta con una sola consulta, no tiene sentido realizar diez.
La eficiencia es una parte importante del diseño de agentes.
25. ¿Cuándo utilizar ReAct?
ReAct resulta especialmente útil cuando una tarea requiere interacción con herramientas y los siguientes pasos dependen de los resultados obtenidos.
Por ejemplo:
investigación;
diagnóstico;
análisis de datos;
soporte técnico;
automatización;
monitoreo;
consulta de información;
resolución de problemas.
En cambio, para tareas muy simples puede ser innecesario.
Si solamente necesitamos responder una pregunta directa, un modelo tradicional puede ser suficiente.
La complejidad debe justificarse por la tarea.
26. ReAct no reemplaza las reglas de programación
Un error común sería pensar que podemos entregar todas las decisiones a la IA.
En sistemas importantes, las reglas tradicionales siguen siendo muy útiles.
Por ejemplo:
"Si la temperatura supera 100 °C, generar una alerta."
Esta regla puede implementarse directamente en el software.
No es necesario pedirle a un modelo que interprete una condición numérica tan sencilla.
La IA puede utilizarse para tareas donde aporta flexibilidad.
Las reglas pueden encargarse de las restricciones críticas.
Una arquitectura híbrida puede ser mucho más segura y predecible.
27. Un agente ReAct completo
Podemos imaginar un agente para una empresa que tiene:
memoria,
base de datos,
documentos,
búsqueda web,
APIs,
Python,
herramientas de notificación.
El usuario proporciona un objetivo:
"Investiga este problema y dime qué debería revisar."
El agente puede:
- Consultar el historial.
- Recuperar documentos relevantes.
- Consultar los datos actuales.
- Analizar los datos con Python.
- Buscar información adicional si es necesario.
- Comparar los resultados.
- Generar una conclusión.
- Solicitar autorización antes de realizar una acción importante.
Este tipo de arquitectura representa una evolución importante respecto a un chatbot.
El sistema ya no solamente genera respuestas.
Interactúa con diferentes fuentes de información y utiliza los resultados para decidir qué hacer.
Conclusiones
El patrón ReAct permite comprender una de las ideas fundamentales detrás de los agentes modernos: la combinación de razonamiento y acción. En lugar de intentar resolver una tarea completamente de una sola vez, el agente puede analizar una situación, utilizar una herramienta, observar el resultado y volver a decidir qué hacer.
Este enfoque resulta especialmente útil cuando las tareas requieren varias herramientas o cuando el siguiente paso depende de información que todavía no se conoce. Puede utilizarse con búsquedas web, APIs, bases de datos, documentos, Python, sensores y sistemas de automatización.
Sin embargo, ReAct también requiere controles. Es necesario establecer límites, permisos, manejo de errores y registros para evitar acciones innecesarias o peligrosas. La autonomía debe diseñarse de acuerdo con el riesgo de cada tarea.
Ahora que conocemos cómo un agente puede razonar y actuar utilizando diferentes herramientas, podemos llevar esta idea mucho más lejos. En el siguiente artículo veremos qué ocurre cuando varios agentes de IA trabajan juntos, cada uno con diferentes funciones y responsabilidades.