Managed agents vs self-hosted, cuándo cada uno tiene sentido

Desde el 23 de abril de 2026, "Memory for Managed Agents" en Anthropic está en public beta. Es el paso directo de Anthropic a una plataforma hosted para agent workers, con virtualización de session, harness y sandbox como servicios desacoplados. Hasta ahora tenías que hostear eso tú: postgres propio, memory server propio, container runner propio. Ahora va as-a-service.

Eso plantea una pregunta que como operator tendrás que responder en algún momento: ¿hosted o self-hosted?

En esta lesson aprendes cuándo tiene sentido cada uno, cuáles son los trade-offs reales, y cómo documentas una decisión que puedas seguir entendiendo en dos años.

Qué es realmente Managed Agents de Anthropic

Tres servicios desacoplados:

• Session service. Estado de conversación y memoria, persistente entre sesiones. Lo que en tu lado sería una tabla de postgres corre aquí en infraestructura de Anthropic.
• Harness service. Lo que ejecuta el agent: hacer tools disponibles, conectar MCP servers, comprobar permissions.
• Sandbox service. Ejecución de código en entorno aislado. En vez de que tú construyas containers Docker y daemons, mandas código bash al sandbox y recibes el resultado.

Más un token vault para secrets. Significa: ya no tienes que gestionar API keys en containers ni montar lookups de vault. Le das tus secrets a Anthropic una vez, el sandbox service los recibe en runtime.

Pricing: en beta es parte de Max Plan, después probablemente per-sandbox-hour. Las condiciones exactas aún no son públicas.

Cuándo tiene sentido hosted (Managed Agents)

Cuando eres el constructor, no la persona devops. Construyes una tool, no quieres gestionar a la vez un cluster de postgres. Hosted te quita las preguntas de infra.

Cuando validas un prototipo. Más rápido empezar, menos setup. Si el prototipo falla, no has montado infraestructura que ahora tienes que desmontar.

Cuando tu caso de uso no tiene un requisito duro de data sovereignty. Tools B2C, automatización de marketing, asistentes personales. Los datos pueden ir a US cloud, sin bloqueo de compliance.

Cuando la latencia es primaria y no quieres optimizar tú. Anthropic tiene edge locations mundiales; self-hostear en Frankfurt significa 200ms round-trip si un usuario accede desde Australia.

Cuando tienes pocos MCP servers custom. Hosted soporta los MCPs estándar out-of-the-box (GitHub, Slack, Notion etc.). Tu propio MCP interno también va, pero entonces necesitas además una URL pública con auth.

Cuándo tiene sentido self-hosted

Cuando data sovereignty es un requisito duro. Residencia de datos UE para datos GDPR-sensibles, auditorías de la Bundesnetzagentur alemana, healthcare, mandatos legales. Anthropic-hosted es US cloud, eso no es legalmente viable para muchas PYMEs.

Cuando tus casos de uso son muy custom. Necesitas diez MCP servers propios que van todos contra tus APIs internas, con patterns de auth que hosted no conoce. Self-hosted te da la libertad de definir todo tú.

Cuando quieres mantener control de coste. En volúmenes grandes un postgres operado por ti puede ser significativamente más barato que pricing per-session de un servicio managed. Pero: lo pagas con tiempo devops.

Cuando tienes requisitos de air-gap. Algunos setups enterprise no permiten cloud calls desde sistemas de producción. Self-hosted es la única opción.

Cuando quieres customizing profundo. Estrategias de memoria propias, funciones de decay propias, embedding models propios. Eso no va en hosted, o solo limitado.

La variante híbrida (a menudo la respuesta correcta)

En la práctica la respuesta rara vez es "todo hosted" o "todo self-hosted", sino híbrido:

• Hosted para casos estándar. Día a día, marketing, asistentes genéricos. Iteración rápida, sin mantenimiento de infra.
• Self-hosted para casos sensibles. Datos de clientes, reportes financieros, contenido legal. Servidores UE, base de datos de memoria propia, container runner propio.

En StudioMeyer hacemos exactamente eso: SaaS memory server (memory.studiomeyer.io) es hosted, pero nuestros agents internos (Academy Fleet, MCP SaaS Fleet) corren en setup de containers propio con postgres propia, porque ahí se juntan datos internos y datos de clientes.

Decision framework

Si no estás seguro, pasa estas cinco preguntas:

1. Data sovereignty: ¿Tienen los datos que quedarse en UE/Alemania? Si sí → self-hosted o proveedor EU-hosted.
2. Compliance: ¿GDPR-sensible, health/legal/finance, BaFin-relevante? Si sí → self-hosted o enterprise plan con DPA.
3. MCPs custom: ¿Tienes más de dos MCP servers propios corriendo internamente? Si sí → self-hosted es más simple.
4. Capacidad devops: ¿Tienes a alguien que mantiene un cluster de postgres y testea disaster recovery? Si no → hosted.
5. Volumen + control de coste: ¿Más de 1000 sessions/día? Si sí → self-hosted sale más barato a partir de un umbral.

Si dices "sí" a 2 o 3 de estas → self-hosted o híbrido. Si no → empieza hosted, migra después si hace falta.

Camino de migración

Importante: puedes migrar de hosted a self-hosted, pero es trabajo. Anthropic Managed Agents guarda memoria en su formato, tienes que exportarlo y convertirlo a tu propio formato. Planea al menos una semana si te lo tomas en serio.

Al revés (self-hosted a hosted) tiende a ser más fácil porque Anthropic ofrece import tools. Pero eso tampoco es esfuerzo cero.

Qué tienes ahora

Una imagen clara de qué significa hosted vs self-hosted, cuándo tiene sentido cada uno, y un decision framework para tu propia arquitectura. Importante: no es una pregunta religiosa sino una decisión guiada por casos de uso que puede cambiar con el tiempo.

Además: el 80 por ciento de los clientes de StudioMeyer va híbrido. Hosted cuando es rápido, self-hosted cuando es sensible. Esa solución del 80 por ciento suele ser la correcta.

Siguientes pasos

Capstone del Nivel 5 es tu caso de prueba. Construye un setup multi-agent para un caso de uso a tu elección, documenta si tomas hosted o self-hosted y por qué. Si lo escribes en vez de solo pensarlo, tienes una base de decisión para refactoring posterior.