AWS elimina la infraestructura de agentes, pero el gancho permanece

AWS ha lanzado dos productos que constantemente se meten en el mismo saco: el Agent Toolkit, que pone en manos de un agente de codificación con IA 300 servicios y 15.000 acciones de API, y Bedrock AgentCore, la plataforma de operación con tiempo de ejecución sin servidor para agentes en producción. Ambos ahorran semanas o meses de trabajo de integración. El precio no aparece en la factura, está en la arquitectura.

Lo más importante en resumen

• Dos productos, un malentendido: El Agent Toolkit conecta tu agente de desarrollo con AWS, mientras que AgentCore ejecuta los agentes después en un entorno sin servidor. Si confundes ambos, evaluarás la herramienta incorrecta.
• La base es la verdadera oferta: El aislamiento de sesiones, la memoria, la identidad y la observabilidad suelen ser desarrollados por cada equipo por su cuenta. AgentCore agrupa todo esto en bloques modulares y asume así la parte más tediosa.
• Abierto arriba, vinculado abajo: Frameworks como LangGraph o CrewAI siguen siendo portátiles. La capa de operación por debajo es AWS. Justo ahí surge la vinculación que se notará más adelante.

Relacionado:Cursor Cloud-Agents: Codificar, incluso cuando el portátil está apagado  /  Reserved Instances: La tasa de cobertura que no demuestra nada

Dos herramientas que constantemente se confunden

La mayor confusión en la primera ronda de arquitectura surge porque dos lanzamientos comparten el mismo nombre. Uno se llama Agent Toolkit for AWS y el otro Amazon Bedrock AgentCore. Resuelven problemas diferentes y pertenecen a fases distintas.

¿Qué es el Agent Toolkit for AWS? Un conjunto compuesto por un servidor MCP, habilidades curadas y complementos que proporciona a los agentes de codificación con IA, como Claude Code, Cursor o Codex, un acceso seguro y auditable a AWS. El servidor MCP cubre más de 300 servicios y más de 15.000 acciones de API, a los que se suman scripts ejecutados en entornos aislados y acceso en tiempo real a la documentación actual.

Por tanto, el Toolkit facilita la fase de construcción. Le proporciona al agente que escribe tu código las herramientas para gestionar los registros de CloudWatch, los estados de CloudFormation y los procedimientos de resolución de problemas. No se paga nada extra, solo asumes los recursos de AWS que el agente utilice realmente.

AgentCore comienza donde el Toolkit termina: en el tiempo de ejecución para la operación. Cuando el agente está construido y debe atender sesiones de usuarios, se ejecuta aquí, en un entorno sin servidor, con sesiones aisladas y memoria persistente. Ambos productos juntos forman una cadena desde el primer prompt hasta el tráfico de producción. Evaluados por separado, tienen sentido. Mezclados, dan lugar a una lista de requisitos que no encaja bien en ningún sitio.

Lo que el subsistema le ahorra al desarrollador

La parte más honesta de la oferta es la invisible. Cada equipo que ha lanzado un agente al entorno de producción conoce la lista de cosas que nadie quiere construir, pero que todos deben hacer. AgentCore descompone exactamente esta lista en bloques modulares. Los siete que más marcan el día a día:

• Runtime: entorno sin servidor con baja latencia e隔离 de sesiones, abierto para cualquier framework.
• Memory: contexto temporal por sesión y conocimientos a largo plazo sobre extracción semántica.
• Identity: acceso seguro del agente a AWS y servicios de terceros como GitHub, Salesforce o Slack.
• Gateway: transforma APIs existentes y funciones Lambda en herramientas que el agente puede usar mediante el MCP.
• Observability: visión paso a paso de la ejecución con conexión a OpenTelemetry.
• Browser: instancias gestionadas de navegador para automatización web a gran escala.
• Code Interpreter: entorno aislado para código que genera el propio agente.

Quien ya lo ha hecho a mano ve su valor inmediatamente. El manejo de sesiones, el brokering de identidades y una capa de memoria que no se rompe en cada despliegue, cuesta rápidamente semanas o meses a un pequeño equipo. Ese tiempo rara vez fluye al producto, casi siempre a tareas de mantenimiento. Este playbook para precisamente esa clase de tareas lo hemos escrito demasiadas veces nosotros mismos.

Un ejemplo hace tangible la diferencia. El Gateway toma una función Lambda existente o una API REST interna y la convierte en una herramienta que el agente puede llamar mediante el Protocolo de Contexto del Modelo. Antes eso significaba: crear un adaptador, una descripción de esquema y una capa de autenticación manualmente para cada función. Ahora es simplemente una registro. Puede sonar como un detalle pequeño, pero acumulado en docenas de herramientas equivale exactamente al trabajo que nadie quiere ver en el planificación de sprints. Lo mismo ocurre con Identity: en lugar de almacenar claves para GitHub o Salesforce en variables de entorno, la componente gestiona el acceso en tiempo real. Esto implica menos código y menos superficie de ataque.

Donde está la cuenta: vinculación en lugar de tarifa

El segundo enfoque merece la pena. AWS vende transparencia, y eso es cierto. AgentCore apoya a CrewAI, LangGraph, LlamaIndex, Strands y marcos propios. Tu código de agentes no queda encerrado. Lo que podrías migrar sería la lógica.

Lo que no migras es la capa de infraestructura. Runtime, Gateway, Identity y Memory son propios de AWS. Tan pronto como tu agente funcione sobre ella, la forma en que se despliega, autentica y observa dependerá de este stack. La vinculación está una capa más profunda que el framework, exactamente en la parte que acabas de dejar de lado.

Esto no es un argumento contra AWS. Es el negocio habitual de cualquier plataforma gestionada. La pregunta es solo si se compra la vinculación conscientemente o se recoge como efecto secundario de un prototipo rápido. La diferencia entre ambos es aproximadamente un auditorio completo.

Cuándo vale la pena el salto

Para la mayoría de los equipos que hoy planean su primer agente productivo, el intercambio es justo. Quien aún no opera su propia capa de memoria e identidad gana más tiempo del que pierde en opción. El adelanto cuenta mientras el caso de uso aún no esté probado.

Las cosas cambian cuando Multi-Cloud ya es la norma o cuando la residencia de datos y la soberanía están reguladas con firmeza. Entonces la capa de infraestructura se convierte en una decisión estratégica que no se toma de pasada. En este caso, vale la pena comparar con un autohosting propio del marco antes de que el primer agente productivo se instale en AgentCore.

En la práctica, esto significa: prototipo en el stack gestionado, decisión arquitectónica antes del lanzamiento productivo. Quien utiliza el toolkit para construir y fija la runtime después de una evaluación seria de lock-in, obtiene lo mejor de ambos mundos. Quien invierte el orden deja que el prototipo dicte la arquitectura. Esto funciona bien por un tiempo y se vuelve costoso precisamente cuando menos tiempo se tiene para una migración.

Preguntas frecuentes

Más de la red de MBF Media

Fuente de la imagen: generada por IA (Juli 2026)