Los módulos 3 a 8 construyeron la plataforma de agentes pieza por pieza: cómputo, red, colas, estado, gateway, freno. Este módulo presenta la alternativa que AWS vende armada: Bedrock AgentCore, la familia de servicios administrados para el corazón agéntico — disponible de forma general desde octubre de 2025 y en evolución rápida, así que este módulo se concentra en la arquitectura de cada pieza (qué problema resuelve, qué acopla) más que en su superficie de API, que cambiará.

La pregunta del módulo no es “¿AgentCore sí o no?” — es más fina: AgentCore es modular, y cada pieza se adopta o no por separado. La decisión build-vs-managed del módulo 4 de Producto se aplica aquí componente a componente.

La tesis del módulo

AgentCore desagrega el harness de un agente — runtime, memoria, acceso a herramientas, identidad, observabilidad — en servicios administrados adoptables por separado, y esa modularidad es la clave de la decisión: no eliges “administrado vs. propio” una vez; lo eliges cinco veces. El criterio en cada pieza es el de siempre: lo administrado compra velocidad y operación a cambio de control y acoplamiento — y las piezas donde tu plataforma se diferencia merecen control, mientras las piezas commodity merecen administración.

El mapa de AgentCore, pieza por pieza

Si conoces las 7 capas del harness, el mapa te resultará familiar — AgentCore es, en buena medida, ese harness vendido como servicios:

Pieza	Qué administra	Su equivalente “propio” en este curso
Runtime	El entorno serverless donde corre el loop del agente: sesiones aisladas, escalado, ciclo de vida	Tu contenedor Fargate + tu loop (módulo 3)
Memory	Memoria de corto plazo (sesión) y largo plazo (entre sesiones) como servicio	Tu DynamoDB de sesiones (módulo 6)
Gateway	Convierte APIs, Lambdas y servicios en herramientas que el agente descubre y llama — hablando MCP, con autorización IAM	Tus servidores MCP como microservicios (módulo 5)
Identity	Identidad para agentes: credenciales, OAuth hacia terceros, API keys administradas	Tu rol por agente + Secrets Manager (módulos 2 y 10)
Herramientas integradas	Code Interpreter (sandbox de código) y Browser (navegador administrado)	Sandboxes propios — caros de hacer bien
Observability	Métricas y trazas del agente listas	Tu CloudWatch/X-Ray (módulo 11)

Desde diciembre de 2025 se suman dos piezas en vista previa: Policy (reglas escritas en lenguaje natural que se traducen a Cedar y se aplican sobre cada llamada a herramienta que pasa por el Gateway — la gobernanza declarativa del módulo 2, ahora en la capa de herramientas) y Evaluations (evaluadores integrados y propios sobre el comportamiento real del agente — lo que el curso de Evals enseña a construir). Por ser vista previa, aquí solo se nombran.

Y al lado, la pieza administrada de RAG: Knowledge Bases — ingesta, chunking, embeddings, vector store (eligiendo el de atrás: OpenSearch, Aurora, S3 Vectors, entre otros — la tabla del módulo 6 sigue mandando) y la API de retrieve/generate. El curso de RAG enseña lo que pasa adentro; aquí la decisión es si operarlo tú o delegarlo.

La decisión, pieza por pieza

Donde lo administrado gana casi siempre:

Las herramientas peligrosas: Code Interpreter y Browser. Un sandbox de ejecución de código o un navegador para agentes hechos bien (aislamiento real, sin fuga al host) son proyectos de seguridad serios — el sandboxing del curso de Seguridad da fe. Comprarlos administrados es comprar exactamente el tipo de ingeniería que no te diferencia y sí te puede hundir. La adopción más fácil de defender del módulo.
Identity para credenciales de terceros. El flujo OAuth del agente hacia Google/GitHub/Salesforce (tokens, refresh, almacenamiento) es plomería de seguridad pura. Administrada, es una categoría de incidentes menos.

Donde la decisión es genuina y depende de tu plataforma:

