La IA agéntica es uno de los temas de mayor crecimiento en el examen actualizado: en vez de un modelo que solo responde texto, un agente razona, decide, actúa sobre sistemas externos y encadena varios pasos. Aquí se cubre el concepto general — independiente de cualquier servicio concreto — y las piezas técnicas que lo hacen posible: MCP, memoria, orquestación y los sistemas multi-agente.
Contenido
Un agente de IA es un sistema construido alrededor de un foundation model que percibe una tarea, razona sobre los pasos necesarios, actúa sobre el mundo real mediante herramientas, y evalúa el resultado de forma iterativa hasta cumplir un objetivo — en vez de limitarse a devolver una respuesta de texto a una única pregunta.
Este concepto es independiente de cualquier servicio de AWS en particular: se puede construir un agente con Bedrock Agents, con un SDK propio, o con frameworks open-source. Lo que define a un agente no es la tecnología subyacente, sino el patrón de comportamiento: razonar → actuar → observar → repetir.
Prompt-respuesta simple
El modelo recibe una entrada, genera texto, y termina. No tiene forma de consultar información que no estaba en su entrenamiento ni en el prompt, y no puede ejecutar ninguna acción real. Es una sola llamada de inferencia, sin estado ni ciclo de decisión posterior.
Agente
El modelo participa en un bucle: decide si necesita más información o una acción concreta, invoca una herramienta, recibe el resultado, decide el siguiente paso, y repite hasta que la tarea completa está resuelta — no solo una pregunta respondida.
Bedrock Agents (cubierto en el módulo de D3) es la implementación administrada de AWS de este patrón general. Este módulo profundiza en los conceptos que aplican sin importar qué plataforma se use para construir el agente.
Crea un agent en Bedrock capaz de invocar APIs externas para completar tareas de varios pasos.
+1 más...
MCP es un protocolo abierto que estandariza cómo un modelo de IA (o un agente) se conecta con herramientas y fuentes de datos externas — bases de datos, APIs, sistemas de archivos — en vez de requerir una integración custom distinta para cada combinación de modelo y herramienta.
Analogía: el USB universal de los agentes
Antes de USB, cada periférico (impresora, teclado, escáner) tenía su propio conector y su propio driver. MCP cumple el mismo rol para agentes de IA: en vez de escribir una integración distinta cada vez que un agente necesita hablar con una nueva herramienta (una base de datos, un CRM, un sistema de archivos), la herramienta expone un servidor MCP que cualquier agente compatible puede usar sin código de integración específico para ese modelo.
Qué problema resuelve exactamente
Sin un protocolo estándar, conectar N modelos con M herramientas requiere hasta N × M integraciones distintas, cada una con su propio formato de entrada/salida. MCP define un formato común: el agente habla "MCP" y cualquier herramienta que exponga un servidor MCP queda disponible, reduciendo drásticamente el trabajo de integración y facilitando reutilizar la misma herramienta entre distintos agentes o modelos.
No todas las tareas se resuelven mejor con un solo agente generalista. Cuando una tarea es lo suficientemente compleja o abarca dominios distintos, conviene dividirla entre varios agentes especializados.
Agente único
Un único agente con acceso a todas las herramientas necesarias resuelve toda la tarea. Es más simple de construir y depurar, pero se vuelve difícil de mantener cuando el número de herramientas y responsabilidades crece — el modelo debe razonar sobre un conjunto cada vez más amplio de opciones en cada paso.
Multi-agente (orquestador + especializados)
Un agente orquestador recibe la solicitud, la descompone en subtareas, y delega cada una al agente especializado adecuado (por ejemplo, un agente de inventario, otro de envíos, otro de atención al cliente). Cada agente especializado tiene un alcance más acotado, lo que facilita razonar mejor sobre su dominio específico y probar/mantener el sistema por partes.
Cuándo preferir multi-agente
En un sistema multi-agente, los agentes necesitan pasarse información y tareas entre sí de forma estructurada, no solo texto libre. Los patrones más comunes:
Orquestador → especializado
El agente orquestador envía una subtarea concreta (con el contexto necesario) a un agente especializado, y espera su resultado antes de continuar o delegar la siguiente subtarea.
Traspaso secuencial (handoff)
Un agente completa su parte del trabajo y entrega el resultado directamente al siguiente agente de la cadena, sin volver a pasar por el orquestador — útil en flujos lineales predecibles.
Estado compartido
Los agentes leen y escriben en un espacio de datos común (por ejemplo, un objeto de sesión o una base de datos compartida) en vez de pasarse mensajes directamente entre sí.
Un agente necesita recordar información — pero no toda la memoria tiene el mismo alcance ni el mismo propósito.
Memoria de corto plazo
Existe solo dentro de una conversación o sesión activa: el historial de mensajes, resultados intermedios de herramientas ya invocadas, y el estado del razonamiento actual. Se pierde cuando termina la sesión y generalmente está limitada por el context window del modelo.
Memoria de largo plazo
Persiste entre sesiones distintas: preferencias del usuario, hechos aprendidos en interacciones anteriores, historial de decisiones pasadas. Normalmente se implementa fuera del modelo, guardando información relevante en una base de datos (a menudo vectorial) y recuperándola cuando es útil en una nueva sesión.
Por qué importa esta distinción
Un agente sin memoria de largo plazo trata cada sesión como si fuera la primera vez que habla con el usuario. Un agente con buena gestión de memoria puede, por ejemplo, recordar que un cliente prefiere respuestas breves, o que ya reportó un problema similar la semana pasada, sin que el usuario tenga que repetir ese contexto en cada conversación.
Un agente decide cuándo y qué herramienta invocar razonando sobre la solicitud del usuario frente a la lista de herramientas disponibles que se le describieron (nombre, propósito, parámetros esperados).
1. Evaluación de necesidad: El modelo determina si puede responder solo con su conocimiento general o si necesita información/acción externa para completar la tarea con precisión.
2. Selección de herramienta: Si necesita actuar, elige — de entre las herramientas descritas — la más adecuada para el paso actual, no necesariamente para toda la tarea de una vez.
3. Generación de parámetros: Construye una llamada estructurada (no texto libre) con los argumentos correctos extraídos de la solicitud del usuario.
4. Observación del resultado: Incorpora el resultado devuelto por la herramienta a su razonamiento antes de decidir si necesita otra herramienta o ya puede responder.
La calidad de la decisión depende directamente de qué tan clara sea la descripción de cada herramienta — nombres ambiguos o descripciones incompletas hacen que el agente elija mal o alucine parámetros.
La orquestación de flujos de trabajo es la capa que coordina múltiples pasos, herramientas o agentes para completar una tarea compleja, gestionando el orden de ejecución, las dependencias entre pasos, y qué hacer cuando un paso falla.
Orquestación secuencial
Los pasos se ejecutan uno tras otro, cada uno usando el resultado del anterior. Simple de razonar, pero más lenta si algunos pasos podrían ejecutarse en paralelo.
Orquestación dinámica
El propio modelo decide en tiempo real el siguiente paso según los resultados obtenidos hasta el momento, en vez de seguir una secuencia fija predefinida de antemano.
En sistemas multi-agente, el agente orquestador cumple este rol: decide a qué agente especializado delegar cada subtarea, en qué orden, y cómo combinar los resultados parciales en una respuesta final coherente.
Además de Bedrock Agents (cubierto en el módulo de D3), AWS ofrece otras dos piezas relevantes para construir y operar agentes, con propósitos distintos y complementarios.
Amazon Bedrock AgentCore
Plataforma pensada para desplegar y operar agentes a escala en producción: gestiona aspectos como runtime, identidad, memoria y observabilidad de los agentes, independientemente del framework con el que se hayan construido. Su enfoque es operacional — llevar un agente ya diseñado a producción de forma confiable y escalable.
Strands Agents
SDK open-source de AWS para construir agentes: proporciona el andamiaje de código para definir el comportamiento del agente, las herramientas que puede usar y su lógica de razonamiento. Su enfoque es de desarrollo — la capa con la que un equipo construye la lógica del agente antes de operarlo.
Cómo se relacionan entre sí
Se pueden entender como capas complementarias: Strands Agents (u otro framework) se usa para construir la lógica del agente; AgentCore se usa para operar ese agente a escala en producción; y Bedrock Agents es la opción totalmente administrada de AWS cuando se prefiere construir agentes directamente sobre foundation models de Bedrock sin gestionar el código de orquestación por separado. Para el examen, basta con reconocer el propósito de cada uno, no memorizar detalles de configuración.
Escenario
Una empresa necesita que un agente consulte el inventario disponible en una base de datos, después llame a una API externa de un proveedor de envíos para calcular el costo y tiempo de entrega, y finalmente notifique al cliente con la información combinada — todo a partir de una sola solicitud en lenguaje natural.
Respuesta razonada
Este escenario describe exactamente el patrón de un agente con tool use encadenado: la tarea requiere invocar varias herramientas distintas (consulta a base de datos, llamada a API externa, envío de notificación) en secuencia, usando el resultado de un paso como entrada del siguiente.
No es un caso de RAG puro (no se trata de recuperar documentos para fundamentar una respuesta), ni de fine-tuning (no requiere cambiar el comportamiento general del modelo), ni de un chatbot con intents fijos como Lex (el orden de las tres acciones y sus parámetros dependen de datos que solo se conocen en tiempo de ejecución). Si además el inventario, los envíos y las notificaciones fueran dominios mantenidos por equipos distintos, sería razonable dividir la tarea en un patrón multi-agente con un orquestador delegando a agentes especializados; con solo tres herramientas bien definidas, un único agente con tool use ya resuelve el caso sin necesidad de esa complejidad adicional.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa quiere que un mismo agente use herramientas expuestas por distintos sistemas internos (una base de datos, un sistema de tickets, un servicio de archivos) sin escribir una integración custom para cada combinación de modelo y herramienta. ¿Qué tecnología está diseñada específicamente para resolver este problema?
Inicia sesión para llevar tu progreso.