AWS quiere sacar los coding agents de tu laptop: AgentCore Runtime pone cada sesión en una microVM
AWS publicó una guía para alojar Claude Code, Codex, Kiro u otros coding agents en Amazon Bedrock AgentCore Runtime. Para builders, el cambio útil es separar shell, workspace persistente, permisos y observabilidad de la máquina personal.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
AWS publicó el 8 de junio de 2026 una guía con un mensaje simple: tu laptop no debería ser el host natural de un coding agent largo. El artículo explica cómo alojar agentes como Claude Code, OpenCode, Codex, Kiro o Cursor dentro de Amazon Bedrock AgentCore Runtime, con una sesión aislada por agente.
La promesa técnica es concreta. AgentCore Runtime da a cada sesión una microVM Linux dedicada, workspace persistente, shell real y ejecución determinística de comandos. Eso convierte una sesión de agente en algo más parecido a infraestructura de CI que a una terminal abierta en la máquina personal.
Por qué esto importa para builders
Los coding agents ya no solo completan funciones pequeñas. Instalan dependencias, corren tests, editan archivos, levantan servidores locales, navegan previews y dejan pull requests. Si ese trabajo vive en tu laptop, hereda todos los problemas de tu laptop: secretos locales, puertos ocupados, procesos colgados, estado irreproducible y sesiones que mueren cuando cierras la tapa.
El ángulo de AWS es separar el agente de esa fragilidad. AgentCore se presenta como una plataforma para construir, desplegar y operar agentes con permisos, gobernanza, escala y monitoreo. Para un equipo, eso permite correr varias sesiones en paralelo sin que compartan filesystem, shell o credenciales por accidente.
La pregunta práctica no es "¿puedo correr Claude Code en AWS?". La pregunta es: ¿qué contrato necesito para que un agente remoto trabaje como parte de mi pipeline y no como una terminal descontrolada?
El workspace persistente es la pieza delicada
La documentación de AgentCore Runtime incluye configuraciones de filesystem persistente mediante filesystemConfigurations. AWS soporta montajes administrados y opciones como EFS o S3 Files, con montaje automático dentro de la microVM. Eso es útil porque un coding agent necesita más que memoria conversacional: necesita archivos, dependencias, cachés, logs y artefactos entre invocaciones.
Pero persistencia también abre riesgos. Si guardas demasiada basura, el agente arrastra contexto viejo. Si compartes el mismo volumen entre tareas, aparecen colisiones. Si no defines limpieza y retención, el workspace se vuelve otro sistema sin dueño.
Yo probaría este patrón con tres reglas:
- una microVM por tarea o rama;
- secrets entregados por rol, nunca copiados al repo;
- artefactos persistentes solo si ayudan a resumir, testear o auditar.
Cómo decidir si vale la pena
No todos necesitan esto. Si usas un agente para refactors pequeños, un worktree local puede bastar. Si ya estás corriendo tareas de una hora, pruebas E2E, builds pesados o varios agentes al mismo tiempo, mover ejecución a un runtime aislado empieza a tener sentido.
La demanda se infiere por fuentes primarias y señales de comunidad: AWS publicó una guía específica para coding agents, AgentCore documenta runtime y filesystem persistente, y las búsquedas probables incluyen Amazon Bedrock AgentCore coding agents, Claude Code AgentCore, Codex microVM, coding agent persistent workspace y host coding agents.
Agente IA puede competir en español porque el valor no es repetir la arquitectura de AWS. Es traducirla a decisión operativa: cuándo un agente deja de ser una herramienta personal y pasa a necesitar aislamiento, cuotas, logs y recuperación. Para preparar ese contrato desde cero, el curso gratis es el punto de partida.