Un chatbot que solo responde con lo que el modelo ya sabe no es un agente. Un agente es el que, cuando le preguntas el clima de hoy en Lima, se da cuenta de que no lo sabe, llama a una API del clima, lee la respuesta y recién ahí te contesta. Ese "darse cuenta y actuar" es el patrón ReAct, y es la base de cómo LangChain construye agentes.
Qué es ReAct en la práctica
ReAct viene de "Reasoning + Acting". En vez de que el modelo genere una respuesta de un solo paso, el agente entra en un ciclo: piensa ("necesito el clima actual"), actúa (llama a la herramienta clima), observa el resultado, y vuelve a pensar con esa información nueva. Repite el ciclo hasta que tiene suficiente para responder.
Esto es justo lo que diferencia un agente de un simple prompt con RAG: el agente decide, en tiempo real, qué herramienta necesita y en qué orden, no sigue un flujo fijo que tú programaste de antemano.
Las piezas que arma LangChain para que esto funcione
- ▸El LLM, que hace de "cerebro" razonando sobre qué hacer en cada paso
- ▸Las Tools: funciones de Python que el agente puede llamar (una API, una consulta SQL, una búsqueda)
- ▸El AgentExecutor, que orquesta el ciclo pensar → actuar → observar hasta llegar a una respuesta final
- ▸La memoria, para que el agente recuerde lo que pasó en turnos anteriores de la conversación
Un ejemplo concreto: agente que consulta inventario
Imagina un agente de soporte que puede responder "¿tienes stock del producto X?". Sin herramientas, el LLM inventaría una respuesta (alucinación). Con una tool conectada a tu base de datos de inventario, el ciclo ReAct sería: piensa "necesito consultar el inventario", actúa llamando a la tool con el nombre del producto, observa el resultado (3 unidades disponibles), y responde con el dato real.
La parte que casi nadie menciona: diseñar bien la descripción de cada tool importa tanto como el código de la función. El LLM decide cuándo usar una herramienta leyendo su descripción — si es vaga ("consulta datos"), el agente la usa mal o no la usa cuando debería. Una descripción específica ("usa esta herramienta para consultar el stock disponible de un producto por su nombre exacto") reduce muchísimo los errores de decisión.
Cuando el agente necesita varias herramientas a la vez
El caso más interesante (y el que más falla si no lo diseñas bien) es cuando el agente tiene acceso a varias tools parecidas: una que busca en una base de datos interna y otra que busca en internet. Si ambas tienen descripciones similares, el agente puede elegir la equivocada o, peor, llamar a las dos innecesariamente y gastar tokens de más. La solución no es técnica, es de diseño: nombrar y describir cada tool de forma que no se puedan confundir entre sí, y limitar cuántas tools le das a un mismo agente (rara vez conviene pasar de 5-6 herramientas activas a la vez).
De pruebas locales a producción
Un agente ReAct que funciona en un notebook y uno que aguanta tráfico real difieren en tres cosas: control de costos (cada ciclo de pensar-actuar consume tokens, así que necesitas un límite de iteraciones), manejo de errores cuando una tool falla, y trazabilidad de cada paso del razonamiento para poder depurar cuando algo sale mal. Herramientas como LangSmith (el observability de LangChain) te dejan ver exactamente qué pensó el agente en cada paso, qué tool llamó y con qué parámetros — sin esto, depurar un agente que falla intermitentemente es casi imposible.
Lo que nadie te dice al empezar con agentes es que el 90% del trabajo no es el prompt del agente — es diseñar bien las herramientas que le das.
Un error de principiante que vale la pena nombrar
El error más repetido que veo en los primeros agentes de un alumno: darle al agente una sola tool genérica que hace de todo (una función que recibe cualquier query SQL, por ejemplo) en vez de varias tools pequeñas y específicas. Suena más simple, pero en la práctica el agente pierde precisión porque tiene que adivinar cómo usar esa tool genérica en cada caso. Agentes con 3-4 tools bien definidas y acotadas superan casi siempre a uno con una sola tool todopoderosa.
Cómo aprenderlo con proyectos reales
El Taller de Creación de Agentes con Langchain de DataPath arranca justo con tu primer agente ReAct y avanza hasta herramientas personalizadas, memoria conversacional y despliegue en producción. Si después quieres controlar flujos más complejos con estados y ciclos, el Taller de Creación de Agentes con LangGraph es el siguiente paso natural.
Para ordenar esto dentro de una carrera completa en agentes de IA, la ruta AI Agentic Engineer conecta LangChain, LangGraph y arquitectura de agentes en producción.
Si quieres resolver dudas de tu propio agente en vivo, cada semana hay un taller práctico en la Comunidad AI Builders.
Entra aquí: builders.datapath.ai
