Semana 5 · Módulo 5 de 11

IA agéntica, herramientas y Amazon Bedrock AgentCore

Aprenderás qué es un agente de IA desde cero, cómo se le dan herramientas, memoria y límites, y cómo se construye con Strands Agents, MCP y Amazon Bedrock AgentCore. Es el task statement 2.1, uno de los más «de diseño» del examen: agentes frente a workflows, multiagente, human-in-the-loop y controles de seguridad.

Reparto de la semana

Por qué importa

Hasta ahora has usado el modelo como una función: le mandas un prompt y te devuelve texto. Un agente (agent) va un paso más allá: el modelo decide qué hacer, llama a herramientas (APIs, bases de datos, otros modelos), mira el resultado y vuelve a decidir, en bucle, hasta cumplir un objetivo. Es la pieza que convierte un chatbot en algo que actúa: consulta un pedido, abre una incidencia, reserva una cita.

El task statement 2.1 (Implement agentic AI solutions and tool integrations) tiene siete skills y el examen las pregunta como decisiones de arquitectura:

• ¿Agente o workflow determinista? ¿Un agente o varios?
• ¿Dónde guardo la memoria? ¿Cómo evito que el agente entre en bucle o gaste sin control?
• ¿Cómo expongo mis APIs como herramientas de forma estándar (MCP) y segura (IAM, OAuth, políticas)?
• ¿Dónde ejecuto el agente en producción con aislamiento por sesión (AgentCore Runtime)?
• ¿Cómo meto a una persona en el circuito para aprobar acciones delicadas?

Qué es un agente, desde cero

Del prompt al bucle

Un modelo fundacional (foundation model, FM) solo genera texto. No puede consultar tu base de datos ni enviar un correo. Lo que sí puede es pedir que alguien lo haga: con tool use (también llamado function calling, llamada a funciones), tú describes herramientas en la petición y el modelo, en vez de contestar, devuelve «quiero llamar a consultar_pedido con pedido_id = P-1001». Tu código ejecuta la herramienta, le devuelve el resultado y el modelo continúa. Lo viste en el módulo 04 con la API Converse: el modelo responde con stopReason = tool_use y un bloque toolUse; tú contestas con un bloque toolResult.

Un agente es exactamente ese mecanismo metido en un bucle con un objetivo:

flowchart TD
    U["Petición del usuario"] --> M["Modelo: razona y decide"]
    M -->|"stopReason = tool_use"| T["Ejecutar herramienta"]
    T -->|"toolResult (observación)"| M
    M -->|"stopReason = end_turn"| R["Respuesta final"]
    M -->|"límite de turnos, tokens o tiempo"| S["Parada controlada"]

A este bucle se le llama agent loop o bucle razonar-actuar-observar. Cada vuelta es un turno (turn o cycle): una llamada al modelo más las herramientas que pida.

Las piezas de un agente

Memoria: corto y largo plazo

Un LLM no recuerda nada entre llamadas. Toda la «memoria» es contexto que tú vuelves a enviar.

• Memoria a corto plazo (short-term memory): los mensajes de la sesión actual. Crece con cada turno y consume la ventana de contexto (context window, el máximo de tokens que el modelo acepta). Por eso se gestiona con estrategias: ventana deslizante (guardar los N últimos mensajes), resumen de lo antiguo o recorte de resultados de herramientas grandes.
• Memoria a largo plazo (long-term memory): información extraída y consolidada que se recupera en sesiones futuras («el cliente prefiere envío urgente»). Se recupera por búsqueda semántica, igual que en RAG.
• Estado (state): datos estructurados de la tarea (paso actual, identificadores, contadores). No es lo mismo que memoria conversacional; suele vivir en DynamoDB, en el estado de Step Functions o en el estado del agente.

Patrones de razonamiento

Chain-of-thought (CoT)

Chain-of-thought (cadena de pensamiento) es pedir al modelo que razone paso a paso antes de responder. Mejora tareas de lógica y cálculo. Es una técnica de prompt (módulo 04); en un agente es la parte «razonar» de cada turno.

ReAct: razonar + actuar

ReAct (Reason + Act) alterna tres cosas: Thought (pensamiento: qué necesito), Action (acción: llamar a una herramienta) y Observation (observación: el resultado). Se repite hasta tener la respuesta. Es el patrón por defecto de casi todos los frameworks de agentes, incluidos Strands y AgentCore Harness.

