Internet ha decidido que este es el año del agente. LangGraph, CrewAI y AutoGen son los nombres en cada hoja de ruta de ingeniería. Los equipos están realizando pruebas de estrés a las capas de orquestación, debatiendo entre máquinas de estado o role-play, y preguntándose qué librería hará finalmente que los modelos de lenguaje de gran tamaño sean autónomos.

Esta es la incómoda verdad: la mayoría de esas comparaciones son prematuras. Los frameworks no son la parte difícil. La parte difícil es que hemos dejado de definir nuestros términos. Ahora la gente llama "agente" a todo. Una llamada a una herramienta no es un agente. Un chatbot no es un agente. Esa definición descuidada conduce directamente a una mala ingeniería, sistemas sobredimensionados y caídas en producción que podrían haberse evitado con un simple script.

Antes de elegir un framework, define lo que realmente estás construyendo.

Lo que un agente es realmente

Un agente no se define por el modelo en el que se ejecuta ni por el número de llamadas a la API que realiza. Un agente se define por su comportamiento. Debe tener un objetivo claro. Debe decidir qué paso sigue sin que un humano trace el camino de antemano. Debe gestionar el fallo cuando ese paso se rompe. Y debe saber cuándo detenerse.

Piensa en un sistema de soporte que lee un correo electrónico entrante, lo clasifica como una solicitud de reembolso, extrae el número de pedido, consulta la base de datos de envíos, verifica el plazo de la política de devoluciones, redacta una respuesta y marca el ticket como resuelto. Si la base de datos agota el tiempo de espera, espera e intenta de nuevo. Si el plazo de la política es ambiguo, solicita la intervención de un humano. Cuando se envía la respuesta, se detiene. Eso es un agente. Un wrapper alrededor de una única llamada a un LLM que devuelve un JSON no lo es, sin importar cuántas pegatinas de "agente" les ponga el equipo de marketing.

Esta distinción es importante porque la complejidad tiene un costo. Un sistema que no necesita autonomía no debería pagar el precio por ella.

La verdadera forma de la IA en producción

La mayoría de los sistemas de IA que funcionan en producción actualmente son especializados. Hacen una sola cosa bien. Clasifican tickets de soporte en colas. Extraen fechas de caducidad de documentos escaneados. Emparejan las consultas de los clientes con artículos existentes en la base de conocimientos. No son motores de razonamiento general, y pretender que lo son conduce al peor tipo de sobreingeniería.

También conduce a una obsesión destructiva con los lanzamientos de modelos. Los equipos persiguen el modelo fundacional más nuevo como si fuera a compensar una arquitectura descuidada. No lo hará. Un modelo más capaz que se ejecute dentro de un bucle frágil sin gestión de errores simplemente fallará con mayor confianza y alucinaciones más creativas. Deja de perseguir benchmarks. Empieza a perseguir la estructura.

El framework no es el producto

LangGraph te ofrece máquinas de estado y ciclos explícitos. CrewAI se inclina hacia la orquestación basada en roles donde los agentes adoptan personalidades. AutoGen se centra en agentes conversacionales que charlan entre sí para resolver problemas. Todos son herramientas capaces. También son enfoques fundamentalmente diferentes para el flujo de control.

Pero el framework que elijas importa menos que los patrones que impongas dentro de él. He visto equipos lanzar automatizaciones sólidas usando nada más que Python y Redis porque respetaron los límites. He visto a otros equipos colapsar bajo el peso de una orquestación sofisticada porque trataron al framework como un sustituto del diseño.

Si tus transferencias son vagas, tus herramientas son frágiles y tu lógica de reintento es inexistente, el logo en tu requirements.txt no te salvará.

Tres cosas que realmente merecen tu tiempo

Si estás construyendo sistemas agénticos, vuelca tu esfuerzo en estas tres áreas.

Diseño de herramientas. Cada función que tu agente puede llamar es un riesgo envuelto en una interfaz. Diséñalas de forma estricta. Valida las entradas de manera agresiva. Devuelve errores que sean realmente legibles, no volcados de error 500. Una buena herramienta es aquella sobre la que el agente puede razonar cuando algo sale mal.

Gestión de fallos. Asume que cada LLM