Comprender los agentes de IA: construcción, comportamiento y establecimiento de límites

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Algunas personas parecen estar confundiendo los LLM con los agentes de IA. Dejemos zanjada esta cuestión de una vez, ¿de acuerdo? Aunque es cierto que algunos están «ampliando» los chatbots para que ejecuten herramientas y los llaman agentes de IA, se trata de un enfoque poco maduro si se quiere aprovechar el potencial de los agentes para la automatización avanzada. Y, por supuesto, eso es lo que quiere hacer, porque reconoce que este es uno de los casos de uso más valiosos para hacer frente a la creciente fatiga operativa provocada por la complejidad de los entornos híbridos y multicloud.

Un agente de IA debe ser una unidad de software (una aplicación), un sistema delimitado que interpreta objetivos, mantiene el contexto y realiza acciones mediante el uso de herramientas. Puede utilizar un modelo de lenguaje de gran tamaño (LLM) para razonar sobre lo que debe suceder, pero el LLM es solo una pieza del engranaje. El agente es el sistema.

En términos prácticos, un agente de IA recibe una tarea (explícita o inferida), la evalúa dentro de un contexto delimitado y decide cómo actuar. Entre las posibles acciones se incluyen invocar herramientas, consultar sistemas o activar flujos de trabajo.

Ahora bien, no necesitas un enjambre de agentes para sacar partido de uno. Un único agente con un ámbito bien definido y vinculado a un conjunto de herramientas específico ya puede realizar tareas útiles. Puede automatizar resúmenes, generar informes, clasificar incidencias o incluso dirigir las alertas a las colas adecuadas. Siempre que respete el ámbito y las políticas establecidos, ya aporta valor.

Puedes utilizar agentes de IA sin recurrir a la IA agéntica. Pero, en cuanto los agentes colaboran, sí estás utilizando IA agéntica, aunque tu arquitectura no esté preparada para ello.

Según nuestra investigación más reciente, supongo que ya estás lidiando con comportamientos agénticos (el 9 % de los encuestados) o que vas camino de ello (el 79 % de los encuestados). La IA agéntica requiere un marco basado en una ejecución controlada, en el que varios agentes (sí, «secuaces», porque así resulta más fácil distinguirlos de la IA agéntica) interactúen con herramientas compartidas, objetivos contextuales y capas de control como MCP.

¿Qué es un agente?

Un agente es una entidad de software que funciona de forma autónoma o semiautónoma dentro de unos límites claramente definidos. Interpreta tareas, gestiona el contexto, utiliza herramientas y toma decisiones en nombre de un usuario o de un sistema más amplio. En las arquitecturas compatibles con MCP, los agentes se ajustan a un protocolo estructurado que regula la interacción entre las tareas, el estado y las políticas.

Los agentes pueden razonar, delegar y actuar, pero solo dentro del entorno aislado que se les ha asignado. No improvisan llamadas al sistema ni se inventan accesos a herramientas. Todas las acciones deben pasar por una interfaz declarada que pueda protegerse, supervisarse y revocarse.

Como mínimo, un agente tiene:

1. Gestor de contexto – Realiza un seguimiento del estado, los objetivos y la memoria (a corto plazo o persistente)
2. Motor de razonamiento – Normalmente, un LLM o un planificador simbólico que interpreta tareas y planifica su ejecución
3. Interfaz de herramientas – Traduce la intención en acciones y controla qué operaciones puede ejecutar el agente
4. Límite de seguridad – Impone qué puede hacer el agente y dentro de qué ámbito
5. Capa de transporte – Transfiere mensajes y contexto, normalmente mediante MCP, HTTP o un bus de eventos

Un LLM piensa. Un agente actúa. La plataforma gobierna.

Modelos de construcción de agentes

Hay dos modelos predominantes, y uno de ellos es una trampa.