Pregunta: ¿Cuánto cuesta enviar por urgente el pedido P-1001?
Thought: necesito el peso del pedido.
Action: consultar_pedido(pedido_id="P-1001")
Observation: {"estado": "enviado", "peso_kg": 2.5}
Thought: ahora calculo el envío urgente de 2,5 kg.
Action: calcular_envio(peso_kg=2.5, modalidad="urgente")
Observation: {"coste_eur": 11.75}
Respuesta: El envío urgente costaría 11,75 €.

Otros patrones que debes reconocer

ReAct con Step Functions (skill 2.1.2)

La guía cita expresamente «Step Functions to implement ReAct patterns and chain-of-thought reasoning». La idea: en vez de un bucle while en tu código, el bucle es una máquina de estados con estados visibles, reintentos, timeouts y un contador de iteraciones como condición de parada.

flowchart TD
    A["Inicializar: iteracion = 0"] --> B["Lambda: llamar al modelo (Converse)"]
    B --> C{"stopReason"}
    C -->|"end_turn"| OK["Éxito: devolver respuesta"]
    C -->|"tool_use"| D{"iteracion mayor o igual que 8"}
    D -->|"sí"| F["Fallo controlado: LimiteIteraciones"]
    D -->|"no"| E["Lambda: ejecutar herramienta (timeout, reintentos)"]
    E --> G["iteracion + 1 y añadir toolResult al historial"]
    G --> B
    E -->|"error tras reintentos"| H["Catch: devolver error al modelo o escalar a humano"]

Fragmento de la definición (Amazon States Language, ASL):

{
  "StartAt": "LlamarModelo",
  "States": {
    "LlamarModelo": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "Parameters": { "FunctionName": "react-llamar-modelo", "Payload.$": "$" },
      "OutputPath": "$.Payload",
      "TimeoutSeconds": 60,
      "Retry": [
        { "ErrorEquals": ["ThrottlingException"], "IntervalSeconds": 2, "BackoffRate": 2, "MaxAttempts": 4 }
      ],
      "Next": "DecidirSiguientePaso"
    },
    "DecidirSiguientePaso": {
      "Type": "Choice",
      "Choices": [
        { "Variable": "$.stopReason", "StringEquals": "end_turn", "Next": "Exito" },
        { "Variable": "$.iteracion", "NumericGreaterThanEquals": 8, "Next": "LimiteIteraciones" }
      ],
      "Default": "EjecutarHerramienta"
    },
    "EjecutarHerramienta": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "Parameters": { "FunctionName": "react-ejecutar-herramienta", "Payload.$": "$" },
      "OutputPath": "$.Payload",
      "TimeoutSeconds": 30,
      "Catch": [ { "ErrorEquals": ["States.ALL"], "ResultPath": "$.error", "Next": "EscalarAHumano" } ],
      "Next": "LlamarModelo"
    },
    "EscalarAHumano": { "Type": "Fail", "Error": "HerramientaFallida" },
    "LimiteIteraciones": { "Type": "Fail", "Error": "LimiteIteraciones" },
    "Exito": { "Type": "Succeed" }
  }
}

Qué gana esta versión frente a un bucle en código: historial de ejecución auditable, reintentos declarativos, timeouts por paso, condición de parada explícita y la posibilidad de insertar un paso de aprobación humana (lo verás en «Human-in-the-loop»). Qué pierde: más latencia y más piezas que mantener. Si el enunciado prima «trazabilidad de cada paso» y «control de ejecución», Step Functions encaja; si prima «mínimo esfuerzo operativo para un agente conversacional», un framework de agentes en AgentCore Runtime.

Workflows deterministas frente a agentes

No todo necesita un agente. Un agente es no determinista: el modelo elige el camino, así que dos ejecuciones pueden diferir. Eso da flexibilidad y quita previsibilidad.

Regla práctica: empieza por lo más simple que cumpla. Si los pasos son conocidos y fijos (validar documento → extraer campos → guardar), workflow. Si las peticiones son abiertas y la ruta depende de lo que se descubra por el camino, agente. Si hay dominios muy distintos o subtareas paralelas, multiagente.

Herramientas fiables (skill 2.1.6)

