Agentes de IA: Más allá del chat hacia la acción autónoma

He pasado suficiente tiempo con LLMs basados en chat como para saber dónde chocan con la pared. Escribes una pregunta, el modelo responde y luego olvida que existes. Eso funciona para tickets de soporte y demos de juguete. No funciona cuando necesitas que se haga algo.

Un agente es algo distinto. Le das un objetivo y él idea un plan, elige una herramienta, ejecuta una acción, observa el resultado y vuelve a empezar hasta que el trabajo termina o se rinde. El chatbot te dice cómo corregir el error. El agente abre el archivo, edita el código, ejecuta los tests y envía el pull request. Eso no es un eslogan de marketing. Es una arquitectura de software diferente.

Qué hace que algo sea realmente un agente

No existe una definición académica limpia, pero después de construir varios de estos, siempre vuelvo a las mismas cuatro piezas:

1. Un modelo fundacional que realiza el razonamiento. Casi siempre un LLM.
2. Uso de herramientas (tool use): la capacidad de llamar a funciones reales: APIs, intérpretes de código, navegadores, bases de datos, el sistema de archivos.
3. Memoria. Contexto a corto plazo para la tarea actual y almacenamiento a largo plazo que sobrevive entre sesiones.
4. Un bucle de planificación (planning loop) que decide el siguiente movimiento basándose en el objetivo, el estado actual y lo que acaba de suceder.

Si quitas cualquiera de estas piezas, deja de ser un agente. Un chatbot sin herramientas es un chatbot. Un LLM que llama a funciones pero nunca planifica es un asistente de function-calling, lo cual está bien, pero no es autónomo. Quita la memoria y el agente ni siquiera podrá aprender de un error que cometió hace diez minutos, mucho menos la semana pasada.

El bucle de planificación y ReAct

El framework que dio forma a la mayor parte de esto es ReAct (Reasoning + Acting), de Yao et al. en 2022. La idea es casi vergonzosamente simple: entrelazar el razonamiento de cadena de pensamiento (chain-of-thought) con llamadas a herramientas.

Thought: El usuario quiere que encuentre el último informe de ventas. Debo buscar en el sistema de archivos.
Action: search_files(query="sales report Q3 2025")
Observation: Found 2 results: /reports/q3-sales-final.pdf, /drafts/q3-sales-v2.docx
Thought: La versión final es probablemente la correcta. Permíteme abrirla.
Action: read_file(path="/reports/q3-sales-final.pdf")
Observation: [Contenido del PDF con cifras de ingresos...]
Thought: Tengo los datos. Ahora puedo resumirlos para el usuario.
Action: respond("Los ingresos del Q3 fueron de $4.2M, un 12% más que en el Q2...")

Cada ciclo de Pensamiento-Acción-Observación le da al modelo la oportunidad de pensar antes de tocar nada. Eso importa porque las llamadas a herramientas tienen efectos secundarios. Afectan a sistemas reales. Un modelo que llama a delete_file sin pensar primero no es un agente. Es una responsabilidad civil esperando un postmortem.

Para ver un bucle real, aquí hay ejecuciones registradas de un agente de clips de películas (busca en la web, busca en YouTube, localiza una marca de tiempo, construye una URL del clip y finaliza). Diferentes consultas toman diferentes caminos, y la última ejecución muestra la otra mitad de ser "autónomo": saber cuándo una solicitud está fuera de alcance y detenerse en el primer paso en lugar de dar vueltas sin sentido:

Ejecuciones reales de agentes capturadas, reproducidas con su tiempo, razonamiento, llamadas a herramientas y resultados. Las consultas de películas encadenan cuatro herramientas; la solicitud fuera de alcance (una canción) recibe una negativa cortés en un solo paso. Un agente que solo entra en bucles infinitos está tan roto como uno que nunca lo hace: saber cuándo detenerse es parte del trabajo.

Aparte de ReAct, vale la pena conocer otras estrategias de planificación. Plan-and-Execute genera un plan completo por adelantado y vuelve a planificar si un paso falla. Tree of Thoughts for Agents explora múltiples secuencias de acciones candidatas y elige la más prometedora. Reflexion hace que el agente critique su propia trayectoria después de una tarea y guarde la lección para la próxima vez. Ninguna es una solución mágica. Todas fallan de maneras interesantes una vez que las pones en producción.

Uso de herramientas en la práctica

Las herramientas son las que le dan alcance a un agente. Sin ellas, el LLM solo puede producir texto. Con ellas, puede consultar una base de datos, ejecutar un script de Python, navegar por la web, enviar un correo electrónico, desplegar código o hablar con cualquier sistema que exponga una API.

La mecánica depende del proveedor, pero la estructura es siempre la misma. El modelo recibe una lista de herramientas disponibles con sus esquemas (schemas):

Cuando el modelo decide llamar a una herramienta, emite una llamada estructurada en lugar de texto plano. El runtime intercepta eso, ejecuta la función y devuelve el resultado como un nuevo mensaje. El modelo continúa razonando con la observación en contexto.

La consecuencia práctica es que un agente es tan capaz como su conjunto de herramientas. Dale a un agente de programación una shell, un sistema de archivos y un test runner, y podrá iterar en el código de la misma manera que lo hace un desarrollador. Dale a un agente de investigación búsqueda web, un parseador de PDF y un gestor de citas, y podrá escribir una revisión bibliográfica. Las herramientas definen el espacio de acción. Elígelas descuidadamente y pasarás las próximas tres semanas depurando por qué el agente sigue intentando usar grep para salir de un callejón sin salida.

