--- title: "Managed agents vs self-hosted, cuándo cada uno tiene sentido — StudioMeyer Academy" description: "Anthropic puso Memory for Managed Agents en public beta en abril 2026. ¿Cuándo lo tomas, cuándo self-hosteas?" canonical: "https://studiomeyer.academy/es/lernwege/fuer-entwickler/lektionen/08-managed-agents-vs-self-hosted" language: es image: "https://studiomeyer.academy/og/academy-og-share.png" publisher: "StudioMeyer Academy, https://studiomeyer.academy (llms.txt: https://studiomeyer.academy/llms.txt)" --- 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](https://studiomeyer.academy/es/dashboard/lernen/5/06-capstone) 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. Puedes leer todo libremente. Con una cuenta se guarda tu progreso. [Iniciar sesión](https://studiomeyer.academy/es/login?next=%2Fes%2Flernwege%2Ffuer-entwickler%2Flektionen%2F08-managed-agents-vs-self-hosted) Para desarrolladores · Módulo 1 de 1 ## Para desarrolladores [Volver a la ruta](https://studiomeyer.academy/es/lernwege/fuer-entwickler) ## Tus notas Inicia sesión para guardar tus propias notas sobre esta lección. [Iniciar sesión](https://studiomeyer.academy/es/login?next=%2Fes%2Flernwege%2Ffuer-entwickler%2Flektionen%2F08-managed-agents-vs-self-hosted) ## Sitemap Páginas públicas de este sitio como Markdown: [sitemap](https://studiomeyer.academy/sitemap.md). Punto de entrada curado: [llms.txt](https://studiomeyer.academy/llms.txt), texto completo: [llms-full.txt](https://studiomeyer.academy/llms-full.txt).