Una herramienta mal diseñada es la causa más habitual de agentes que fallan. El modelo solo ve nombre, descripción y esquema: si son ambiguos, elegirá mal o pasará parámetros erróneos.

Definición estandarizada

Todas las plataformas usan la misma idea: un JSON Schema de entrada. En Converse se llama toolSpec:

{
  "toolSpec": {
    "name": "calcular_envio",
    "description": "Calcula el coste de envío en euros de un paquete.",
    "inputSchema": {
      "json": {
        "type": "object",
        "properties": {
          "peso_kg": { "type": "number", "description": "Peso en kg, mayor que 0 y como máximo 30." },
          "modalidad": { "type": "string", "enum": ["estandar", "urgente"] }
        },
        "required": ["peso_kg"]
      }
    }
  }
}

Buenas prácticas

Lambda como herramienta: validación y errores

La guía pide «Lambda functions to implement error handling and parameter validation». Patrón típico:

import json

def handler(event, context):
    # El agente (o el gateway) entrega los parámetros de la herramienta
    try:
        peso = float(event["peso_kg"])
    except (KeyError, TypeError, ValueError):
        return {"ok": False, "error": "peso_kg es obligatorio y debe ser numérico"}
    if not 0 < peso <= 30:
        return {"ok": False, "error": "peso_kg debe estar entre 0 y 30"}
    modalidad = event.get("modalidad", "estandar")
    if modalidad not in ("estandar", "urgente"):
        return {"ok": False, "error": "modalidad debe ser estandar o urgente"}
    coste = 4.0 + 0.6 * peso if modalidad == "estandar" else 9.0 + 1.1 * peso
    return {"ok": True, "coste_eur": round(coste, 2)}

Devolver ok: false con un mensaje en vez de lanzar una excepción permite al modelo entender el error y rectificar.

Herramientas en Strands: la API @tool

En Strands, una función Python con el decorador @tool se convierte en herramienta: el docstring se usa como descripción y los type hints y la sección Args generan el esquema. Si la función devuelve un diccionario con status y content, Strands lo pasa tal cual como toolResult; cualquier otro valor lo serializa como resultado correcto. Si los parámetros no cumplen el esquema o la función lanza una excepción, Strands devuelve al modelo un resultado con status: error. Esto es lo que la guía llama «using the Strands API to implement custom behaviors».

Model Context Protocol (MCP)

Qué problema resuelve

Sin un estándar, cada framework define herramientas a su manera y cada integración (Jira, una base de datos, tu API) se reescribe para cada agente. MCP (Model Context Protocol) es un protocolo abierto que estandariza cómo una aplicación de IA descubre y usa herramientas y datos externos. Escribes un servidor MCP y cualquier cliente MCP (Strands, Kiro, AgentCore, IDEs…) puede usarlo.

Arquitectura

flowchart LR
    subgraph Host["Host: aplicación de IA (agente, IDE)"]
        C1["Cliente MCP 1"]
        C2["Cliente MCP 2"]
    end
    C1 -->|"JSON-RPC (stdio)"| S1["Servidor MCP local: documentación de AWS"]
    C2 -->|"JSON-RPC (Streamable HTTP)"| S2["Servidor MCP remoto: API de pedidos"]
    S2 --> API["Sistema interno"]

• Host: la aplicación que usa el modelo. Cliente: el conector dentro del host (uno por servidor). Servidor: expone capacidades.
• Mensajes JSON-RPC 2.0. La especificación vigente a octubre de 2026 es la versión 2026-07-28.
• El servidor ofrece tres primitivas: Tools (funciones que el modelo ejecuta), Resources (datos de contexto) y Prompts (plantillas). El cliente puede ofrecer, por ejemplo, elicitation (el servidor pide datos al usuario).
• Transportes habituales: stdio (proceso local, típico en IDEs y desarrollo) y Streamable HTTP (servidor remoto, típico en producción).
• La especificación insiste en seguridad: consentimiento del usuario antes de invocar herramientas y tratar como no confiables las descripciones de herramientas de servidores desconocidos.

MCP en AWS (skill 2.1.7)

Así se conecta Strands a un servidor MCP (ejemplo del README oficial del SDK):

from mcp import stdio_client, StdioServerParameters
from strands import Agent
from strands.tools.mcp import MCPClient

