¿Creando agentes? Dejen de tratar los mensajes como una base de datos.

Pero a medida que la lógica de mi agente se volvía más compleja, empezaron a aparecer grietas. El modelo repetía las llamadas a herramientas que ya había ejecutado. Las plantillas de indicaciones se llenaban de contexto irrelevante. Estaba escribiendo funciones para analizar la transcripción de messages[] solo para extraer el resultado correcto de la llamada a la herramienta al crear indicaciones. Empezó a parecer extraño. Tenía que haber una mejor manera.

El problema de fondo no eran las herramientas en sí, sino mi suposición de que la transcripción era el estado.

LangGraph me brindó una nueva perspectiva. En lugar de tratar la transcripción como un cajón de sastre para todo lo que el agente podría necesitar "recordar", podía modelar el estado estructurado explícitamente: entradas específicas para cada nodo y campos aislados para los resultados de las herramientas, el historial de uso y otros datos reutilizables. Incluso ciertas respuestas del asistente, como el razonamiento interno o las estrategias elegidas, merecen sus propios campos de estado si se van a reutilizar más adelante. Este estado reside en el objeto de hilo LangGraph y persiste durante las ejecuciones, lo que me permite introducir indicaciones más breves y específicas en el modelo, con el contexto exacto que necesita, sin necesidad de arqueología de transcripciones.

Esta publicación explica este cambio y cómo la adopción de un estado estructurado hace que los agentes sean más robustos, fiables y estén listos para su uso real.

La mayoría de las demostraciones convierten la transcripción en una base de datos accidental. En su lugar, convierta los datos pesados ​​en un estado estructurado y mantenga la transcripción ligera:

// Antes graphState = { messages[] //una combinación de indicaciones del usuario, respuestas del asistente, solicitudes de llamadas a la herramienta, resultados de llamadas a la herramienta }

// Después graphState = { messages[], //solo flujo de chat: indicaciones del usuario y respuestas del asistente que vale la pena mostrar al usuario toolResults, userPreferences, …otros datos reutilizables }

La transcripción messages[] se mantiene legible y breve; la verdadera "memoria de trabajo" del agente reside en campos dedicados dentro del estado del grafo, donde está estructurada, es inspeccionable y fácil de reutilizar. El tipo de dato de estos campos dedicados depende totalmente de usted: por ejemplo, una cadena, un booleano, un número o un objeto, lo que mejor se adapte a sus necesidades.

• Menores costos de tokens: las indicaciones simplificadas omiten el historial completo de llamadas a herramientas y chat.
• Inspección y depuración más sencillas: el estado reside en campos con nombre que se pueden registrar y visualizar, en lugar de estar enterrado en un montón de tokens.
• Comportamiento predecible y controlable: el estado explícito hace que las entradas y salidas de cada nodo sean deterministas, de modo que se dirige el LLM con exactamente el contexto que necesita, en lugar de esperar que encuentre la parte correcta en una transcripción enorme.
• Mayor precisión: al recortar mensajes no relacionados y resultados obsoletos de herramientas, se reduce el ruido, de modo que el modelo se centra en la señal.
• Pruebas más sencillas: cada nodo LangGraph puede someterse a pruebas unitarias con una pequeña carga útil de estado explícito, en lugar de reconstruir un registro de mensajes masivo.

El antipatrón

La mayoría de los tutoriales configuran un LLM con la llamada a herramientas habilitada y luego añaden tanto la solicitud de llamada a la herramienta como su resultado JSON directamente al registro messages[]. Ahora imaginemos que un usuario pregunta: "¿Qué tiempo hace este fin de semana?" y sigue chateando.

1. Cada nuevo mensaje de usuario activa la herramienta de búsqueda de nuevo.
2. Cada ejecución añade otra solicitud y otro blob JSON a messages[].
3. Cuando el usuario finalmente dice: "¿Debería llevar un paraguas?", el LLM debe revisar toda la transcripción, decidir cuál de los muchos resultados de búsqueda es el actual y utilizar esos datos correctamente.

Esto implica indicaciones más largas, más tokens y un razonamiento frágil.

Una mejor manera

Eleva los datos al estado:

graphState["searchResults"] = results_json

…luego inyecta solo lo que cada nodo necesita:

Aquí están los resultados de la búsqueda: {{searchResults}}

Ahora, cada mensaje de usuario puede reutilizar o actualizar graphState.searchResults sin sobrecargar la transcripción, y el LLM siempre ve los datos correctos en un mensaje limpio.

LangGraph lo hace posible, pero no lo fuerza. Dar el salto depende de ti. La misma lógica se aplica a las estadísticas reutilizables del asistente: resúmenes, acciones recomendadas, conclusiones analizadas. Almacénalas en el estado, no en la matriz messages[].

• Tratar el estado del hilo de LangGraph como memoria de trabajo: estructurada, inspeccionable y portátil.
• Crear campos claros: resultados de búsqueda, perfil de usuario, datos de precios, resumen de estrategia, etc.
• Si un mensaje del asistente guiará pasos posteriores, incorporarlo al estado en lugar de dejarlo en la transcripción.
• Mantener la sección messages[] limpia: solo el texto del usuario y las respuestas finales del asistente.
• Construir plantillas de indicaciones con solo el estado relevante necesario para respaldar mejor la respuesta del LLM.

Usar messages[] para todo funciona, por un tiempo. Pero a medida que los agentes crecen, este patrón se vuelve frágil, opaco y costoso.

Trate la transcripción como una transcripción, no como un cerebro. El estado estructurado preserva lo que importa (resultados de la herramienta, razonamiento del asistente, decisiones), aportando claridad, determinismo y fiabilidad en el mundo real.