AgentCore en GA en Bedrock: el centro de gravedad se desplaza del chat al runtime
Seis comunicados de AWS en tres días describen la misma arquitectura desde seis ángulos diferentes. Amazon Bedrock AgentCore está en disponibilidad general, y los componentes para sacar un agente fuera de la demostración están todos ahí: un MCP bridge que conecta agentes en la nube con herramientas locales en el laptop, memoria persistente entre sesiones, un nodo para n8n que construye workflows agentivos sin escribir código, y Web Search nativa dentro de Bedrock para el grounding sin proveedores externos.
Para quien intenta hacer funcionar un agente en tareas reales, lo que importa es el cambio de perspectiva. La pregunta central se desplaza hacia cómo orquestar quién hace qué. Elegir el modelo pasa a segundo plano. El agente se convierte en un proceso con estado, herramientas, aislamiento y observabilidad. AWS reúne estos componentes en una plataforma única, y lo hace la misma semana en que Cloudflare construye su runtime para agentes. Dos proveedores con infraestructuras diferentes, mismo diseño.
Los casos de uso publicados son concretos. Mobileye desplegó un agente de soporte técnico que conecta sistemas on-prem con la nube. LendingTree tiene tres agentes coordinados que guían a los clientes en hipotecas respetando el cumplimiento financiero. Son producciones reales, con números y restricciones auténticas detrás.
En detalle
El agente que probaste en chat, el que responde bien si le das el prompt correcto, tiene un problema estructural cuando lo llevas a producción: pierde el estado entre una llamada y otra, no recuerda qué hizo, no tiene un lugar seguro para ejecutar código, y cada herramienta que le añadas es una integración que escribir a mano. AgentCore intenta resolver estos problemas en el mismo lugar.
Memoria persistente. El agente guarda el estado entre sesiones. Si ayer analizó un documento y hoy le pides una continuación, no empieza desde cero. Es la diferencia entre un asistente que funciona y uno que reinicia cada vez.
MCP bridge para herramientas locales. El Model Context Protocol, del que contamos la actualización a 2.0, es el estándar para conectar agentes a herramientas. El bridge de AWS resuelve un problema concreto: el agente corre en la nube, pero tus archivos y herramientas están en el laptop. La solución es un túnel WebSocket firmado que pasa por una extensión del navegador, sin abrir puertos ni configurar VPN.
n8n como frontend visual. El nodo open source para n8n convierte AgentCore en un paso dentro de un workflow visual. Memoria, herramientas reales, ejecución de código e aislamiento VPC se configuran desde el editor, sin código de infraestructura. Para quien no desarrolla, significa construir un agente arrastrando bloques.
Web Search nativa. Bedrock ahora tiene búsqueda web integrada del lado del servidor. El grounding del modelo en fuentes actuales se convierte en una capacidad de la plataforma, sin incorporar un proveedor tercero ni gestionar APIs externas.
Qué dicen los casos reales. Mobileye conecta sistemas on-prem con AWS para soporte técnico, manteniendo gobernanza empresarial. LendingTree usa tres agentes coordinados con LangGraph y MCP para hipotecas, con guardrails integrados para cumplimiento financiero. El tercer caso, extracción automática de insights de la web, combina AgentCore Browser, OpenSearch y Lambda para monitorear feeds RSS y hacer buscables los insights extraídos.
Limitaciones. Estos son posts del blog de AWS: describen la arquitectura en sus partes mejores. El lock-in es real, una vez construido sobre AgentCore cambiar de proveedor significa reescribir la orquestación. El MCP bridge es elegante pero añade complejidad (extensión del navegador, Chrome native messaging). Y la convergencia con Cloudflare confirma la dirección sin validar los detalles: dos proveedores que convergen en el mismo diseño es una señal fuerte, pero no sustituye la experiencia en el terreno.