aws_docs_client = MCPClient(
    lambda: stdio_client(StdioServerParameters(command="uvx", args=["awslabs.aws-documentation-mcp-server@latest"]))
)

with aws_docs_client:
    agent = Agent(tools=aws_docs_client.list_tools_sync())
    response = agent("Tell me about Amazon Bedrock and how to use it with Python")

MCP también sirve para recuperación: la skill 1.5.6 habla de «MCP clients for vector queries». Un servidor MCP que envuelve tu Knowledge Base da a cualquier agente un acceso estándar a la búsqueda vectorial.

Strands Agents

Qué es

Strands Agents es un SDK open source de AWS (Python y TypeScript, licencia Apache 2.0) para construir agentes con un enfoque model-driven: tú das modelo, instrucciones y herramientas, y el propio modelo dirige el bucle. Datos verificados a octubre de 2026:

• Paquete PyPI strands-agents (versión 1.57.1, requiere Python 3.10 o superior); herramientas de ejemplo en strands-agents-tools.
• El código vive en el monorepositorio strands-agents/harness-sdk, que incluye también el Strands harness (strands-harness): un agente ya ensamblado con valores por defecto, para cuando no quieres montar el bucle tú.
• Proveedor por defecto: Amazon Bedrock (BedrockModel), pero es multiproveedor (Anthropic, OpenAI, Gemini, Ollama, LiteLLM, SageMaker…).
• Incluye de serie: herramientas con @tool, clientes MCP, hooks (interceptar el ciclo de vida), límites por invocación (turnos y tokens), interrupciones para human-in-the-loop, gestores de conversación y de sesión, patrones multiagente (agents-as-tools, swarm, graph, workflow, A2A), streaming y trazas OpenTelemetry.

Un agente completo en pocas líneas

from strands import Agent, tool
from strands.models import BedrockModel

@tool
def calcular_envio(peso_kg: float, modalidad: str = "estandar") -> dict:
    """Calcula el coste de envío en euros de un paquete.

    Args:
        peso_kg: Peso del paquete en kilogramos. Debe ser mayor que 0 y como máximo 30.
        modalidad: Modalidad de envío: "estandar" o "urgente".
    """
    if not 0 < peso_kg <= 30:
        return {"status": "error", "content": [{"text": "peso_kg debe estar entre 0 y 30"}]}
    base, por_kg = (9.0, 1.1) if modalidad == "urgente" else (4.0, 0.6)
    return {"coste_eur": round(base + por_kg * peso_kg, 2)}

modelo = BedrockModel(
    model_id="eu.amazon.nova-lite-v1:0",   # perfil de inferencia EU
    region_name="eu-central-1",
    temperature=0.2,
    max_tokens=800,
)

agente = Agent(
    model=modelo,
    system_prompt="Eres el asistente de envíos de una tienda online. No inventes precios.",
    tools=[calcular_envio],
    callback_handler=None,   # sin impresión en streaming por consola
)

resultado = agente("¿Cuánto cuesta enviar 2,5 kg por urgente?", limits={"turns": 5})
print(resultado.stop_reason, str(resultado))
print(resultado.metrics.accumulated_usage)   # inputTokens, outputTokens, totalTokens

Puntos que conviene retener:

• limits={"turns": 5} es una condición de parada: si se alcanza, el agente termina con stop_reason = "limit_turns". También existen output_tokens y total_tokens como presupuestos.
• resultado.stop_reason puede ser, entre otros, end_turn, max_tokens, guardrail_intervened, interrupt o los de límite.
• resultado.metrics da ciclos, uso de tokens y estadísticas por herramienta (llamadas, errores, tiempo): base de la observabilidad de herramientas (skill 4.3.4).
• Si no pasas model, el SDK usa por defecto un modelo Claude Sonnet de Bedrock y, si no encuentra región configurada, us-west-2. En Europa indica siempre el modelo (con perfil eu. si tienes requisitos de residencia) y la región.

Memoria y sesiones en Strands

• Corto plazo: el objeto Agent guarda los mensajes. Un conversation_manager controla el crecimiento: SlidingWindowConversationManager(window_size=20) conserva los últimos mensajes; también hay uno que resume.
• Persistencia de sesión: un session_manager guarda el historial fuera del proceso (por ejemplo, en S3 o en AgentCore Memory) para retomar la conversación en otro contenedor.
• Largo plazo: integración con AgentCore Memory como gestor de sesión.

