Anthropic permite a los clientes alojar Claude Managed Agents en su propia infraestructura

Anthropic lanzó una opción para alojar Claude Managed Agents en infraestructura propia el 12 de noviembre de 2026, lo que permite a los clientes ejecutar el servicio completo y sus entornos aislados en su propia cuenta en la nube o en un centro de datos local. Los agentes, las sesiones y el historial de sesiones se almacenan en esa infraestructura, mientras que las solicitudes a los modelos pueden enviarse al proveedor de inferencia elegido.

Los anteriores entornos aislados autohospedados de Anthropic trasladaban la ejecución de las herramientas de un agente a los sistemas del cliente, mientras Anthropic seguía ejecutando el agente. Las entradas y salidas de las herramientas seguían pasando por Anthropic, que también almacenaba las habilidades y los almacenes de memoria. La nueva opción amplía el control del cliente a la API, el ciclo del agente y el almacenamiento de sesiones.

Qué gestionan ahora los clientes

La arquitectura autohospedada se centra en cma-server, que ofrece la API de Managed Agents, ejecuta el ciclo del agente, almacena los agentes, las sesiones y sus historiales, y se comunica con el proveedor de inferencia configurado. Trabajadores independientes ejecutan las herramientas de shell y de archivos dentro de los entornos aislados de los clientes; el propio servidor nunca ejecuta esas herramientas.

El servidor que ejecuta el cliente ofrece la misma API de Managed Agents que el servicio alojado de Anthropic, salvo por las diferencias de funcionalidad documentadas, por lo que el SDK de Claude y la ant CLI pueden conectarse a él. Para una implementación persistente se necesita PostgreSQL 16 o una versión posterior. Sin una base de datos, el servidor conserva los datos solo en memoria, y un reinicio los borra. Los clientes deben ponerse en contacto con su equipo de cuentas de Anthropic para solicitar la descarga e instalar cada versión por su cuenta.

Opciones de inferencia y límites de los datos

De forma predeterminada, las llamadas a los modelos se envían a la API de Claude. En su lugar, los clientes pueden seleccionar Amazon Bedrock, Claude Models en Google Cloud (gestionados por Google), Microsoft Foundry o una pasarela de modelos que gestionen, mediante la configuración del proveedor del servidor. Los agentes siguen haciendo referencia a los modelos mediante sus ID de la API de Claude, que el servidor traduce para los proveedores que ofrecen esos modelos, lo que permite que una definición de agente funcione sin cambios.

El alojamiento propio del servicio no basta, por sí solo, para mantener el tráfico de los modelos dentro de la red del cliente. Cada llamada a un modelo envía al proveedor de inferencia seleccionado la conversación hasta ese momento, incluidas las indicaciones, las entradas de las herramientas y sus resultados. La documentación de seguridad indica que el servidor solo se conecta a Anthropic cuando la API de Claude es el proveedor seleccionado y que Anthropic no tiene acceso remoto al servidor gestionado por el cliente ni a sus registros.

Migración y límites operativos

La guía de migración indica que no se copia nada del servicio alojado de Anthropic, incluido el historial de sesiones. Los clientes deben volver a crear los agentes, las habilidades, las credenciales de la bóveda y los almacenes de memoria en su propio servidor. Las organizaciones que ya ejecutan entornos aislados autohospedados pueden conectar el mismo software de trabajadores al nuevo servidor, aunque los trabajadores activados por webhooks no funcionarán porque el servidor autohospedado no envía ninguno.

Los clientes también asumen responsabilidades que Anthropic se encarga de gestionar en el servicio alojado: proteger el servidor, alojar los almacenes de memoria, detectar usos inusuales e instalar las versiones. Cada implementación atiende a un único tenant con un único nivel de confianza. Por tanto, los distintos tenants o las cargas de trabajo con niveles de confianza diferentes requieren implementaciones independientes, cada una con sus propias bases de datos, claves de API del servidor y trabajadores.

Algunas funciones del servicio alojado no están disponibles, como las implementaciones programadas, los sueños y los webhooks. Las herramientas de búsqueda web y recuperación web permanecen desactivadas hasta que se habilitan expresamente; a partir de entonces, su disponibilidad depende del proveedor de inferencia. La búsqueda web funciona con la API de Claude, Claude Models en Google Cloud (gestionados por Google) y Microsoft Foundry; la recuperación web funciona con la API de Claude y Microsoft Foundry.

La retención de sesiones también queda a cargo del cliente. Las sesiones y sus historiales permanecen en la base de datos del cliente hasta que se eliminan, en lugar de caducar con el paso del tiempo. Al eliminarlas, se quitan de esa base de datos, pero no se borran las copias incluidas en las copias de seguridad, los registros y trazas exportados, los almacenes de memoria ni, en Kubernetes, el volumen del espacio de trabajo de la sesión.

Por tanto, para los clientes el límite clave tiene dos aspectos: el estado y la ejecución del agente pueden permanecer dentro de su propia implementación, pero cada conversación sigue enviándose al proveedor de inferencia que seleccionen. Este mayor control implica encargarse de proteger y actualizar esa implementación, aislar a los tenants y aceptar las carencias del conjunto de funciones del servicio alojado.