Runtime. Compra: cero operación del loop, aislamiento por sesión, escalado. Acopla: tu agente corre donde y como el runtime dicta — su contrato de invocación, sus límites (sesiones de hasta 8 horas por defecto), debugging a su manera; el framework, en cambio, es libre: corre cualquier loop empaquetado como contenedor. Si tu loop es estándar (un LangGraph típico), el acoplamiento es barato; si tu harness es tu diferencial (control fino del contexto, patrones propios), el runtime administrado te queda chico. Regla práctica: el runtime administrado para los agentes commodity; el propio para el agente que es tu producto.
Memory. Compra: memoria corta y larga sin diseñar esquemas. Acopla: la forma de recordar de tu agente — qué se guarda, cómo se recupera, cuándo se olvida — queda dentro del servicio. Y la memoria es de las palancas de calidad más finas de un agente (fundamentos de memoria): si la afinas, la quieres tuya; si te basta “que recuerde”, administrada.
Gateway de herramientas. Compra: catálogo central de herramientas con permisos IAM, MCP hablado por ti. Acopla: poco — MCP es estándar abierto, y tus herramientas siguen siendo tus APIs. De las adopciones más baratas de revertir; su valor crece con el número de agentes y herramientas (con 2 agentes y 5 herramientas es prematuro; con 20 y 50 es orden).
Knowledge Bases. Compra: el pipeline RAG entero sin operarlo. Acopla: chunking, estrategia de retrieval y evaluación quedan dentro de lo que el servicio permite afinar. El mismo criterio del runtime: RAG commodity (buscar en manuales) → administrado; RAG que es tu producto (retrieval afinado con evals propias, rag-10) → propio.

   ¿ADMINISTRADO O PROPIO? — POR PIEZA

            ¿la pieza te diferencia?
                      │
        ┌─────── no ──┴── sí ────────┐
        ▼                            ▼
  ¿es peligrosa de           ¿el acoplamiento
  hacer bien? (sandbox,      te deja afinarla
  browser, OAuth)            como necesitas?
        │                            │
   ┌────┴─────┐                 ┌────┴─────┐
   ▼ sí       ▼ no              ▼ sí       ▼ no
 se compra  administrada     híbrido:    PROPIA
 (sin duda) (por defecto,    admin. hoy, (es tu
            revisable)       migrable    producto)

Lo que no cambia con AgentCore

El punto que este módulo necesita clavar: adoptar AgentCore no deroga los módulos 1-8. El agente en Runtime administrado sigue siendo un principal IAM con su rol mínimo (módulo 2 — Runtime ejecuta tu agente con la identidad que tú definiste); su gasto sigue necesitando atribución y freno (módulo 8 — y la letra chica de la atribución por perfil aplica con más razón en capas administradas: verifica en la factura); sus herramientas siguen siendo APIs con contrato y egress controlado (módulos 4-5); su memoria administrada sigue siendo un honeypot que exige política de retención y PII (módulo 6). La responsabilidad compartida del módulo 1, una vez más: el servicio opera la pieza; el comportamiento y sus consecuencias siguen firmados por ti.

Ojo — la velocidad de cambio como criterio propio: AgentCore pasó de anuncio a GA en meses, y sus piezas ganan capacidades por trimestre. Eso corta en dos direcciones: lo que hoy “no da” puede darlo en seis meses (revisita las decisiones “propio” con calendario), y construir tú lo que AWS está claramente a punto de administrar es correr contra la maquinaria. La decisión de este módulo no se toma una vez — se agenda.

Errores comunes

Tratar AgentCore como todo-o-nada. Es modular a propósito: browser administrado + runtime propio + memoria propia es una combinación perfectamente sana. La tabla se recorre pieza por pieza.
Construir el sandbox de código propio. El aislamiento de ejecución hecho a medias es la vulnerabilidad más cara del mundo agéntico. Salvo requisito extraordinario, esta pieza se compra.
Delegar el runtime del agente que es tu producto. Si tu diferencial está en el harness — contexto, patrones, control — el runtime administrado te promedia con el mercado. Lo commodity se delega; el corazón, no.
Creer que administrado = gobernado. Runtime, Memory y Gateway operan la mecánica; permisos, presupuesto, retención y egress siguen siendo tu diseño. Los módulos 1-8 aplican íntegros encima.
Ignorar Knowledge Bases por orgullo de RAG propio. Para el RAG commodity, KB entrega en días lo que operar OpenSearch + pipeline cuesta en meses. El orgullo se reserva para el RAG que de verdad compite.
Decidir una vez y no volver. La frontera administrado/propio de esta categoría se mueve por trimestre. Decisión con fecha de revisión, o decisión vencida.

La frase para llevarse

“AgentCore desagrega el harness en piezas administradas, y la decisión se toma pieza por pieza con una brújula: compra lo peligroso (sandbox, browser, OAuth), delega lo commodity (el runtime del agente estándar), y quédate con lo que te diferencia. Y recuerda: administrado opera la pieza — el comportamiento del agente sigue firmado por ti.”

Qué viene

Módulo 10: seguridad de la plataforma. Las piezas están todas; falta blindarlas como sistema: secretos con Secrets Manager (por qué el agente jamás ve una llave), cifrado con KMS y la decisión de llaves propias, Guardrails de Bedrock para el filtrado administrado de entrada/salida y PII, y las capas de detección — CloudTrail como caja negra inmutable y GuardDuty como vigilante. El módulo donde la landing zone conceptual termina de aterrizar completa en AWS.

Arquitectura AWS — Módulo 9: AgentCore y los agentes administrados