Hooks: comportamiento a medida

Los hooks te dejan ejecutar código en eventos del ciclo de vida: BeforeInvocationEvent, BeforeModelCallEvent, BeforeToolCallEvent, AfterToolCallEvent, etc. Sirven para registrar métricas, validar o modificar parámetros de herramientas, cancelar una llamada (event.cancel_tool) o pedir aprobación humana (event.interrupt(...)). Lo usarás en el lab 09.

Multiagente en Strands

from strands import Agent

agente_envios = Agent(
    name="agente_envios",
    description="Responde preguntas sobre plazos y costes de envío.",
    system_prompt="Eres experto en logística.",
)
agente_devoluciones = Agent(
    name="agente_devoluciones",
    description="Gestiona dudas sobre devoluciones y reembolsos.",
    system_prompt="Eres experto en devoluciones.",
)

supervisor = Agent(
    system_prompt="Deriva cada pregunta al especialista adecuado y combina sus respuestas.",
    tools=[agente_envios, agente_devoluciones],   # agents-as-tools
)

Sistemas multiagente y coordinación de modelos (skills 2.1.1 y 2.1.4)

Arquitecturas multiagente

flowchart TD
    U["Usuario"] --> S["Agente supervisor"]
    S --> A1["Especialista: facturación"]
    S --> A2["Especialista: logística"]
    S --> A3["Especialista: técnico"]
    A1 --> S
    A2 --> S
    A3 --> S
    S --> R["Respuesta agregada"]

• Supervisor u orquestador: un agente planifica y delega; los especialistas no hablan entre sí. Fácil de razonar y de auditar.
• Router o clasificador: una capa ligera decide a qué agente va cada mensaje; el agente elegido responde directamente. Barato y rápido (es lo que hace Agent Squad).
• Red o swarm: los agentes se pasan el control. Flexible, más difícil de depurar.
• Jerárquico: supervisores de supervisores para dominios grandes.

Costes a vigilar: cada agente añade llamadas al modelo (tokens y latencia), y el contexto compartido crece. Mide la coordinación con trazas (AgentCore Observability) y evalúa con AgentCore Evaluations (módulo 10).

Agent Squad

Agent Squad (antes Multi-Agent Orchestrator) es un framework open source para Python y TypeScript que enruta cada petición al agente más adecuado mediante un clasificador que mira la descripción de cada agente y el historial, y mantiene el contexto de la conversación entre agentes. Trae agentes preconstruidos (Bedrock, Lex, Lambda, Anthropic, OpenAI…) y un SupervisorAgent que coordina un equipo en paralelo con el patrón agent-as-tools. La guía lo nombra junto a Strands («Strands Agents and AWS Agent Squad for multi-agent systems»).

Coordinación de modelos (skill 2.1.4)

No todo son agentes: a veces coordinas modelos.

Amazon Bedrock ofrece además Intelligent Prompt Routing (enrutado entre modelos de una familia según la petición; lo verás en el módulo 09).

Amazon Bedrock AgentCore, componente a componente

La idea

Construir el bucle de un agente es fácil; llevarlo a producción no: aislamiento entre usuarios, escalado, memoria duradera, identidad y credenciales para llamar a terceros, control de qué herramientas puede usar, trazas y evaluación. Amazon Bedrock AgentCore es la plataforma de AWS que resuelve esas piezas como servicios modulares que funcionan juntos o por separado, con cualquier framework (Strands, LangGraph, CrewAI, LlamaIndex, Google ADK, OpenAI Agents SDK…) y cualquier modelo (de Bedrock o de fuera).

flowchart LR
    Cli["Cliente (app, API)"] -->|"Identity: IAM SigV4 u OAuth"| RT["AgentCore Runtime (microVM por sesión)"]
    RT --> MOD["Modelo (Bedrock u otro proveedor)"]
    RT --> MEM["AgentCore Memory"]
    RT -->|"MCP"| GW["AgentCore Gateway"]
    GW --> POL["Policy (Cedar): permitir o denegar cada llamada"]
    POL --> L["Lambda"]
    POL --> O["APIs OpenAPI / Smithy / API Gateway"]
    POL --> MS["Servidores MCP"]
    RT --> CI["Code Interpreter"]
    RT --> BR["Browser"]
    RT -.->|"OpenTelemetry"| OBS["Observability (CloudWatch)"]
    OBS -.-> EV["Evaluations"]

Los componentes y cuándo usar cada uno

Runtime en detalle

Datos verificados en la documentación:

• Cada sesión (runtimeSessionId) corre en una microVM dedicada con CPU, memoria y sistema de ficheros aislados. Al terminar, la microVM se destruye y la memoria se sanea: no hay contaminación entre sesiones.
• Una sesión puede durar hasta 8 horas y termina por inactividad a los 15 minutos. Las operaciones asíncronas largas también llegan a 8 horas.
• Cada actualización crea una versión inmutable; el endpoint DEFAULT apunta a la última y puedes crear endpoints propios (dev, test, prod) que apunten a versiones concretas: despliegue controlado y rollback.
• Autenticación de entrada: IAM (SigV4) u OAuth 2.0 (JWT de tu proveedor de identidad). Salida: OAuth o API keys vía AgentCore Identity.
• Contrato HTTP: tu contenedor expone POST /invocations y GET /ping. El SDK bedrock-agentcore lo hace por ti con BedrockAgentCoreApp y el decorador @app.entrypoint.
• Despliegue: la AgentCore CLI (npm install -g @aws/agentcore; comandos agentcore create, dev, deploy, invoke, status, logs, remove) empaqueta el código como zip (CodeZip, sin Docker) o como contenedor, y aprovisiona con AWS CDK. También puedes usar la API CreateAgentRuntime con una imagen de ECR.
• Facturación por consumo (vCPU-hora y GB-hora de uso activo). Estimación a 1/10/2026 en eu-central-1: 0,0895 USD por vCPU-hora y 0,00945 USD por GB-hora (precios de AgentCore).

Memory en detalle

• Corto plazo: cada interacción se guarda como evento (CreateEvent) asociado a un sessionId (y a un actor). Se recupera con ListEvents; admite metadatos para filtrar.
• Largo plazo: un proceso asíncrono extrae y consolida información de los eventos en registros de memoria, recuperables con búsqueda semántica (RetrieveMemoryRecords). Lo que se extrae lo deciden las estrategias:
  • Integradas (built-in): semántica (hechos y conocimiento), preferencias de usuario, resumen y episódica (episodios con reflexión entre ellos).
  • Integradas con override: cambias los prompts de extracción manteniendo el pipeline gestionado.
  • Autogestionadas (self-managed): tú controlas extracción y consolidación.
• Sin estrategias, no se genera memoria a largo plazo.

Gateway en detalle

• Tres categorías de destinos (targets): MCP (agrega Lambda, etapas de API Gateway REST, esquemas OpenAPI, modelos Smithy, servidores MCP, plantillas de integraciones y conectores en un único servidor MCP virtual), HTTP (paso directo, incluido tráfico A2A) e inferencia (enruta peticiones de modelos entre proveedores).
• Autenticación de entrada (quién puede usar el gateway) y de salida (credenciales hacia cada herramienta: IAM, OAuth, API key), con renovación de tokens.
• Selección semántica de herramientas: el agente busca la herramienta adecuada entre miles sin meterlas todas en el prompt.
• Se integra con Policy y con Bedrock Guardrails para aplicar controles a nivel de agente.
• Precio estimado (eu-central-1, 1/10/2026): 5 USD por millón de invocaciones.

Regiones y cuenta

• En eu-central-1 (Fráncfort) y eu-west-1 (Irlanda) están disponibles Harness, Runtime, Memory, Gateway, Identity, herramientas integradas, Observability, Policy y Evaluations. En eu-south-2 (España) hay Runtime, Gateway, Identity, herramientas integradas, Observability, Policy y Evaluations, pero no Memory ni Harness. Registry, en la UE, solo en Irlanda. Consulta la tabla de regiones antes de diseñar.
• La cuenta debe estar en plan de pago (Paid plan).

Bedrock Agents «Classic» (para el examen)

Qué era y qué estado tiene

Amazon Bedrock Agents (lanzado en noviembre de 2023) fue el servicio gestionado de agentes de Bedrock. Desde el 30/07/2026 se llama Agents Classic y está en modo mantenimiento:

