Cómo comprender los agentes IA: Diseño, funcionamiento y definición de límites

Algunas personas suelen confundir los LLM con agentes de IA. Aclarémoslo de una vez, ¿te parece? Aunque ciertamente algunos “extienden” los chatbots para ejecutar herramientas y los llaman agentes de IA, ese enfoque resulta inmaduro si quieres aprovechar al máximo los agentes para una automatización avanzada. Y claro que quieres hacerlo, porque sabes que ese es uno de los casos de uso más valiosos para mitigar la creciente fatiga operativa que genera la complejidad de la nube híbrida y multinube.

Un agente de IA debe ser un sistema delimitado como una unidad de software (una aplicación) que interpreta objetivos, mantiene el contexto y ejecuta acciones mediante herramientas. Puede utilizar un modelo de lenguaje extenso (LLM) para razonar sobre lo que debe ocurrir, pero el LLM es solo una parte del conjunto. El agente es el sistema.

En términos prácticos, un agente de IA recibe una tarea (ya sea explícita o deducida), la evalúa dentro de un contexto determinado y decide cómo actuar. Puede realizar acciones como usar herramientas, consultar sistemas o lanzar flujos de trabajo.

Ya no necesitas un enjambre de agentes para sacar partido a uno solo. Un agente bien definido y vinculado a una cadena de herramientas eficaz puede hacer un trabajo útil hoy mismo. Puede automatizar resúmenes, generar informes, clasificar tickets o incluso dirigir alertas a las colas correctas. Mientras respete el alcance y la política, ya aporta valor.

Puedes utilizar agentes de IA sin practicar IA agentic. Pero en cuanto los agentes colaboran, estás haciendo IA agentic, aunque tu arquitectura no esté preparada para ello.

Según nuestra investigación más reciente, asumo que ya estás manejando comportamiento agente (9 % de los encuestados) o te diriges hacia ello (79 % de los encuestados). La IA agentica requiere un marco basado en la ejecución controlada donde varios agentes (sí, “minions”, para distinguirlos más fácilmente de la IA agentica) interactúan con herramientas compartidas, objetivos contextuales y capas de aplicación de políticas virtuales como MCP.

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

Los agentes pueden razonar, delegar y actuar, pero solo dentro del sandbox asignado. No improvisan llamadas al sistema. No inventan accesos a herramientas. Cada acción debe pasar por una interfaz declarativa que puedas asegurar, monitorizar y revocar.

Como mínimo, un agente dispone de:

1. Manejador de contexto – Supervisa el estado, los objetivos y la memoria (a corto plazo o persistente)
2. Motor de razonamiento – Suele ser un LLM o un planificador simbólico que interpreta las tareas y planifica su ejecución
3. Interfaz de herramienta – Mapea intenciones a acciones; controla las operaciones que puede ejecutar el agente
4. Límite de seguridad – Define qué puede hacer el agente y en qué ámbito
5. Capa de transporte – Transporta mensajes y contextos, normalmente utilizando MCP, HTTP o un bus de eventos

Un LLM razona. Un agente actúa. La plataforma controla.

Existen dos modelos predominantes, pero uno te puede engañar.

Este es el estándar en la mayoría de frameworks hoy en día: LangChain, AutoGen, CrewAI, etc. El agente funciona como un chat con herramientas integradas y memoria opcional, todo dentro de una única sesión de LLM.

• Prototipado rápido
• Fácil de probar
• Riesgo al escalar

Limitaciones:

• Arquitectura sin persistencia
• Falta aplicación de políticas nativas
• El modelo tiende a inventar llamadas a herramientas o a ignorar restricciones
• No hay observabilidad fuera de los registros de tokens, a menos que se amplíe

En pocas palabras: es un becario inteligente con acceso root y sin supervisión. Funciona perfectamente, hasta que no.

Este es el modelo que necesitas en producción.

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

• El estado está alojado externamente (Redis, bases de datos vectoriales, motores de políticas)
• Gestionamos el uso de la herramienta con una capa de control clara (servidor MCP, proxy gateway)
• La seguridad y la observabilidad son una prioridad, no algo secundario
• El agente es un servicio desplegado, no un mensaje emergente

Con este enfoque, dispones de control de versiones, registros de acceso, gobernanza a nivel de herramienta y aislamiento en tiempo de ejecución. Así conviertes los agentes de simples herramientas en parte integral de la infraestructura.

Cuando diseñamos agentes pensando que son personas inteligentes, solemos recurrir instintivamente a modelos de acceso centrados en humanos: control de acceso basado en roles (RBAC), tokens de inicio de sesión, atributos de usuario y ámbitos de identidad. Estos funcionan bien si gestionas una identidad humana consistente a lo largo de una sesión. Pero los agentes no actúan así. No son usuarios. Son ejecutores. Y eso cambia por completo el enfoque.

Los agentes cambian de función mientras actúan. Un mismo agente puede recuperar datos, planificar y luego activar la automatización, todo en la misma sesión y bajo la misma tarea. No se limita a iniciar sesión, obtener un token estático y seguir una única ruta.

Aquí es donde falla el control de acceso tradicional. RBAC considera roles estáticos. El control de acceso basado en atributos (ABAC) considera atributos fijos. Los tokens de sesión presuponen un alcance constante. Ninguno de estos aspectos aplica cuando los agentes son dinámicos. La identidad en sistemas agentivos es funcional, no personal.

Por eso, controlar agentes requiere cambiar de políticas basadas en identidad a políticas basadas en ejecución. Validamos cada llamada de herramienta en tiempo real según el rol actual de la tarea del agente, el estado del contexto y el alcance permitido. Las políticas se aplican en la capa de la herramienta, no en la de autenticación. Los bloques de contexto, no las sesiones de inicio de sesión, contienen los metadatos necesarios para hacer cumplir esas políticas. Por eso llamamos a este cambio de paradigma “Política en Payload”, porque la política está verdaderamente en el payload.

Trata a los agentes como agentes. Gobiernalos como software. Y no olvides: el LLM piensa, el agente actúa y la plataforma gobierna. Si confundes esos roles, crearás una personalidad con privilegios de administrador y sin memoria de sus errores anteriores.

El LLM razona. El agente ejecuta. La plataforma administra.

Sigue ese camino y crearás una infraestructura de agentes que escala, protege y resiste el contacto con la realidad.