Agentes de IA: una introducción

“Agente de IA” es hoy el término más trillado del sector. Se vende como magia, pero por dentro hay un bucle sencillo. Cuando entiendes ese bucle, ya no te dejas engañar por las demos y empiezas a valorar con frialdad cuándo tiene sentido un agente y cuándo es mejor un simple script. Este texto es para desarrolladores que han oído la palabra “agente” quinientas veces y todavía no saben explicar en qué se diferencia de un chatbot. Se diferencia en una sola cosa: un agente actúa, no se limita a responder.

Qué es un agente y qué no es

Un chatbot recibe texto y devuelve texto. Nada más. No tiene acceso al mundo, no ejecuta acciones y no recuerda nada fuera de la ventana de contexto de la conversación actual. Un agente es algo más. La definición práctica que conviene retener: un agente es un LLM, más herramientas, más un bucle, más memoria.

• LLM: el cerebro que decide qué hacer a continuación;
• herramientas: las manos (un buscador, una base de datos, una terminal, una API);
• bucle: el mecanismo que le permite dar más de un paso;
• memoria: lo que el agente sabe más allá del prompt actual.

Quita cualquiera de estos elementos y deja de ser un agente. Un LLM sin herramientas es un chatbot. Un LLM con herramientas pero sin bucle es una sola llamada a una función: útil, pero no es un agente. Solo el bucle, en el que el modelo observa el resultado de su propia acción y decide la siguiente, convierte un modelo de lenguaje en algo que persigue un objetivo.

El bucle, el corazón del agente

El modelo mental más sencillo es el ciclo percibir, planificar, actuar, observar. El agente recibe un objetivo, mira el estado actual, elige una acción, la ejecuta, lee el resultado y vuelve al principio. Repite hasta que considera cumplido el objetivo o agota su presupuesto de pasos.

1. Percibir: reunir el contexto (el objetivo, los resultados obtenidos hasta ahora, el estado del mundo);
2. Planificar: decidir qué herramienta llamar y con qué argumentos;
3. Actuar: ejecutar la llamada a la herramienta (lo hace tu código, no el modelo);
4. Observar: el resultado de la herramienta vuelve al contexto como una nueva observación.

Este bucle es engañosamente sencillo, y ahí se esconden la mayoría de los problemas en producción. Sin un límite estricto de iteraciones, un agente puede dar vueltas en círculo, llamar diez veces a la misma herramienta o “mejorar” una solución que funciona hasta romperla. Un límite de pasos y un criterio claro de “terminado” no son opcionales: son un requisito.

Tool use y function calling

El mecanismo que le da manos a un LLM se llama function calling o tool use. Funciona así. Le describes al modelo las herramientas disponibles: un nombre, una descripción y un esquema de argumentos (normalmente JSON Schema). En lugar de responder con texto, el modelo devuelve una petición estructurada: “llama a search con el argumento query: AI agents”.

Un detalle clave que confunde a los principiantes: el modelo no ejecuta la herramienta. Solo pide que se ejecute. Es tu código el que recibe la petición, ejecuta la función real, captura el resultado y lo devuelve al contexto. La frontera de confianza pasa justo por aquí, y es de este lado, en tu código, donde pones la validación de argumentos y los límites. Nunca dejes que el texto generado por el modelo llegue directamente a eval, a una shell o a una consulta SQL sin una capa de control.

ReAct frente a plan-and-execute

Hay dos arquitecturas de bucle dominantes y conviene conocer la diferencia.

ReAct (reason + act) intercala el razonamiento y la acción. El modelo razona en voz alta sobre la marcha, ejecuta una acción, lee el resultado y vuelve a razonar. Es reactivo y se desenvuelve bien en entornos impredecibles, cuando no se puede planificar todo de antemano porque cada paso cambia el panorama. La desventaja: puede pecar de corto de miras y perderse en una cadena larga.

Plan-and-execute separa las fases. Primero el modelo traza un plan completo (una lista de pasos) y luego los ejecuta en orden, replanificando si algo sale mal. Ofrece más previsibilidad y es más barato, porque la planificación ocurre una sola vez y no en cada iteración. La desventaja: un plan rígido lleva mal los entornos que cambian más rápido de lo que el agente tarda en completarlo.

Mi elección por defecto: empieza con ReAct, porque es más sencillo de poner en marcha y de depurar. Pasa a plan-and-execute cuando las tareas se alarguen y el costo de “pensar” en cada paso empiece a doler.

Un agente o varios

La tentación de repartir un problema entre un equipo de agentes especializados (investigador, programador, revisor, orquestador) es fuerte y, por lo general, prematura. Un sistema multiagente suena elegante, pero añade dos costos reales: la comunicación entre agentes quema tokens y los errores de un agente se propagan al resto, a menudo sin que nadie lo note.

• Un agente: el punto de partida por defecto. Más fácil de rastrear, más barato y suficiente para la gran mayoría de las tareas;
• Varios agentes: recurre a ellos cuando una tarea se divide de forma natural en subdominios paralelos o cuando necesitas distintos conjuntos de herramientas y permisos para distintos roles.

Regla práctica: no añadas un segundo agente hasta que uno realmente no sea suficiente. La mayoría de los “necesitamos un sistema multiagente” son en realidad “nuestro único agente tiene demasiadas herramientas y un prompt demasiado vago”.