• Los agentes existentes siguen funcionando y todas las APIs (InvokeAgent, UpdateAgent, alias, action groups…) siguen disponibles para quien ya lo usaba.
• Las cuentas sin actividad de Bedrock Agents en los últimos 12 meses reciben AccessDeniedException (HTTP 403) al llamar a CreateAgent o InvokeInlineAgent. No hay proceso de excepción.
• El catálogo de modelos de Agents Classic está congelado; no tendrá funciones nuevas. No hay fecha de fin de vida ni plazo obligatorio de migración.
• Agents Classic no tiene cargo propio: se paga el modelo y los recursos asociados.
• Migración recomendada: AgentCore Harness (lo más parecido) o agentes en código en AgentCore Runtime para orquestación avanzada o multiagente. La AgentCore CLI puede importar la configuración de un agente Classic.

Conceptos de Agents Classic que pueden salir

Equivalencias con AgentCore

Human-in-the-loop (skill 2.1.5)

Human-in-the-loop (HITL, persona en el circuito) significa que una persona revisa, aprueba o corrige en momentos concretos. Se usa cuando la acción es irreversible o cara (reembolsos, borrados), cuando la confianza del modelo es baja o cuando la normativa lo exige.

Patrones

Aprobación con Step Functions y task token

sequenceDiagram
    participant SF as Step Functions
    participant L as Lambda notificar
    participant P as Revisor (app interna)
    participant API as API Gateway + Lambda
    SF->>L: lambda:invoke.waitForTaskToken (con la propuesta y el token)
    L->>P: Notificación (SNS, correo, cola de tareas)
    Note over SF: Ejecución en pausa (hasta el TimeoutSeconds del estado)
    P->>API: POST /aprobar con decisión y token
    API->>SF: SendTaskSuccess o SendTaskFailure
    SF->>SF: Continúa: ejecutar acción o rechazar

{
  "PedirAprobacion": {
    "Type": "Task",
    "Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken",
    "Parameters": {
      "FunctionName": "notificar-revisor",
      "Payload": { "propuesta.$": "$.propuesta", "taskToken.$": "$$.Task.Token" }
    },
    "TimeoutSeconds": 86400,
    "Catch": [ { "ErrorEquals": ["States.Timeout"], "Next": "RechazarPorTiempo" } ],
    "Next": "EjecutarAccion"
  }
}

La ejecución espera sin coste de cómputo hasta que alguien llama a SendTaskSuccess (o SendTaskFailure) con el token. API Gateway es la puerta para que la interfaz del revisor envíe la decisión y también para recoger valoraciones de usuarios (skill 2.1.5: «API Gateway to implement feedback collection mechanisms»).

Aprobación dentro del agente (Strands)

En Strands, un hook sobre BeforeToolCallEvent puede llamar a event.interrupt(...). El agente se detiene con stop_reason = "interrupt" y devuelve las interrupciones pendientes; tu aplicación recoge la decisión y vuelve a invocar al agente con las respuestas. Si se rechaza, el hook pone event.cancel_tool y el modelo recibe un resultado de error. Es el patrón del lab 09.

Límites de seguridad de los agentes (skill 2.1.3)

Un agente es un programa que decide solo. Hay que ponerle barreras, y las que valen son las deterministas, fuera del modelo.

Circuit breaker, en concreto

stateDiagram-v2
    [*] --> Cerrado
    Cerrado --> Abierto: N fallos seguidos
    Abierto --> SemiAbierto: pasa el tiempo de espera
    SemiAbierto --> Cerrado: la llamada de prueba funciona
    SemiAbierto --> Abierto: la llamada de prueba falla

Con el circuito abierto, el agente no llama a la herramienta: usa una respuesta degradada («ahora no puedo consultar pedidos; te aviso por correo») o una herramienta alternativa. En Step Functions se implementa leyendo el estado del circuito de DynamoDB antes de la tarea y actualizándolo en el Catch. La guía cita este patrón también en la skill 1.2.3 (resiliencia).

Observabilidad y evaluación de agentes (avance)

Lo verás a fondo en los módulos 09 y 10, pero conecta ya las piezas:

