Restate zebrał 20 mln dolarów — agenci AI mają wracać po awarii

Według komunikatu Restate z 30 września 2026 r. berlińska spółka pozyskała 20 mln dolarów w rundzie Series A, której przewodził Singular, z udziałem Redpoint Ventures i Capital One Ventures. Finansowanie ma pomóc rozwijać system trwałego wykonywania procesów: zapisuje on postęp wieloetapowego zadania, aby po awarii wykorzystać ukończone kroki i wznowić pracę. W przypadku agenta AI chodzi między innymi o zachowanie wyników wywołań modelu i narzędzi.

W relacji TechCrunch współzałożyciel Stephan Ewen mówi o pierwotnym przeznaczeniu technologii: „It never was built for agents in the beginning”; publikacja wskazuje też Replit jako klienta Restate. Silnik powstał do obsługi odpornych procesów backendowych, zanim długie zadania agentów stały się ważnym zastosowaniem. Restate obsługuje już wykonywanie Replit Agent, więc runda dotyczy rozwoju używanego produktu, a nie zapowiedzi jego pierwszego wdrożenia.

Co dzieje się z zadaniem agenta po przerwaniu

W długim zadaniu awaria rzadko następuje w wygodnym momencie. W umownym przykładzie agent pyta model o dalsze działanie, wywołuje wskazane narzędzie, czeka na odpowiedź i na jej podstawie wybiera następny krok. Jeśli aplikacja zostanie zatrzymana po odpowiedzi modelu, ale przed zapisaniem tego wyniku, ponowne uruchomienie może oznaczać kolejne wywołanie modelu. Odpowiedź może się różnić, a wykonana wcześniej praca nie zostanie automatycznie odzyskana.

Trwałe wykonanie zmienia punkt, od którego zadanie rusza ponownie. System zapisuje wyniki wybranych działań w dzienniku wykonania. Po awarii kod może zostać uruchomiony ponownie, lecz ukończony krok otrzymuje swój zapisany wynik, zamiast jeszcze raz pytać model lub narzędzie. Dopiero działanie, którego wyniku nie utrwalono, wymaga ponowienia. Właśnie ta różnica ma znaczenie, gdy pojedyncze zadanie obejmuje wiele decyzji, wywołań usług i okresów oczekiwania.

Zapis postępu pomaga również wtedy, gdy proces aplikacji znika podczas wdrożenia nowej wersji albo traci połączenie z usługą. Wcześniejsze wyniki pozostają dostępne dla wznowionego wykonania; samo zadanie nie musi być traktowane jako jedna niepodzielna operacja. Przy zadaniu trwającym długo oszczędza to ponownego wykonywania ukończonych etapów i pozwala zachować ciągłość decyzji podjętych przed przerwaniem.

Dlaczego Restate zapisuje kroki wewnątrz pętli agenta

Istotna jest szczegółowość zapisu. Gdy system utrwala tylko początek i koniec całego procesu, awaria w środku może wymusić powtórzenie znacznej części pracy. Restate chce umieszczać trwałe działania wewnątrz pętli agenta, przy wywołaniach modelu, narzędzi i zmianach stanu. Dzięki temu zapisany wynik staje się częścią historii wykonania, z której korzysta proces odtwarzany po przerwaniu.

Za tą funkcją stoi dziennik zdarzeń z replikacją, lokalne przechowywanie danych w RocksDB oraz trwałe migawki w magazynie obiektowym. Restate nie opiera całego silnika wyłącznie na zewnętrznej bazie danych: zapis do dziennika służy zarówno utrwaleniu postępu, jak i koordynacji dalszego wykonania. Spółka przedstawia tę architekturę jako sposób na ograniczenie opóźnień i kosztu częstych zapisów. To argument projektowy Restate, a nie niezależny pomiar przewagi nad każdym konkurencyjnym rozwiązaniem.

Replit Agent pokazuje, po co przenosić granicę trwałości do wnętrza zadania. Agent programistyczny może kolejno korzystać z modelu, narzędzi i informacji zwrotnych od użytkownika; przerwanie takiej sekwencji nie powinno usuwać już uzyskanych wyników. Restate służy w tym wdrożeniu jako warstwa wykonania, natomiast przebieg samego agenta i wybór działań pozostają częścią systemu Replit. Ta różnica oddziela odporność infrastruktury od jakości decyzji modelu.

Wznowienie nie usuwa ryzyka podwójnego działania

Najtrudniejsza granica przebiega przy usłudze zewnętrznej. Narzędzie może wykonać operację, a aplikacja ulec awarii, zanim odpowiedź zostanie trwale zapisana. Opis efektów ubocznych w Restate wskazuje, że w takim oknie awarii działanie może zostać wykonane więcej niż raz. Jeśli skutkiem jest na przykład wysłanie żądania płatności, usługa odbierająca nadal musi umieć rozpoznać ponowienie, choćby za pomocą klucza idempotencji.

Restate porządkuje więc ponawianie i odzyskiwanie zapisanego postępu, ale nie gwarantuje poprawności każdej operacji poza własnym dziennikiem. Jeżeli model wybierze niewłaściwe narzędzie, trwały zapis zachowa tę decyzję. Jeżeli zewnętrzne API odrzuca żądanie z powodu błędnych danych, kolejne próby nie naprawią danych. Dziennik odpowiada na pytanie, co zostało ukończone i skąd wznowić wykonanie; logika zadania nadal musi określać, kiedy próbę powtórzyć, przerwać albo skierować do człowieka.

To wyjaśnia również, kiedy wystarczy prostsza kolejka. Dla krótkiego zadania, które można tanio uruchomić od początku, kolejka z ponawianiem oraz idempotentnym odbiorcą może zapewnić potrzebną odporność. W wieloetapowym procesie agenta trzeba dodatkowo zachować wcześniejsze odpowiedzi modelu, wyniki narzędzi i stan oczekiwania. Sama obecność zadania w kolejce nie mówi, które z tych działań zostały już zakończone ani jak bezpiecznie do nich wrócić.

Na co Restate przeznaczy finansowanie

Nowa runda ma wesprzeć rozwój produktu, zatrudnienie oraz rozbudowę obecności spółki w rejonie San Francisco. Restate działa na rynku infrastruktury trwałego wykonywania procesów, na którym obecny jest także Temporal. Zainteresowanie agentami zwiększa wagę krótkich, częstych zapisów wewnątrz długiego zadania, lecz zastosowanie technologii pozostaje szersze: obejmuje również procesy backendowe niezwiązane z AI.

Dla użytkownika agenta znaczenie tej inwestycji będzie widoczne w chwili przerwania pracy: czy po powrocie zachowane zostaną wyniki już ukończonych działań i czy niedokończona operacja zostanie ponowiona bez niezamierzonego skutku. Pierwszą część problemu rozwiązuje dziennik wykonania. Druga zależy także od sposobu, w jaki agent i zewnętrzne usługi obsługują ponawiane żądania.

Przeczytaj także:

• Trójmorze uruchamia fundusz 360 mln euro: Polska wnosi 50 mln
• Agenci OpenAI wysłali 53 obrazy użytkowników na zewnętrzne serwisy