Agentes de IA: herramientas, MCP y AgentCore

Un chatbot responde. Un agente actúa: recibe un objetivo, decide qué pasos dar, usa herramientas para consultar o cambiar cosas en otros sistemas y sigue hasta terminar. Por dentro es un modelo de lenguaje (LLM) con tres piezas extra: herramientas, memoria y un ciclo que lo hace pensar, actuar y revisar el resultado varias veces.

Para entender agentes conviene tener claro cómo se llama a un modelo en Amazon Bedrock y cómo se le da contexto con RAG. Un agente suele usar RAG como una herramienta más.

El ciclo razonar-actuar y el uso de herramientas

El patrón más común se llama ReAct (reason + act, razonar y actuar). El modelo alterna pensamiento y acción hasta resolver la tarea:

1. 1

   Recibir el objetivo

   El usuario pide algo. El agente recibe la petición, las instrucciones del sistema y la lista de herramientas disponibles con su descripción.
2. 2

   Razonar

   El modelo decide qué le falta saber o hacer y elige la siguiente herramienta, o concluye que ya puede responder.
3. 3

   Actuar

   El modelo devuelve el nombre de la herramienta y los argumentos en JSON. Esto se llama uso de herramientas (tool use o function calling). Tu código, no el modelo, ejecuta la llamada.
4. 4

   Observar

   El resultado vuelve al modelo como un mensaje más. Puede ser un dato, un error o una lista vacía.
5. 5

   Repetir o terminar

   El ciclo sigue hasta que el modelo da la respuesta final o se alcanza un límite: número de pasos, tiempo o presupuesto de tokens.

// Definición de una herramienta para la Converse API de Bedrock
{
  "toolSpec": {
    "name": "consultar_pedido",
    "description": "Devuelve estado y fecha de entrega de un pedido. Úsala cuando el cliente pregunte por un pedido concreto.",
    "inputSchema": {
      "json": {
        "type": "object",
        "properties": {
          "pedido_id": { "type": "string", "description": "ID con formato PED-123456" }
        },
        "required": ["pedido_id"]
      }
    }
  }
}

// El modelo NO ejecuta nada. Responde con stopReason "tool_use" y:
// { "toolUse": { "name": "consultar_pedido", "input": { "pedido_id": "PED-104233" } } }
// Tu código llama a la API real y devuelve el resultado como "toolResult".

La descripción de la herramienta es parte del prompt. Si es vaga, el modelo elige mal o llena mal los parámetros. Escríbela como si se la explicaras a un colega nuevo: qué hace, cuándo usarla, qué formato espera.

MCP, memoria y varios agentes

Antes de MCP, cada framework definía las herramientas a su manera. MCP es un protocolo abierto con tres roles: el host (la aplicación con el modelo), el cliente (la conexión que el host abre) y el servidor (el programa que expone capacidades). Un servidor MCP ofrece herramientas (acciones que el modelo puede invocar), recursos (datos que puede leer, como archivos o registros) y prompts (plantillas reutilizables). Puede correr local, junto al host, o remoto por HTTP.

En AWS, un servidor MCP remoto puede vivir en Lambda (herramientas cortas y sin estado) o en ECS con Fargate (conexiones largas o dependencias pesadas). También puedes desplegarlo en AgentCore Runtime, o usar AgentCore Gateway para convertir APIs, funciones Lambda y especificaciones OpenAPI existentes en herramientas MCP sin reescribirlas.

Cuando una tarea es grande, se reparte entre varios agentes. Los patrones más usados:

• Supervisor y trabajadores: un agente coordinador divide la tarea y llama a agentes especialistas como si fueran herramientas (agents as tools). Fácil de razonar y de auditar.
• Enjambre (swarm): agentes pares que se pasan el control entre sí y comparten contexto. Más flexible, más difícil de predecir.
• Grafo o flujo: tú defines el orden y las dependencias entre agentes. El más determinista.

