Un deck que me enviaron hace poco describía un AI agent para administración de bases de datos. Diagramas limpios, loop de llamadas a herramientas, umbral de confianza, escalada humana. Las diapositivas eran buenas. El patrón era ReAct, publicado por Yao et al. en octubre de 2022. El deck simplemente no lo decía.
Esta es la parte del ciclo de hype de IA que me resulta agotadora. Un patrón académico conocido recibe un nombre nuevo, un logo de proveedor, y un caso de uso, y de repente es una innovación. El ejemplo del DBA en esas diapositivas era una ilustración decente. El patrón en sí era más viejo que la mayoría de las empresas que lo venden como la última tecnología.
Qué es realmente ReAct
ReAct significa Reasoning + Acting. Es un loop. El LLM produce un pensamiento sobre qué hacer a continuación, elige una acción de una whitelist de herramientas, la acción se ejecuta, el resultado vuelve como una observación, y esa observación alimenta el siguiente pensamiento. Enjuagar y repetir hasta que el modelo decide que la tarea está hecha.
Thought: I need to check if the orders table is locked.
Action: run_sql("SELECT pid FROM pg_locks WHERE relation = 'orders'::regclass")
Observation: [{"pid": 3421}]
Thought: There is a lock held by pid 3421. I should check what query is running.
Action: run_sql("SELECT query FROM pg_stat_activity WHERE pid = 3421")
Observation: [{"query": "UPDATE orders SET ... WHERE created_at < ..."}]
Thought: Long-running update. I should escalate before killing it.
Action: notify_slack("DBA: long UPDATE on orders, pid 3421, need decision")
Observation: Message delivered to #oncall
Thought: Done. Writeback the incident.Eso es. El patrón completo. Todo lo demás en las diapositivas, los triggers, la whitelist de herramientas, la escape hatch basada en confianza, es andamiaje alrededor de ese loop. Andamiaje importante, pero andamiaje.
Por qué funciona el reempaque
La razón por la que ReAct se sigue redescubriendo es que el paper original era académico. Ejemplos de prompts, algunas tareas de benchmark, cero historias de guerra en producción. Los proveedores y consultores toman ese núcleo académico, lo envuelven en un dominio (DBA, security ops, atención al cliente, IT interno), agregan su caja de herramientas, y lo entregan como producto.
No estoy en contra de eso. Convertir un paper en un producto usable es trabajo real. El problema es cuando el wrapper de dominio se vende como la innovación, y terminas pagando por un loop ReAct envuelto alrededor de una whitelist de herramientas que tu equipo podría haber construido en una semana.
Lo que las presentaciones de agent de nivel básico suelen omitir
Si estás viendo un pitch o una charla sobre agents y cubren solo el loop, las herramientas y la escape hatch, aquí es donde los presiono. Estas son las partes que separan una demo que funciona de un agent que sobrevive en producción.
La memoria suele faltar
El loop tiene un scratchpad. Ese scratchpad es la memoria de corto plazo de la sesión. Bien. ¿Pero qué pasa mañana cuando llega un incidente similar? Si el agent no lee ni escribe en un store persistente, es reactivo, no aprende. La mayoría de los decks introductorios se saltan esto por completo. Tengo un post aparte sobre arquitectura de memoria porque no es una sola cosa, son cinco capas.
El contexto crece en cada iteración
Cada pensamiento, acción y observación regresa al prompt de la siguiente iteración. Diez loops después estás pagando por un prompt con diez pensamientos, diez llamadas a herramientas y diez observaciones. Veinte loops después, chocas con el techo de tu ventana de contexto o de tu presupuesto. Los decks nunca muestran el costo en tokens por ejecución. Pídelo.
La evaluación se pasa por alto
Los sistemas no deterministas necesitan arneses de evaluación. ¿Cómo sabes que un cambio en el system prompt no hizo una regresión de comportamiento sobre un conjunto de incidentes conocidos? Si el pitch no tiene un replay de golden-set o una forma de comparar decisiones entre versiones, es un prototipo vestido de producto.
Cómo evaluar un pitch de agent sin ser esa persona
No estoy sugiriendo que entres a cada reunión de proveedor gritando sobre el paper de Yao. El patrón es útil, la productización tiene valor real, y los desarrolladores gruñones que dicen "esto es solo ReAct" son la razón por la que dejan de invitarnos a las reuniones. Pero hay cuatro preguntas que exponen si el equipo que te está vendiendo el agent sabe lo que está haciendo.
- ¿Qué le pasa al contexto en el loop 20? Si no tienen una estrategia de resumen o truncamiento, el agent muere o quema dinero en sesiones largas.
- ¿Dónde vive la memoria? Solo por sesión está bien para agents simples. Para cualquier cosa operativa, quiero ver un store de largo plazo y una ruta de sincronización hacia él.
- ¿Cómo previenen una acción confiadamente errónea? Whitelist más dry-run más umbral de confianza es un mínimo. Sin eso, el agent hará algo que no podrás deshacer.
- ¿Cómo evalúan los cambios? Un cambio en el system prompt es un cambio de comportamiento. Sin un arnés de regresión estás entregando por intuición.
El patrón es de 2022. El hype es del martes pasado. Evalúa la implementación, no el folleto.
Lo que esto realmente significa para ti
Si estás evaluando un producto de agent, ahora conoces la baseline. Si estás construyendo uno, ahora sabes dónde están los problemas interesantes. El loop no es la parte difícil. Las partes difíciles son memoria, evaluación, control de costo y recuperación de malas decisiones. Cualquiera que te diga lo contrario te está vendiendo el andamiaje y llamándolo la casa.
Referencias
- ReAct: Synergizing Reasoning and Acting in Language Models, Yao et al., 2022: https://arxiv.org/abs/2210.03629
- Prompt Engineering Guide, sección ReAct: https://www.promptingguide.ai/techniques/react
- Conceptos de agent de LangGraph: https://langchain-ai.github.io/langgraph/concepts/agentic_concepts/