Memoria: a corto y largo plazo

La memoria in-context es la forma más simple: toda la conversación va en el prompt. Está bien para sesiones únicas, pero la ventana de contexto es finita y el costo escala linealmente con los tokens. Pruébalo en una tarea de larga duración y verás cómo crece tu factura.

La memoria a largo plazo necesita almacenamiento externo. Los enfoques comunes son:

Vector stores: almacenan interacciones pasadas y recuperan las relevantes mediante búsqueda semántica. Esto le da al agente una forma de memoria episódica; puede recordar de qué hablaron el martes pasado.

Logs estructurados: mantienen las llamadas a herramientas y sus resultados en una base de datos. El agente puede consultar su propio historial para evitar repetir errores. Aquí es donde suelo empezar, porque es solo SQL y confío en SQL.

Resúmenes clave-valor (Key-value summaries): comprimen periódicamente la conversación en un resumen y lo almacenan. En la siguiente sesión, se carga el resumen para restaurar el contexto.

Los agentes que resisten en producción combinan los tres. Recuerdan de qué hablaste la semana pasada, qué acciones tuvieron éxito o fallaron y los hechos clave sobre tu proyecto.

Sistemas de agentes en el mundo real

El salto de la demo de investigación a la producción ocurrió más rápido de lo que esperaba. Algunas categorías donde esto ya está dando frutos:

Agentes de codificación como Claude Code, Cursor Agent y Devin pueden tomar un issue de GitHub, leer el código base, escribir una corrección, ejecutar pruebas y abrir un pull request. No son perfectos. Aún necesitas revisar el diff. Pero para tareas bien delimitadas, comprimen horas en minutos.

Agentes de investigación como Elicit y Consensus buscan en bases de datos académicas, extraen hallazgos y señalan contradicciones. Una revisión bibliográfica que solía tomar una semana ahora toma una tarde.

Agentes de "computer-use" controlan un navegador o una GUI de escritorio como lo haría un humano: haciendo clic, completando formularios, navegando por páginas. El computer-use de Anthropic y Operator de OpenAI demostraron que los agentes pueden interactuar con software que nunca fue diseñado para acceso programático. Esta es tecnología incipiente hoy, pero la trayectoria es obvia.

Agentes de análisis de datos se conectan a una base de datos, escriben y ejecutan SQL o Python, generan gráficos e iteran en el análisis basándose en preguntas de seguimiento. Se comportan como un analista junior que no duerme y no se aburre. También ocasionalmente alucinan columnas, por lo que nunca dejo que uno se acerque a una base de datos de producción sin una read replica.

Los problemas difíciles

Los agentes son impresionantes en las demos y genuinamente útiles dentro de límites estrechos. Pero todavía son toscos. Hay cosas que no están resueltas a escala:

Confiabilidad (Reliability). Un chatbot que da una respuesta ligeramente incorrecta es molesto. Un agente que toma una acción ligeramente incorrecta puede borrar un archivo, enviar un correo equivocado o desplegar código roto. La tasa de error que aceptaría en un chat es la tasa de error que hace que me llamen a las 3 AM en un agente.

Llamadas a herramientas alucinadas. Los modelos a veces inventan herramientas que no existen o pasan argumentos mal formados. Los agentes reales necesitan una capa de validación: comprobación de esquemas, sandboxing y pasos de confirmación para cualquier cosa destructiva.

Bucles infinitos y costos descontrolados. Sin condiciones de terminación, un agente girará felizmente en círculos, quemando tokens y llamadas a la API. Cada sistema de producción que he lanzado tiene límites de pasos, topes de presupuesto y puntos de control humanos.

Evaluación. ¿Cómo se prueba realmente un agente? Las pruebas unitarias cubren las herramientas. La evaluación de extremo a extremo del razonamiento de varios pasos bajo incertidumbre sigue siendo un problema de investigación abierto. SWE-bench y WebArena son un comienzo, pero solo cubren una pequeña fracción de lo que los usuarios reales lanzarán al sistema.

Lo que viene después: sistemas multi-agente

Lo siguiente no es un agente individual más inteligente. Es un equipo de ellos. Las arquitecturas multi-agente asignan diferentes roles a diferentes modelos. Uno planifica, otro programa, un tercero revisa. Se coordinan a través de un paso de mensajes estructurado.

AutoGen y CrewAI son implementaciones tempranas y prometedoras, pero la coordinación es difícil. Los agentes necesitan negociar, delegar y resolver conflictos sin un humano en el bucle. El protocolo de comunicación importa tanto como la capacidad del agente individual. He visto configuraciones multi-agente producir resultados que un solo agente no podría, y también los he visto bloquearse durante cuarenta minutos discutiendo sobre a quién le toca el turno.

El objetivo final no es un modelo único que lo haga todo. Es un sistema de agentes especializados, cada uno bueno en una tarea estrecha, orquestado por un planificador que comprende el panorama general. Aún no hemos llegado ahí. Pero las piezas fundamentales —uso de herramientas, memoria, bucles de planificación— están madurando rápidamente, y la próxima ola de productos de IA no serán chatbots con mejores respuestas. Serán agentes que realmente terminen el trabajo.