Claude Managed Agents self-hosted: agenci na naszym serwerze

Anthropic udostępnił 12 listopada 2026 Claude Managed Agents w wersji self-hosted, czyli całą usługę do uruchomienia na własnej infrastrukturze. Jak czytamy w Claude Release Notes, u nas działa już nie tylko sandbox, ale też serwer, który przechowuje agentów, sesje i ich historię. O dostęp trzeba poprosić opiekuna konta w Anthropic.

Czym to się różni od self-hosted sandboxes?

Self-hosted sandboxes są w becie od 19 maja 2026. Przenoszą do nas tylko miejsce, w którym agent uruchamia komendy i pracuje na plikach. Pętlę agenta, API i zapis sesji nadal prowadzi Anthropic, więc wejścia i wyniki narzędzi i tak trafiają na jego serwery.

Nowa opcja zabiera stamtąd także usługę. Dokumentacja pokazuje to w jednej tabeli:

Opcja	Sandboxy	Usługa	Model
Cloud sandboxes (domyślna)	Anthropic	Anthropic	Anthropic
Self-hosted sandboxes	my	Anthropic	Anthropic
Self-hosted Managed Agents	my	my	Anthropic albo wybrany dostawca

Model zostaje więc w chmurze. To nie jest Claude uruchamiany lokalnie, tylko lokalna „obudowa” agenta: API, pętla i pamięć sesji.

Jak wygląda Claude Managed Agents self-hosted od środka?

Jedno wdrożenie składa się z kilku części:

1. Serwer cma-server wystawia API, prowadzi pętlę agenta i woła model. Nie uruchamia przy tym shella ani narzędzi plikowych agenta.
2. Baza to PostgreSQL 16 lub nowszy. Bez niej serwer trzyma dane w pamięci i restart je kasuje.
3. Workery (komenda ant beta:worker albo worker z SDK) pobierają pracę z serwera i wykonują narzędzia w naszych sandboxach.
4. Do tego dochodzą konsola w przeglądarce, do której logujemy się przez własnego dostawcę tożsamości, oraz CLI administratora cma-server-admin.

API jest takie samo jak w usłudze hostowanej, dlatego SDK i CLI ant działają po wskazaniu adresu naszego serwera.

Na próbę wystarczy jedna maszyna z co najmniej dwoma CPU i Docker Compose. Według quickstartu stack uruchamia serwer, bazę i 10 workerów, a każda sesja dostaje własny kontener. To wariant deweloperski (zwykły HTTP na 127.0.0.1:8400). Na produkcję zalecane są dwa charty Helm i Kubernetes.

Co ciekawe, quickstart zaczyna się od gotowego promptu, którym całą instalację można zlecić Claude Code, a w archiwum każdego wydania jest plik operator-guide.md przeznaczony do przeczytania przez Claude ;)

Dokąd trafiają zapytania do modelu?

Domyślnie do Claude API. Ustawienie inference.provider pozwala to zmienić na Amazon Bedrock, Claude Models on Google Cloud (w wersji zarządzanej przez Google), Microsoft Foundry albo własny gateway modeli. Przy każdej z tych opcji serwer nie potrzebuje klucza Claude API (szczegóły konfiguracji).

Poza naszą sieć wychodzi przy każdym wywołaniu modelu cała dotychczasowa rozmowa, razem z wejściami i wynikami narzędzi. Jeśli dostawcą jest Claude API, dochodzą trzy nagłówki z identyfikatorami sesji, agenta i środowiska. Nie da się ich wyłączyć, a według strony o danych i dostępie służą do przypisywania zużycia.

Na tej samej stronie czytamy, że Anthropic nie ma zdalnego dostępu do serwera ani do jego logów. Sesje leżą w naszej bazie, dopóki sami ich nie usuniemy, a umowa ZDR (zero data retention) obejmuje wywołania modelu tak samo jak inne zapytania do Messages API. W usłudze hostowanej Managed Agents pod ZDR nie podlega, bo transkrypty sesji przechowuje Anthropic.

Na co zwrócić uwagę?

Po pierwsze, na listę braków. Według zestawienia różnic na własnym serwerze nie ma środowisk chmurowych, Files API, scheduled deployments, dreams, webhooków ani gotowych skilli docx, pdf, pptx i xlsx. W orkiestracji wielu agentów zostaje tylko delegowanie do subagentów z listy (od 1 do 20), bez dynamic workflows i advisora. Z usługi hostowanej nic się też nie przenosi, więc agentów, skille i memory stores tworzymy od nowa.

Po drugie, na to, co jest domyślnie wyłączone. Narzędzia web_search i web_fetch trzeba włączyć w ustawieniach serwera, a lista dozwolonych hostów MCP jest na starcie pusta. Przy Bedrocku żadne z tych dwóch narzędzi nie działa, przy Google Cloud działa tylko web_search.

Po trzecie, na bezpieczeństwo, które w całości spada na nas. Narzędzie bash to prawdziwy shell z uprawnieniami procesu workera, a izolację daje dopiero kontener albo VM, w którym worker działa. Jedno wdrożenie obsługuje jednego tenanta na jednym poziomie zaufania, więc kod zaufany i niezaufany wymagają osobnych instalacji. Podstawy opisywałem w przewodniku po bezpieczeństwie agentów AI, a ograniczanie kluczy do własnej sieci przy Claude IP allowlist.

Po czwarte, na dostęp. Archiwum z wydaniem dostaje się tylko przez opiekuna konta, a w Release Notes i w opisie funkcji nie ma mowy o cenie. To oferta dla organizacji, które muszą trzymać historię sesji u siebie albo kierować ruch przez swojego dostawcę chmury. Do własnych eksperymentów prostszą drogą zostaje agent zbudowany na Claude Agent SDK.

FAQ

Czy Claude Managed Agents self-hosted działa bez połączenia z Anthropic?

Serwer łączy się z Anthropic tylko wtedy, gdy dostawcą modelu jest Claude API. Przy Bedrocku, Google Cloud, Foundry albo własnym gatewayu zapytania idą tam, ale nadal do modeli Claude, bo agent wskazuje model po identyfikatorze z Claude API (np. claude-opus-5-5).

Czy do uruchomienia potrzebny jest Kubernetes?

Do testów nie, wystarczy Docker Compose na jednej maszynie. Kubernetes i charty Helm to zalecenie dla wdrożeń produkcyjnych.

Jak dostać dostęp do self-hosted Claude Managed Agents?

Przez opiekuna konta w Anthropic (cytując dokumentację, „contact your Anthropic account team”). Publicznego pobierania nie ma.