Zbudowałeś agenta. Przetestowałeś go na swoim laptopie. Działał — nawet pięknie. Więc wrzuciłeś go na produkcję tak, jak ludzie stawiali strony w 2003 roku: edytuj plik na serwerze, zapisz, módl się.
Potem o drugiej w nocy twój agent zaczyna halucynować wywołania narzędzi, wysyłać maile do ludzi, którzy o żadne maile nie prosili, i przepalać twój budżet API jak marynarz na przepustce. Sięgasz po przycisk rollbacku. Nie ma przycisku rollbacku. Nie ma poprzedniej wersji. Twój agent nie ma wersji — to system prompt w polu tekstowym, garść konfiguracji narzędzi i cokolwiek trzymasz w głowie.
Witaj w deploymencie agentów — kwiecień 2026.
Platformy wyszły. Pipelines — nie.
Między 8 a 22 kwietnia trzej giganci chmury wypuścili swoje platformy agentowe jeden po drugim: Anthropic z Managed Agents (8 kwietnia) — hostowane sandboxy i CLI ant, OpenAI z Agents SDK v0.14 (15 kwietnia) — sześć wydań w dziesięć dni, i Google z ADK 1.0 na Cloud Next (22 kwietnia) — wielojęzyczne SDK i dashboard do monitoringu. Porównania ficzerów już omawialiśmy. Czego żaden z nich nie dostarczył: dyscypliny deploymentu.
Jak ujął to xpander.ai w swoim porównaniu 24 kwietnia: "Czego nie oferują: przenośności multi-cloud, natywnego CI/CD dla agentów, wersjonowania, rollbacku ani canary deployments." Każdy hyperscaler dostał ocenę 'DIY" za cykl życia agenta.
Trzeba przyznać, Anthropic podszedł najbliżej — CLI ant deklaruje promocję ze stagingu na produkcję. Ale ich własny post na blogu inżynieryjnym zawiera zero wzmianek o rollbacku, canary deploys czy blue-green switchingu. Wersjonowanie istnieje; dyscyplina deploymentu — nie.
Dlaczego agenty zepsuły CI/CD
CI/CD — continuous integration i continuous deployment — to sposób, w jaki normalny software trafia na produkcję. Masz artefakt do wdrożenia (obraz Dockera, skompilowany binarek), testujesz go na stagingu (bezpieczna kopia produkcji), puszczasz canary (5% ruchu na nową wersję), a jak się sypie — rollback jednym poleceniem.
Agenty nie mają jednego artefaktu. Zachowanie agenta żyje na co najmniej czterech powierzchniach:
# Powierzchnia 1: Kod (wersjonowany w gicie)
agent = Agent(model="claude-sonnet-4", tools=[search, email, calendar])
# Powierzchnia 2: System prompt (często edytowany w dashboardzie, nie w gicie)
SYSTEM_PROMPT = "Jesteś asystentem do planowania spotkań, który..."
# Powierzchnia 3: Konfiguracje narzędzi (uprawnienia, rate limity, klucze API)
# Powierzchnia 4: Pamięć / wyuczony kontekst (żyje... gdzieś)
System prompt i opisy narzędzi to najbardziej krytyczne elementy zachowania, ale domyślnie żyją poza kontrolą wersji. Simon Willison pokazał to 18 kwietnia, ręcznie budując historię Gita z fałszywymi datami commitów, żeby śledzić zmiany promptów — reverse-engineering wersjonowania, które powinno być ficzerą platformy.
Jak sami Anthropic przyznali: "Wdrożenie agenta na poziomie produkcyjnym wymaga od zespołów programistycznych zbudowania nie tylko samego agenta, ale też znacznej ilości scaffoldingu."
Era taśmy klejącej
Obejścia istnieją. Możesz wersjonować pliki promptów w gicie. Możesz ręcznie robić blue-green swap. Możesz flag-ować feature'ami listę narzędzi. Oto minimalne 'wersjonowanie agenta":
# Wersjonowanie agenta dla ubogich
agent_config = {
"version": "1.4.2",
"prompt_sha": "a3f8c1d", # hash gita pliku promptu
"tools": ["search_v2", "email_v1"],
"permissions": {"email": {"max_per_hour": 10}},
"model": "claude-sonnet-4",
}
# Deploy: załaduj config → zwaliduj → przełącz ruch
# Rollback: załaduj poprzedni config → przełącz z powrotem
Ale to taśma klejąca wymagająca dyscypliny, której żadna platforma nie wymusza. I sypie się w momencie, gdy do gry wchodzi pamięć agenta — kontekst wyuczony w trakcie sesji. Nie da się zrollbackować tego, co agent pamięta.
Jak źle może być? Post-mortem Reworkd z marca 2026 udokumentował jeden zły deployment promptu, który wywołał 14 000 błędnych wywołań API w 47 minut — 2300 dolarów w tokenach, zanim ktokolwiek zauważył. Żadnego canary. Żadnego rollbacku. Tylko alert na Slacku, który przyszedł za późno. Pomnóż to przez tysiące zespołów budujących teraz agenty bez guardrails deploymentu i zaczynasz widzieć skalę problemu.
Co powinieneś zrobić teraz
Jeśli budujesz agenty dzisiaj: traktuj każdy prompt, konfigurację narzędzi i politykę uprawnień jako infrastructure-as-code. Trzymaj je w kontroli wersji. Nigdy nie aktualizuj agenta na produkcji bez przetestowania kopii na stagingu. Zaplanuj czas na budowę pipeline'u deploymentu, który twój dostawca platformy pominął. To nie jest opcjonalne — to różnica między demem a produktem.
Brakująca warstwa
Pamiętaj, zacząłeś tę przygodę od edycji pliku na serwerze. Dokładnie tu są teraz agenty — w erze pre-Docker, "u mnie działa". Platforma, która dostarczy agent CI/CD jako domyślny prymityw — staging, canary, rollback, z agentem jako wersjonowalnym artefaktem — przejmie warstwę operacyjną, która siedzi powyżej jakości modelu i liczby narzędzi. To jest prawdziwa nagroda, i na dzień 26 kwietnia 2026 nikt jej jeszcze nie zdobył.