Memoria: corta, larga, vectorial

La memoria es de dos tipos, y confundirlos es un error de diseño habitual.

• La memoria a corto plazo es la ventana de contexto: la conversación actual, las observaciones recientes. Es rápida pero limitada, y desaparece cuando termina la sesión;
• La memoria a largo plazo es el conocimiento que sobrevive a la sesión: documentos, historial, datos sobre el usuario. Suele guardarse fuera del modelo y se recupera bajo demanda.

El mecanismo de memoria a largo plazo más común es una base de datos vectorial. Conviertes el texto en un embedding (un vector de números) y, al hacer una consulta, buscas los fragmentos más cercanos en significado y los inyectas en el contexto. Ese es el fundamento de RAG. Cuidado con la trampa: una base de datos vectorial no es magia; si la alimentas con basura, el agente recibirá basura semánticamente parecida. La calidad de tus chunks y de tus metadatos lo decide todo.

MCP: un estándar común para las herramientas

Hasta hace poco, cada framework de agentes definía las herramientas a su manera. MCP (Model Context Protocol) es un intento de unificarlo: un protocolo abierto en el que un servidor expone herramientas, recursos y prompts, y cualquier cliente (agente) puede usarlos sin escribir una integración desde cero.

Por qué te importa: escribes un servidor MCP una vez y se conecta a muchos agentes y hosts. En lugar de n integraciones para n herramientas y m agentes, tienes una única interfaz compartida. Para las herramientas de agentes es, más o menos, lo que LSP llegó a ser para los editores de código: un solo protocolo en lugar de un número cuadrático de plugins. En 2026 vale la pena escribir las nuevas integraciones de herramientas sobre MCP si tienes elección.

Dónde brillan los agentes y dónde se desmoronan

Los agentes funcionan de maravilla cuando una tarea requiere muchos pasos, acceso a herramientas y tolerancia a la iteración:

• Investigación: búsqueda en muchas fuentes, síntesis, verificación cruzada;
• Programación: leer un repositorio, escribir cambios, ejecutar tests, corregir;
• Operaciones: triaje de tickets, tareas rutinarias con datos, automatización de workflows.

Y con la misma previsibilidad se desmoronan en:

• Horizontes largos: cuantos más pasos, más probable es que el agente pierda de vista el objetivo o se atasque;
• Acumulación de errores: si un solo paso sale bien el 95% de las veces, tras veinte pasos la probabilidad combinada de éxito cae por debajo de la mitad. Los errores se multiplican, no se suman;
• Costo: cada iteración es una llamada al LLM. Un agente que “piensa” treinta veces cuesta treinta veces más que una sola consulta y, a veces, ni siquiera así termina la tarea.

Toma estas cifras como una estimación que ilustra el mecanismo, no como un benchmark riguroso: las tasas reales dependen de la tarea y del modelo. Pero la dirección es segura: la falta de fiabilidad crece con la longitud de la cadena.

Guardrails y humano en el bucle

Un agente con acceso a herramientas puede romper algo de verdad: borrar un archivo, enviar un correo, gastar dinero. Por eso los guardrails no son un añadido, sino parte de la arquitectura.

• Límites: un número máximo de pasos, un presupuesto de tokens, un timeout;
• Validación de herramientas: cada llamada se comprueba en el código (por ejemplo, con un esquema) antes de que se ejecute nada;
• Mínimo privilegio: el agente solo tiene acceso a lo que de verdad necesita, nunca a la base de datos de producción “por si acaso”;
• Humano en el bucle: las acciones irreversibles o costosas requieren la aprobación de una persona antes de ejecutarse.

Tener un humano en el bucle no es desconfiar de la IA: es el mismo principio que aplicas a un deploy en producción o a una migración de base de datos. Cuanto más alto sea lo que está en juego y más difícil sea deshacer el efecto, más cerca de la decisión debe estar una persona.

¿Agente o un simple script?

La decisión más importante se toma antes de escribir una sola línea. El modelo mental es sencillo: si los pasos se conocen de antemano y no cambian, escribe un script. Un script es más barato, más rápido, determinista y fácil de probar.

Recurre a un agente solo cuando el camino hacia el objetivo no se conoce de antemano, cuando cada paso depende del resultado del anterior y el número de ramificaciones es demasiado grande para dejarlo fijo en el código. Dicho de otro modo: un agente es una herramienta para la incertidumbre, no para la repetición. Si puedes dibujar un diagrama de flujo de la tarea, casi siempre será mejor un script. Si el diagrama tiene cien caminos y la mitad dependen del contenido de los datos, ese es terreno fértil para un agente.

TL;DR

Un agente es un LLM más herramientas, más un bucle, más memoria: algo que actúa, no algo que solo responde. El corazón es el bucle percibir-planificar-actuar-observar; el function calling le da manos, pero quien ejecuta la herramienta es tu código, no el modelo. Empieza con ReAct y un solo agente, deja que una base de datos vectorial se encargue del conocimiento que queda fuera del contexto y apóyate en MCP para estandarizar las herramientas. Los agentes brillan en investigación, programación y operaciones, pero se desmoronan en horizontes largos por la acumulación de errores y el costo. Rodéalos de límites y de un humano en el bucle para las acciones irreversibles. Y si los pasos se conocen de antemano, escribe un script, no un agente.