• Trazas: cada turno, llamada al modelo y llamada a herramienta como span de OpenTelemetry. AgentCore Observability las muestra en CloudWatch; Strands las emite de serie; en Agents Classic, la trace del agente.
• Métricas de herramientas: número de llamadas, errores, latencia, tasa de éxito (skill 4.3.4, tool calling observability).
• Evaluación: tasa de tareas completadas, precisión en la elección de herramientas y sus parámetros, calidad del razonamiento (skill 5.1.7). AgentCore Evaluations usa LLM-as-a-judge sobre trazas.
• Transparencia: mostrar al usuario el razonamiento resumido y las fuentes (skill 3.4.1).

Trampas típicas del examen

• «Bedrock Agents» en un diseño nuevo: si el enunciado es de una cuenta nueva o un proyecto nuevo, la respuesta moderna es AgentCore. Si el enunciado describe un agente Classic existente (action groups, alias, trace), razona con sus conceptos.
• Agente cuando basta un workflow: pasos fijos y auditables → Step Functions o Bedrock Flows. Un agente añade coste y no determinismo.
• Controles en el prompt: «decirle al modelo que no borre nada» no es un control. IAM, Policy, límites y aprobación humana sí.
• Memoria mal ubicada: el historial de la sesión en Runtime es efímero; la memoria duradera va en AgentCore Memory (o DynamoDB). Guardar historiales enormes y reenviarlos enteros agota la ventana de contexto.
• Lambda para todo: una herramienta con estado, conexiones persistentes o ejecución larga (más de 15 minutos, el máximo de Lambda) va mejor en ECS o en AgentCore Runtime.
• MCP frente a Gateway: MCP es el protocolo; AgentCore Gateway es un servicio que expone tus APIs como servidor MCP gestionado, con autenticación y políticas.
• Identity frente a IAM: IAM controla qué puede hacer el rol del agente en AWS; AgentCore Identity gestiona credenciales de terceros (OAuth, API keys) y la identidad del usuario final que invoca al agente.
• Multiagente por defecto: más agentes = más tokens, más latencia, más puntos de fallo. Solo si hay especialización real o paralelismo.
• Human-in-the-loop con polling: la forma nativa de «esperar a una persona» en Step Functions es el task token (.waitForTaskToken), no un bucle que consulta una tabla.
• Strands no es un servicio: es un SDK. Se ejecuta donde lo despliegues (Lambda, ECS, EKS, AgentCore Runtime).

Resumen

• Un agente es un FM en bucle que razona, llama a herramientas y observa resultados hasta cumplir un objetivo, con memoria y límites.
• ReAct es el patrón base; Step Functions lo implementa con estados, reintentos, timeouts y un contador como condición de parada.
• Elige workflow si los pasos son fijos, agente si la ruta depende de lo que se descubre, multiagente solo si hay especialización real.
• Herramientas fiables: esquemas estrictos, validación, errores útiles, resultados pequeños, timeouts e idempotencia.
• MCP estandariza herramientas: Lambda para servidores ligeros, ECS para complejos, AgentCore Gateway para exponer APIs existentes con autenticación y políticas.
• Strands Agents: SDK open source de AWS; @tool, BedrockModel, hooks, límites, interrupciones y patrones multiagente.
• AgentCore: Harness (sin código), Runtime (microVM por sesión, hasta 8 h), Memory, Gateway, Identity, Code Interpreter, Browser, Observability, Evaluations, Policy. Exige plan de pago.
• Agents Classic está en mantenimiento (cerrado a clientes nuevos desde el 30/07/2026); conoce sus conceptos y su equivalencia en AgentCore.
• Human-in-the-loop: task tokens de Step Functions, interrupciones de Strands, return of control; API Gateway para decisiones y feedback.
• Las barreras que cuentan son deterministas: IAM de mínimo privilegio, Policy, límites, timeouts, circuit breakers y aprobación humana.

Cobertura del temario

Practica lo aprendido

Documentación oficial para ampliar

• What is Amazon Bedrock AgentCore?
• Get started with the AgentCore CLI
• AgentCore Runtime (microVMs, sesiones, versiones)
• AgentCore Gateway
• AgentCore Memory (tipos y estrategias)
• Policy in Amazon Bedrock AgentCore
• Amazon Bedrock Agents Classic maintenance mode
• Strands Agents (documentación)
• Strands Agents (repositorio harness-sdk)
• Model Context Protocol (especificación)
• Servidores MCP oficiales de AWS
• Agent Squad
• AWS Step Functions – esperar una respuesta con task token