Actualmente existen dos enfoques predominantes para crear agentes de IA: el centrado en los LLM y el limitado a una aplicación. El enfoque centrado en los LLM es adecuado para los chatbots, pero no para casos de uso de automatización más exigentes.

1. Agentes centrados en LLM (monolíticos)

Este es el enfoque predeterminado de la mayoría de los frameworks actuales: LangChain, AutoGen, CrewAI, etc. El agente es, en esencia, un prompt de chat con herramientas integradas y memoria opcional, todo ello en torno a una única sesión de un LLM.

• Rápido para crear prototipos
• Fácil de mostrar en una demostración
• No es seguro escalarlo

Limitaciones:

• Sin arquitectura persistente
• Sin aplicación nativa de políticas
• Es fácil que el modelo alucine llamadas a herramientas u olvide las restricciones
• Observabilidad nula más allá de los registros de tokens, salvo que se amplíe

En resumen: es como un becario listo con acceso root y sin supervisión. Funciona de maravilla, hasta que deja de hacerlo.

2. Agentes vinculados a aplicaciones (modulares)

Este es el modelo que querrás usar en producción.

Aquí, el agente es un servicio de software completo creado sobre un framework que utiliza un LLM, pero no depende de él para gestionar la ejecución.

• El estado es externo (Redis, bases de datos vectoriales, motores de políticas)
• El uso de herramientas es explícito y está gestionado por una capa de control (servidor MCP, proxy de puerta de enlace)
• La seguridad y la observabilidad son aspectos prioritarios, no algo que se añade a posteriori
• El agente es un servicio desplegado, no un prompt

Este enfoque te proporciona control de versiones, registros de acceso, gobernanza a nivel de herramientas y aislamiento en tiempo de ejecución. Así es como se consigue que los agentes dejen de ser meros juguetes y se conviertan en infraestructura.

Los agentes no son personajes

Cuando se diseñan agentes como si fueran entidades inteligentes, se tiende instintivamente a recurrir a modelos de acceso centrados en las personas: control de acceso basado en roles (RBAC), tokens de inicio de sesión, atributos de usuario y ámbitos de identidad. Estos modelos tienen sentido cuando se trabaja con una identidad humana coherente durante toda una sesión. Pero los agentes no se comportan así. No son usuarios, sino ejecutores. Y eso lo cambia todo.

Los agentes cambian de rol a medida que operan. Un mismo agente puede actuar como recuperador de datos, después como planificador y, a continuación, como desencadenante de una automatización, a menudo dentro de la misma sesión y en el marco de una misma tarea. No inicia sesión, obtiene un token estático y se limita a una única función.

Aquí es donde falla el control de acceso tradicional. El control de acceso basado en roles (RBAC) presupone roles estáticos. El control de acceso basado en atributos (ABAC) presupone atributos fijos. Los tokens de sesión presuponen un ámbito constante. Nada de esto se cumple cuando los agentes son dinámicos. En los sistemas agénticos, la identidad es funcional, no personal.

Por eso, la gobernanza de los agentes exige pasar de políticas basadas en la identidad a políticas basadas en la ejecución. Cada llamada a una herramienta debe validarse en tiempo real en función del rol que desempeña el agente en la tarea actual, el estado del contexto y el ámbito permitido. Las políticas residen en la capa de herramientas, no en la de autenticación. Son los bloques de contexto, y no las sesiones de inicio de sesión, los que contienen los metadatos necesarios para aplicar esas políticas. Por eso denominamos a este cambio de paradigma «Política en la carga útil», porque la política está literalmente en la carga útil.

Trata a los agentes como agentes. Gobiérnalos como software. Y no lo olvides nunca: el LLM piensa, el agente actúa y la plataforma gobierna. Si confundes esos roles, estarás creando una personalidad con permisos de administrador y sin memoria de su último error.

El LLM piensa. El agente actúa. La plataforma gobierna.

Cíñete a eso y construirás una infraestructura de agentes escalable, segura y capaz de resistir el contacto con la realidad.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie