Kaskadowe wskaźniki awarii w wielokrokowych agentach są brutalne — to już ustaliliśmy. Siedmiokrokowy workflow przy 95% niezawodności na krok daje około 70% end-to-end. Trzy na dziesięć uruchomień wybucha. Ale jest część, której nikt nie naprawia: kiedy krok czwarty rzuca HTTP 500, co się dzieje z trzema krokami, które już się wykonały? Wiadomość na Slacku już wysłana, wiersz w bazie już zapisany, ticket w Jirze już założony. Twój agent nie wie, które kroki się zakończyły. Nie ma checkpointu — żadnego zapisanego stanu, do którego mógłby wrócić. I nie ma logiki kompensacji — żadnego automatycznego "cofnij" dla na wpół wykonanej roboty.

Zobaczenie wskaźnika awarii to krok pierwszy. Przeżycie awarii to krok drugi. Nikt nie wdraża kroku drugiego.

Teatr odzyskiwania

Wszystkie trzy główne runtime'y agentów wypuściły funkcje recovery w kwietniu. Żaden z nich nie rozwiązuje problemu recovery.

Anthropic Managed Agents (8 kwietnia) używają append-only event logu — jednokierunkowego dziennika wszystkiego, co agent zrobił. Crash? Restart, odczytaj dziennik, kontynuuj. Ich zespół inżynierów: "Nic w harnessie nie musi przetrwać crasha." Brzmi odpornie. Ale nie ma dead-letter queue dla nieudanych zadań, nie ma gwarancji exactly-once, że każda akcja wykona się dokładnie raz, i nie ma sposobu na wycofanie ukończonych efektów ubocznych.

OpenAI Agents SDK update (15 kwietnia) dodał snapshotting i rehydration — zapisywanie i odtwarzanie stanu agenta między restartami kontenerów. Ale persystuje historię wiadomości, nie stan wykonania. Model pamięta, co powiedział; nie śledzi, co zrobił.

Google ADK (ogłoszony na Cloud Next, 22 kwietnia) dostarcza SequentialAgent, ParallelAgent, LoopAgent plus ResumabilityConfig. Drobny druczek: to wywołujący musi wykryć przerwanie i ręcznie wywołać ponownie. Żadnego automatycznego recovery.

Trzy różne podejścia do trwałości. Wszystkie trzy modelują wykonanie jako pętle inferencji — "pomyśl → wywołaj narzędzie → obserwuj → powtórz." Żadne nie modeluje tego jako durable state machine — systemu, który śledzi dokładnie, w jakim stanie się znajduje i które przejścia są dozwolone, jak automat vendingowy, który pamięta, że już wrzuciłeś monetę nawet po awarii zasilania.

Rozwiązania, które już istnieją (poza AI)

Silniki workflow rozwiązały problem durable execution dekadę temu. Branża AI po prostu ich jeszcze nie zaadoptowała.

Temporal opakowuje każdy krok w powtarzalną, odtwarzalną activity. Crash w połowie workflow? Temporal odtwarza od ostatniej ukończonej activity — nie od zera. Tak wygląda krok agenta opakowany w Temporal:

@activity.defn
async def file_jira_ticket(ctx: AgentContext) -> TicketResult:
    """Temporal automatycznie ponawia to przy awarii.
    Jeśli agent crashnie w połowie workflow, odtwarza
    od ostatniej ukończonej activity — nie od zera."""
    return await ctx.tools.jira.create_issue(
        summary=ctx.draft.title,
        idempotency_key=ctx.run_id  # zapobiega duplikatom ticketów
    )

Ten idempotency_key — unikalny identyfikator zapewniający, że to samo żądanie nie wykona się dwa razy — to cała różnica między "production-grade" a "efektownym demo".

Cloudflare Project Think (15 kwietnia) poszedł zupełnie inną drogą: bazy SQLite per agent, checkpointy step.do() i hibernacja zero-cost. Każdy agent to trwały, izolowany byt z własnym persystentnym stanem, a nie job w centralnym orkiestratorze. Dla zespołów już na Cloudflare Workers to prawdopodobnie najczystsza ścieżka — bez zewnętrznego silnika workflow, bez message brokera, same durable objects z wbudowanym checkpointingiem.

Restate plasuje się pomiędzy: lżejszy niż Temporal, bardziej ustrukturyzowany niż surowe durable objects. Zapewnia gwarancje exactly-once z mechanizmem replay opartym na journalu i opublikował wzorce integracji bezpośrednio z Google ADK.

Niewygodny środek

Problem, którego nikt nie chce przyznać: luka działa w obie strony.

Silniki workflow nie mówią w LLM. Nie rozumieją token budgets — ile tekstu AI może przetworzyć na jedno wywołanie. Nie obsługują model fallback routing — przełączania na tańszy model, gdy drogi trafia w rate limits. Nie mają pojęcia o prompt versioning, zarządzaniu context window ani ewolucji schematów tool-call. Przykręcenie agentów do Temporal oznacza napisanie warstwy translacji między "krokiem workflow" a "wywołaniem inferencji" — i utrzymywanie jej za każdym razem, gdy dostawca modelu zmienia swoje API.

Platformy agentowe nie rozumieją durability. Traktują wywołania narzędzi jako efemeryczne efekty uboczne inferencji, nie jako przejścia stanowe wymagające gwarancji transakcyjnych. LLM wywołujący narzędzie to filozoficznie coś innego niż krok workflow wywołujący funkcję: LLM może zdecydować się wywołać narzędzie ponownie, wywołać inne narzędzie albo zhallucynować narzędzie, które nie istnieje. Silniki workflow zakładają deterministyczne definicje kroków. LLM-y są z definicji niedeterministyczne.

Żadna strona nie jest w błędzie. Rozwiązują różne połówki tego samego problemu.

Co to znaczy dla ciebie

Jeśli twój agent modyfikuje zewnętrzny stan przez więcej niż trzy kroki — wysyła maile, pisze do baz danych, wywołuje API firm trzecich — już potrzebujesz gwarancji silnika workflow. Twoja platforma agentowa ich nie zapewnia. Masz trzy opcje:

  1. Dokręć Temporal/Restate samodzielnie. Realna złożoność integracji, ale sprawdzona w boju trwałość. Warto, jeśli prowadzisz agenty na produkcji z prawdziwymi SLA.
  2. Idź full Cloudflare. Jeśli już jesteś na Workers, Project Think daje ci durable agents bez narzutu orkiestracji. Kompromis: vendor lock-in.
  3. Zaakceptuj wskaźnik awarii i zbuduj narzędzia do ręcznej rekoncyliacji. Szczerze, dla wewnętrznych narzędzi z wyrozumiałymi użytkownikami to może być racjonalne. Tylko nie nazywaj tego "production-ready".

Konwergencja jest nieunikniona. Pierwszy vendor, który dostarczy durable state-machine execution jako domyślny prymityw agentowy — nie jako dodatek, nie jako integrację z third-party — przejmie warstwę niezawodności produkcyjnej ponad wszystkimi trzema runtime'ami. Temporal to wie; ich integracja z OpenAI Agents SDK to land grab. Cloudflare to wie; Project Think jest zaprojektowany tak, żeby agenty stały się feature platformy.

Twoje siedmiokrokowe demo wciąż działa pięknie. Wdrożenie go na produkcję wciąż oznacza wybór, z którym trybem awarii jesteś w stanie żyć.