Konrad Kowalski (rootsher)Principal Platform & Reliability Architect001101101001100011111100001000000100111110001001

Gdy Managed Agents nie wystarczają: platforma do uruchamiania agentów

data
kategoria
AI Agents
także w
AI Engineering · Automation · Engineering Practices
czytanie
2 min / 449 słów

Managed Agents dobrze rozwiązują problem:

text
mam agenta
-> chcę uruchamiać go zdalnie
-> nie chcę utrzymywać własnego runtime'u

Dla wielu zespołów to wystarczy.

Ale w większej organizacji problem może się zmienić.

Nie chodzi już o:

jak uruchomić Claude poza laptopem?

Tylko:

jak uruchamiać agentów zgodnie z zasadami całej naszej platformy?

Masz już:

text
IAM
networking
secrets
observability
logging
deployment standards
security policies
data governance

i nie chcesz budować osobnego świata tylko dla agentów.

Wtedy pojawia się kolejna kategoria narzędzi:

managed agent runtimes / agent platforms

Co daje taka platforma?

Mentalny model:

text
company infrastructure
-> agent runtime
-> agent
-> Claude
-> tools / data / services

Platforma przejmuje odpowiedzialność za rzeczy takie jak:

  • hosting agentów,
  • sessions,
  • scaling,
  • identity i IAM,
  • networking,
  • secrets,
  • observability,
  • governance,
  • integrację z pozostałą infrastrukturą.

Claude nadal odpowiada za reasoning.

Zmienia się głównie miejsce, w którym agent żyje i sposób, w jaki organizacja nim zarządza.

Przykłady narzędzi tej klasy

Do tej kategorii należą m.in.:

  • Google Vertex AI Agent Engine,
  • Amazon Bedrock AgentCore,
  • Microsoft Foundry Agent Service,
  • platformy budowane samodzielnie na Kubernetes / serverless runtimes.

Nie musisz od razu wybierać jednej z nich.

Ważniejsze jest rozpoznanie momentu, w którym Claude-native Managed Agents przestają pasować do wymagań organizacji.

Kiedy Managed Agents wystarczają?

Jeżeli Twój świat wygląda mniej więcej tak:

text
Claude
-> repo
-> tools
-> MCP
-> skills

i potrzebujesz po prostu zdalnego, zarządzanego środowiska dla Claude, Managed Agents są naturalnym wyborem.

Masz mało warstw.

Możesz szybko przejść od:

text
local Claude Code

do:

text
managed execution

bez budowania własnej platformy.

Kiedy zaczynasz patrzeć dalej?

1. Organizacja ma własne standardy platformowe

Na przykład:

text
każdy workload musi używać naszego IAM
wszystkie logi trafiają do jednego systemu
secrets muszą być zarządzane centralnie
network access musi przechodzić przez nasze policies

Agent staje się wtedy kolejnym workloadem infrastruktury.

Nie chcesz wyjątków tylko dlatego, że jest agentem.

2. Chcesz obsługiwać więcej niż jeden model lub framework

Dzisiaj możesz być Claude-first.

Ale platforma organizacji może potrzebować:

text
Claude
inny model
własny agent framework
agent napisany przez inny zespół

Wtedy bardziej neutralny runtime zaczyna mieć sens.

3. Potrzebujesz centralnego governance

Przy kilku agentach można zarządzać wszystkim ręcznie.

Przy kilkudziesięciu zaczynają pojawiać się pytania:

text
kto może uruchomić którego agenta?
do jakich danych ma dostęp?
jakie tools może wykonać?
ile kosztuje?
gdzie są logi?
jak go wyłączyć?

To przestaje być problem jednego developera.

Staje się problem platform engineering.

4. Agent musi mocno integrować się z istniejącym cloudem

Jeżeli agent ma korzystać z:

text
wewnętrznych usług
private networking
service accounts
cloud databases
event bus
secret manager
centralnego observability

uruchamianie go bezpośrednio w tej samej platformie może być prostsze niż budowanie mostów do osobnego runtime'u.

Przykładowa architektura

Claude-first:

text
SDLC event
-> Claude Managed Agent
-> Claude
-> repo / tools

Platform-first:

text
SDLC event
-> company agent platform
-> agent runtime
-> Claude-powered agent
-> company services / data / tools

Claude nie znika.

Zmienia się warstwa dookoła niego.

To nadal nie jest orchestrator

Nie mieszaj tego z poprzednim artykułem.

Narzędzia typu:

text
Trigger.dev
Hatchet
Temporal
Inngest
Restate

odpowiadają głównie za:

text
workflow
state
retry
wait
event
approval

Agent runtime odpowiada za:

text
gdzie agent działa
jak jest uruchamiany
jak dostaje identity
jak się skaluje
jak jest obserwowany

Możesz więc mieć oba:

text
GitHub event
-> Trigger.dev
-> Agent Runtime
-> Claude agent
-> result
-> Trigger.dev
-> kolejny krok

To są różne warstwy.

Wdróż to dziś

Nie migruj niczego.

Zrób prostą ocenę swojego setupu.

Jeżeli Managed Agents spełniają wymagania:

text
zostań przy nich

Jeżeli zaczynasz mieć wymagania typu:

text
centralny IAM
private networking
multi-model
enterprise governance
wspólny observability stack
własne deployment policies

zacznij patrzeć na platformy agent runtime.

Nie dlatego, że Claude przestał wystarczać.

Tylko dlatego, że runtime agenta stał się częścią problemu infrastrukturalnego.

Level complete

Poziom jest zaliczony, kiedy potrafisz rozdzielić trzy warstwy:

text
Claude
= reasoning

orchestrator
= pilnuje workflow

agent runtime
= hostuje i zarządza agentem

I potrafisz rozpoznać moment, w którym Claude Managed Agents są wystarczające, a moment, w którym potrzebujesz bardziej platformowego podejścia.

Materiały