Anthropic låter kunder självhosta Claude Managed Agents

Anthropic lanserade självhostade Claude Managed Agents den 12 november 2026, så att kunder kan köra hela tjänsten och dess sandlådor i sitt eget molnkonto eller i ett lokalt datacenter. Agenter, sessioner och sessionshistorik lagras i den infrastrukturen, medan modellförfrågningar kan skickas till en vald inferensleverantör.

Anthropics tidigare självhostade sandlådor flyttade körningen av en agents verktyg till kundernas system, medan Anthropic fortsatte att köra agenten. Indata och utdata från verktygen skickades fortfarande till Anthropic, som också lagrade färdigheter och minneslager. Det nya alternativet ger kunderna kontroll även över API:et, agentloopen och sessionslagringen.

Det här sköter kunderna nu själva

Den självhostade arkitekturen bygger på cma-server, som tillhandahåller Managed Agents API, kör agentloopen, lagrar agenter, sessioner och deras historik samt anropar den konfigurerade inferensleverantören. Separata arbetare kör skal- och filverktyg i kundernas sandlådor; servern kör aldrig dessa verktyg själv.

Den kunddrivna servern exponerar samma Managed Agents API som Anthropics värdtjänst, med undantag för dokumenterade funktionsskillnader, så Claude SDK och ant CLI kan ansluta till den. En driftsättning som bevarar data kräver PostgreSQL 16 eller senare. Utan en databas behåller servern data endast i minnet, och en omstart raderar den. Kunder måste kontakta sitt Anthropic-kontoteam för att begära nedladdningen och själva installera varje version.

Val av inferensleverantör och datagränser

Modellanrop går som standard till Claude API. Kunder kan i stället välja Amazon Bedrock, Claude Models på Google Cloud (hanteras av Google), Microsoft Foundry eller en modellgateway som de själva driver via serverns leverantörsinställningar. Agenter anger fortfarande modeller med deras Claude API-ID:n, som servern översätter för leverantörer som tillhandahåller modellerna. Därmed kan en agentdefinition användas utan ändringar.

Att självhosta tjänsten innebär inte i sig att modelltrafiken stannar inom kundens nätverk. Varje modellanrop skickar den dittillsvarande konversationen, inklusive promptar, verktygsindata och verktygsresultat, till den valda inferensleverantören. I säkerhetsdokumentationen står det att servern bara ansluter till Anthropic när Claude API är den valda leverantören, och att Anthropic inte har fjärråtkomst till den kunddrivna servern eller dess logg.

Migrering och driftsbegränsningar

I migreringsvägledningen står det att ingenting kopieras från Anthropics värdtjänst, inte heller sessionshistoriken. Kunder måste återskapa agenter, färdigheter, autentiseringsuppgifter i valv och minneslager på sin egen server. Organisationer som redan kör självhostade sandlådor kan ansluta samma arbetarprogramvara till den nya servern, men arbetare som aktiveras av webhooks fungerar inte eftersom den självhostade servern inte skickar några sådana.

Kunderna tar också över ansvar som Anthropic sköter för värdtjänsten: att skydda servern, stå för minneslagringen, upptäcka ovanlig användning och installera nya versioner. Varje driftsättning betjänar en enda klient på en enda förtroendenivå. Separata klienter, eller arbetslaster med olika förtroendenivåer, kräver därför separata driftsättningar med egna databaser, API-nycklar för servern och arbetare.

Vissa funktioner i värdtjänsten är inte tillgängliga, däribland schemalagda driftsättningar, dreams och webhooks. Verktygen för webbsökning och webbhämtning är inaktiverade tills de aktiveras uttryckligen, och då beror tillgängligheten på inferensleverantören. Webbsökning fungerar med Claude API, Claude Models på Google Cloud (hanteras av Google) och Microsoft Foundry; webbhämtning fungerar med Claude API och Microsoft Foundry.

Kunderna ansvarar också för sessionslagringen. Sessioner och deras historik ligger kvar i kundens databas tills de raderas i stället för att löpa ut efter en viss tid. Radering tar bort dem från databasen, men inte kopior i säkerhetskopior, exporterade loggar och spårningar, minneslager eller, i Kubernetes, sessionens arbetsytevolym.

För kunderna går den viktiga gränsen alltså i två led: agentens tillstånd och körning kan stanna i den egna driftsättningen, men varje konversation skickas fortfarande till den inferensleverantör de väljer. Den utökade kontrollen innebär också det operativa arbetet med att skydda och uppdatera driftsättningen, isolera klienter och acceptera att vissa funktioner från värdtjänsten saknas.