¿Qué es un agente de IA y en qué se diferencia de un chatbot?

La palabra agente se ha estirado hasta cubrir casi cualquier cosa que lleve un modelo de lenguaje dentro. Eso es un problema de marketing, no de ingeniería. Debajo hay una definición concreta y bastante estrecha, y conviene conocerla, porque de esa diferencia depende lo que puede salir mal.

La definición: un modelo en un bucle con herramientas

Un chatbot corriente hace una cosa: recibe texto y devuelve texto. Lo que «sabe» tiene que estar ya en el modelo o en el prompt.

Un agente añade tres cosas:

1. Herramientas. Funciones corrientes que el modelo puede invocar: consultar una base de datos, hacer una petición HTTP, ejecutar un comando, escribir un fichero. El modelo no las ejecuta; emite una petición estructurada, tu código la ejecuta y el resultado vuelve.
2. Un objetivo. Una tarea formulada por encima de un solo paso: «concilia estas facturas», no «lee la línea 4».
3. Un bucle. Tras cada resultado, el modelo decide qué hacer a continuación. Sigue hasta que juzga cumplido el objetivo, alcanza un límite de pasos o falla.

Ese bucle es todo. Lo demás —memoria, planificación, subagentes, borradores— son optimizaciones encima.

Qué son realmente las herramientas

Aquí es donde la gente se sorprende: las herramientas no son componentes especiales de IA. Una herramienta es una función con un nombre, una descripción y un esquema de argumentos. Se escribe en una tarde.

name: search_orders
description: Busca pedidos por correo del cliente o número de pedido.
parameters:
  query: string
  limit: integer (por defecto 20)

El modelo ve esa descripción en su contexto, decide que search_orders es pertinente y emite una llamada con argumentos. Tu runtime ejecuta la función real y devuelve el resultado como texto. El modelo nunca toca tu base de datos.

De ahí se siguen dos cosas. Primera: un agente es tan capaz como las herramientas que le des; el modelo aporta el juicio sobre cuál y con qué argumentos, nada más. Segunda: la descripción de la herramienta forma parte del prompt, y una descripción vaga produce llamadas erróneas igual que una instrucción vaga produce respuestas erróneas.

El Model Context Protocol (MCP) existe para que no todo el mundo reconstruya los mismos servidores de herramientas. Estandariza cómo un servidor anuncia lo que ofrece, de modo que una implementación sirva a muchos productos.

Lo difícil es la fiabilidad

Los agentes fallan de una forma fácil de pasar por alto en una demo. Supongamos que cada paso de un flujo tiene éxito el 95% de las veces: una cifra respetable para un modelo haciendo algo no trivial.

El modelo no está mal. Los errores simplemente se multiplican. Por eso los agentes que funcionan en producción tienden a ser poco vistosos: entre cinco y quince pasos, un dominio muy acotado y un punto de control humano en los momentos caros.

También explica un patrón que aparece una y otra vez en las guías de los proveedores: elige la arquitectura más simple que funcione. Una sola llamada bien planteada gana a una cadena; una cadena gana a un bucle autónomo; un bucle autónomo gana a un enjambre de agentes. Cada escalón compra flexibilidad y la paga en previsibilidad.

Dónde los agentes se ganan el sueldo

Las tareas que les sientan bien comparten una forma: el objetivo es claro, el camino no lo es, y el resultado es barato de verificar.

• Programar. Los tests pasan o no pasan. El agente puede iterar contra una señal objetiva.
• Investigación y recopilación. Reunir material de muchas fuentes, donde de todos modos una persona lee el resultado.
• Triaje. Clasificar y enrutar tickets, marcar anomalías, redactar primeras respuestas para revisión.
• Conciliación de datos. Cruzar registros entre sistemas cuyos esquemas casi —pero no del todo— coinciden.

Las que les sientan mal son la imagen especular: verificar sale caro, los errores son irreversibles, o el camino correcto ya se conoce, en cuyo caso escribe el script. Nadie necesita un agente para enviar un informe nocturno.

El límite de permisos

Como el agente decide sus propios pasos, «qué puede hacer» no se responde leyendo el código. Hay que imponerlo fuera del modelo.

En la práctica:

• Lee mucho, escribe poco. Que mire lo que necesite; pon una puerta en cada acción que cambie el estado.
• Aprobación para lo irreversible. Dinero, mensajes externos, borrados, despliegues a producción.
• Presupuestos. Límite de pasos, de tiempo y de tokens. Un agente atascado en un bucle es un incidente de facturación.
• Un registro reproducible. Cada llamada y cada resultado, guardados. Cuando algo falle, «qué hizo exactamente» debe responderse en segundos.

La inyección de prompts merece línea propia. Si tu agente lee una página web, un correo o un comentario de una pull request, un atacante puede poner instrucciones en ese contenido. El modelo no tiene forma fiable de distinguir tus instrucciones de las que acaba de leer. La defensa no es un prompt mejor, sino no concederle una autoridad que no debería tener.

Cómo separar el ruido de lo sólido

Ante un producto que se llama agéntico, tres preguntas bastan:

1. ¿Qué herramientas puede invocar, exactamente? ¿Una lista que se pueda leer, o gestos?
2. ¿Qué pasa cuando un paso falla? ¿Reintenta, escala, se detiene, o produce en silencio una respuesta plausible y equivocada?
3. ¿Qué puede hacer sin preguntar? Si la respuesta es «todo», eso no es autonomía: es una responsabilidad sin límite.

Un agente no es un chatbot más listo. Es un chatbot con la mano en los mandos, y la ingeniería que importa trata casi por completo de esa mano.