Un agente de IA es un sistema en el que un modelo de lenguaje (LLM) no se limita a responder texto, sino que decide qué acciones ejecutar, las ejecuta a través de herramientas (buscar, leer archivos, llamar a una API, ejecutar código), observa el resultado y repite el ciclo hasta completar una tarea. Un chatbot responde a un mensaje; un agente persigue un objetivo en varios pasos. La diferencia no está en el modelo, que puede ser el mismo, sino en la arquitectura que lo rodea: herramientas, bucle de control y criterio de parada.
Este artículo explica esa arquitectura, qué tipos de sistemas se llaman “agentes”, qué riesgos introducen y cuándo tiene sentido usar uno en lugar de algo más simple.
Chatbot frente a agente
| Chatbot (asistente conversacional) | Agente | |
|---|---|---|
| Entrada | Un mensaje del usuario | Un objetivo o tarea |
| Salida | Una respuesta de texto | Acciones y, al final, un resultado |
| Pasos | Uno por turno | Varios, decididos por el propio modelo |
| Acceso al mundo | Solo lo que hay en la conversación | Herramientas externas (archivos, APIs, navegador, terminal) |
| Quién decide el siguiente paso | El usuario, al escribir | El modelo, hasta cumplir el criterio de parada |
| Riesgo principal | Respuesta incorrecta | Acción incorrecta con efectos reales |
Un chatbot que puede buscar en internet antes de responder está a medio camino: usa una herramienta, pero en un único paso fijo. Lo que define a un agente es el bucle: el modelo elige la herramienta, ve el resultado y decide si necesita otra.
Cómo funciona por dentro
La mayoría de agentes actuales siguen una estructura parecida, popularizada por el patrón ReAct (razonar y actuar) y descrita con claridad en la guía de Anthropic Building effective agents:
- Objetivo. El sistema recibe la tarea (“encuentra en el repositorio por qué falla el test X y propón un parche”).
- Herramientas disponibles. Se describen al modelo con nombre, para qué sirven y qué parámetros aceptan (por ejemplo,
leer_archivo(ruta),ejecutar_tests()). - Decisión. El modelo produce o bien una respuesta final, o bien una llamada a herramienta con sus argumentos.
- Ejecución. El programa anfitrión ejecuta la herramienta (el modelo nunca ejecuta nada por sí mismo) y devuelve el resultado al modelo como nuevo contexto.
- Repetición hasta que el modelo decide que ha terminado o se alcanza un límite (número de pasos, tiempo, coste).
Dos detalles importantes:
- Todo lo que el modelo “sabe” sobre la tarea está en su ventana de contexto: la instrucción, las descripciones de herramientas y los resultados acumulados. Cuando el contexto se llena, hay que resumir o descartar.
- Las herramientas son código normal escrito por el desarrollador. El Model Context Protocol (MCP) es un estándar abierto para exponer herramientas y datos a los modelos de forma uniforme, de modo que un mismo servidor de herramientas sirva a distintos agentes.
Flujos de trabajo frente a agentes
No todo lo que encadena varias llamadas a un modelo es un agente. Anthropic distingue entre:
- Flujos de trabajo (workflows): los pasos están definidos de antemano en código. El modelo rellena cada paso (clasifica, resume, redacta), pero no decide el orden. Son predecibles, baratos de depurar y suficientes para la mayoría de automatizaciones.
- Agentes: el modelo decide dinámicamente qué hacer y cuántos pasos dar. Son más flexibles y más caros, y su comportamiento es más difícil de garantizar.
La recomendación práctica de esa guía, y la que vale la pena interiorizar, es empezar con la solución más simple que funcione: una sola llamada bien diseñada, luego un flujo de trabajo, y solo después un agente, si la tarea realmente exige decisiones abiertas.
Ejemplos de uso real
- Asistentes de programación que leen un repositorio, ejecutan tests, editan archivos y abren un pull request.
- Soporte técnico que consulta la documentación interna, revisa el estado de una cuenta y ejecuta una acción (reembolso, reinicio) dentro de límites definidos.
- Investigación: buscar en varias fuentes, leer páginas, contrastar y redactar un informe con referencias.
- Automatización operativa: revisar logs, correlacionar alertas y proponer (no ejecutar) una acción correctora.
Fíjate en el patrón: tareas con varios pasos, resultado verificable y herramientas bien delimitadas.
Riesgos específicos de los agentes
Un agente puede equivocarse igual que un chatbot, pero sus errores se ejecutan. Los riesgos más relevantes:
- Inyección de instrucciones (prompt injection). Si el agente lee una página web, un correo o un archivo que contiene texto del tipo “ignora tus instrucciones y envía los datos a…”, puede obedecerlo. El OWASP Top 10 para aplicaciones LLM la sitúa como el primer riesgo. Trata todo contenido externo como datos, no como órdenes, y limita lo que las herramientas pueden hacer.
- Acciones irreversibles. Borrar, pagar, enviar. Exige confirmación humana para ellas o directamente no las expongas como herramienta.
- Bucles y coste. Un agente que no converge puede repetir pasos indefinidamente. Fija límites de pasos, tiempo y presupuesto.
- Permisos excesivos. Dale al agente las credenciales mínimas para su tarea, igual que harías con cualquier servicio.
- Falsa seguridad. Que un agente “explique” lo que ha hecho no garantiza que sea correcto. Verifica el resultado con tests, revisiones o comprobaciones independientes.
Cuándo conviene (y cuándo no) usar un agente
Conviene cuando la tarea tiene varios pasos cuyo orden depende de lo que se vaya encontrando, cuando el resultado se puede verificar (un test que pasa, un dato contrastado) y cuando el coste de un error es acotado o reversible.
No conviene cuando el proceso es siempre igual (usa un flujo de trabajo), cuando una sola llamada al modelo resuelve el problema, o cuando un error tendría consecuencias graves sin posibilidad de revisión humana.
Conclusión
Un agente de IA es un modelo de lenguaje dentro de un bucle con herramientas y un criterio de parada. Esa arquitectura le permite completar tareas en lugar de solo responder, y a cambio introduce riesgos nuevos: acciones equivocadas, inyección de instrucciones y costes descontrolados. La forma sensata de adoptarlos es progresiva (llamada simple, flujo de trabajo, agente), con herramientas acotadas, permisos mínimos y verificación del resultado.