Strands Agents es un SDK de código abierto de AWS que implementa estos patrones (agentes como herramientas, enjambre, grafo y flujo), soporta A2A y funciona con modelos de Bedrock y de otros proveedores. Cada agente extra suma llamadas, tokens, latencia y puntos de falla: empieza con uno y divide solo cuando lo justifiques con métricas.

Bedrock Agents y Bedrock AgentCore

Criterio	Amazon Bedrock Agents	Amazon Bedrock AgentCore
Qué es	Agentes configurados en Bedrock: instrucciones, grupos de acción y knowledge bases	Una plataforma modular para desplegar y operar agentes hechos con cualquier framework
Framework y modelo	El orquestador de Bedrock con modelos de Bedrock	Strands, LangGraph, CrewAI, LlamaIndex u otro; modelos dentro o fuera de Bedrock
Control	Menos código, menos libertad	Más código, control total del ciclo
Cuándo	Un agente sencillo, rápido de armar desde la consola	Agentes en producción a escala, con aislamiento, identidad y observabilidad

Con AgentCore, el modelo que razona puede estar en Bedrock, en otro proveedor o en un endpoint propio de SageMaker AI.

AgentCore son servicios que puedes usar juntos o por separado:

• 

  Runtime

  Entorno serverless para desplegar agentes y servidores MCP, con aislamiento por sesión y soporte para tareas largas.
• 

  Memory

  Memoria de corto plazo por conversación y de largo plazo entre sesiones, compartible entre agentes.
• 

  Gateway

  Convierte APIs, Lambda y servicios existentes en herramientas MCP, y conecta servidores MCP ya existentes.
• 

  Identity

  Identidad y credenciales del agente, compatible con proveedores como Cognito, Okta o Entra ID. El agente actúa en nombre del usuario sin guardar sus secretos.
• 

  Code Interpreter y Browser

  Un entorno aislado para ejecutar código y un navegador en la nube para operar sitios web.
• 

  Observability, Evaluations y Policy

  Trazas de cada paso, evaluación automática de calidad y reglas deterministas que interceptan cada llamada a una herramienta antes de ejecutarla.

Límites, aprobación humana y observabilidad

Un agente sin límites es un script que improvisa con tus permisos. Las defensas van en capas:

• Condiciones de parada: máximo de pasos por tarea, presupuesto de tokens y tiempo límite. Si se agotan, el agente se detiene y avisa.
• Mínimo privilegio por herramienta: cada herramienta corre con su propio rol de IAM, limitado a lo que hace. La herramienta de consulta solo lee. Si el modelo se equivoca o lo manipulan, el daño queda acotado por el rol, no por el prompt.
• Reglas fuera del modelo: AgentCore Policy evalúa cada llamada a herramienta contra reglas escritas en lenguaje natural o en un lenguaje compatible con Cedar. Un límite en código no se convence con un prompt.
• Aprobación humana (human in the loop): las acciones caras o irreversibles esperan una aprobación. Con Step Functions, el patrón waitForTaskToken pausa el flujo hasta que una persona aprueba. Bedrock Agents permite pedir confirmación al usuario antes de ejecutar una acción.
• Desconfiar de lo que entra: el texto de una página web o de un correo puede traer instrucciones escondidas (inyección de prompts indirecta). Trata la salida de las herramientas como datos, no como órdenes. Más en IA responsable.

Para operar agentes necesitas ver cada paso. AgentCore Observability emite trazas en formato OpenTelemetry y CloudWatch las muestra en su vista de observabilidad de IA generativa. Mide la tasa de tareas completadas, los errores por herramienta, los pasos y tokens por tarea y la latencia de punta a punta. Cómo evaluarlos antes de lanzar está en evaluar IA.

Los agentes también ayudan a programar. Kiro es el entorno de desarrollo agéntico de AWS, con IDE y línea de comandos, que parte de especificaciones antes de escribir código. Para Amazon Q Developer, AWS anunció el fin de soporte de los plugins de IDE y de las suscripciones pagas para el 30 de abril de 2027, y recomienda migrar a Kiro (blog AWS DevOps, abril de 2026; revisado en noviembre de 2026).