Agenci chcą kompilować

Agenci AI zaczynają kompilować. W połowie 2026 roku ta sama separacja pojawia się w całym stosie, z każdej strony: model decyduje, a wykonuje coś, co nie jest modelem. Zamiast działać na żywo wewnątrz pętli modelu, agenci emitują deterministyczny artefakt — plan, graf DAG, skrypt przepływu pracy — i przekazują go środowisku uruchomieniowemu, które odtwarza go, wznawia i audytuje jak zwykłe oprogramowanie. Model staje się front-endem kompilatora, parsującym nieuporządkowaną intencję do reprezentacji pośredniej. Deterministyczne środowiska uruchomieniowe stają się back-endem. Działanie na żywo zostaje wycenione na nowo jako kosztowny tryb, który rezerwuje się dla eksploracji, nowych awarii i kwestii smaku. {.answer-block}

1 lipca na Hacker News wylądował wpis Show HN z tytułem, który brzmi jak teza: „Coding agent that compiles intent into deterministic DAG before running” (agent kodujący, który przed uruchomieniem kompiluje intencję do deterministycznego grafu DAG). Projekt nazywa się Rigorix — to napisane w Ruście środowisko uruchomieniowe, które określa się mianem „deterministycznego środowiska uruchomieniowego dla agentów kodujących na potrzeby powtarzalnej, audytowalnej inżynierii oprogramowania AI”, a swój podział pracy streszcza w jednym zdaniu: „LLM generuje kod; Rigorix zarządza wykonaniem”.³ Czternaście punktów, jeden komentarz — łatwo przewinąć dalej. Zatrzymałem się przy nim, bo to już trzeci raz w ciągu trzech tygodni, kiedy obserwuję, jak ten sam kształt pojawia się z kolejnego kierunku, a historią jest właśnie ten kształt, nie żadne pojedyncze narzędzie.

TL;DR

• Anthropic wyznaczył kanoniczną granicę w grudniu 2024 roku: przepływy pracy działają „poprzez predefiniowane ścieżki kodu”, a agenci „dynamicznie kierują własnymi procesami”.¹ Było to rozwidlenie wybierane przez człowieka na etapie projektowania. Teraz przenosi się do czasu wykonania, a wyboru dokonuje model.
• W dynamicznych przepływach pracy Claude Code model pisze skrypt orkiestracyjny w JavaScripcie, który środowisko uruchomieniowe wykonuje poza konwersacją: da się go wznowić z wynikami z pamięci podręcznej, porównać ze skryptami poprzednich uruchomień i zapisać jako polecenie do wielokrotnego użytku.²
• Ten sam kształt nadchodzi z trzech kolejnych kierunków: niezależne narzędzia kompilujące zadania w języku naturalnym do wykonywalnych grafów DAG (Rigorix)³, frameworki odmawiające uruchomienia nieskompilowanego grafu (LangGraph)⁴ oraz infrastruktura trwałego wykonywania opakowująca pętle agentów w odtwarzalne przepływy pracy (Temporal)⁵.
• Kompilacja kupuje to, co kupuje zawsze: pamięć podręczną, przyrostowe przebudowy, artefakty dające się porównywać, przegląd przed wykonaniem. Kosztuje zaś to, co kosztuje zawsze: osąd zamrożony w momencie kompilacji.
• Działanie na żywo wciąż wygrywa w eksploracji, przy nowych stanach błędów i w kwestiach smaku. Zasada operacyjna: pierwsze uruchomienie to badanie, każde kolejne chce być buildem.

Rozwidlenie było kwestią czasu projektowania. Staje się kwestią czasu wykonania

Punktem odniesienia jest tu tekst Anthropic „Building Effective Agents”, opublikowany 19 grudnia 2024 roku i wciąż stanowiący standardową taksonomię tej przestrzeni. Definiuje on przepływy pracy jako „systemy, w których LLM-y i narzędzia są orkiestrowane poprzez predefiniowane ścieżki kodu”, a agentów jako „systemy, w których LLM-y dynamicznie kierują własnymi procesami i użyciem narzędzi, zachowując kontrolę nad sposobem realizacji zadań”. Jego rada dotycząca wyboru brzmi: „przepływy pracy oferują przewidywalność i spójność dla dobrze zdefiniowanych zadań, podczas gdy agenci są lepszą opcją, gdy na dużą skalę potrzebne są elastyczność i podejmowanie decyzji sterowane modelem”.¹

Przez osiemnaście miesięcy to zdanie czytało się jak menu. Projektant systemu wybierał lewą albo prawą kolumnę, zanim napisał pierwszą linijkę. Zwrot roku 2026 polega na tym, że menu zapada się w potok. Agent wykonuje elastyczny, sterowany modelem przebieg dokładnie raz — na etapie planowania — a wynikiem tego przebiegu jest przepływ pracy: predefiniowane ścieżki kodu, wygenerowane na żądanie, dla tego konkretnego zadania. Elastyczność agenta otrzymuje się w czasie kompilacji, a przewidywalność przepływu pracy w czasie wykonania — z tego samego systemu, w fazach.

Na pytanie „przepływ pracy czy agent?” odpowiada się dziś tak, jak kompilatory odpowiedziały na pytanie „elastyczność czy szybkość?”: jedno i drugie, rozdzielone artefaktem.

Trzy sygnały, jeden kierunek

Najpierw deterministyczne stało się środowisko

Warstwa harnessu dotarła tam przed agentami. Hooki odpalają się na zdarzeniach cyklu życia z kodami wyjścia, z którymi model nie może negocjować. Reguły uprawnień są ewaluowane przed wywołaniem narzędzia, nie po nim. Cała dyscyplina architektury agentowej w 2026 roku to deterministyczna powłoka wokół stochastycznego rdzenia, a jej szczere wyznanie brzmi: przy wszystkim, co musi wydarzyć się za każdym razem, przestaliśmy prosić model i zaczęliśmy egzekwować na granicy. Determinizm najpierw dotarł na krawędzie.

Potem trwały artefakt pokonał konwersację

Drugi sygnał dotyczy tego, co przetrwa sesję. Konwersacje wyparowują; kontrola, specyfikacja i test pozostają, a agenci optymalizują pod nie tak mocno, że kontrola staje się specyfikacją. Lekcja pod spodem: transkrypt nie jest wynikiem. Wynikiem jest artefakt, bo tylko jego mogą uchwycić następna sesja, następny agent i następny inżynier. Gdy raz przyjmie się to dla weryfikacji, przyjęcie tego samego dla planów wykonania jest już krótkim krokiem. Jeśli trwała kontrola przeżywa konwersację, która ją wytworzyła, to trwały plan również.

Teraz artefaktem jest sam plan

Trzeci sygnał jest tym nowym — i to o nim jest ten esej. Agenci zaczęli emitować swoje wykonanie jako pełnoprawny artefakt, zamiast odgrywać je na żywo.

Claude Code wypuścił to jako element produktu. Dynamiczny przepływ pracy to „skrypt JavaScript, który orkiestruje subagentów na dużą skalę”: Claude pisze skrypt dla opisanego zadania, a środowisko uruchomieniowe wykonuje go w tle, podczas gdy sesja pozostaje responsywna. Dokumentacja mówi wprost, co przeszło z rąk do rąk: „Przepływ pracy przenosi plan do kodu”. W ich własnej tabeli porównawczej odpowiedzią na pytanie „kto decyduje, co uruchomi się dalej”, nie jest Claude. Jest nią skrypt. Każde uruchomienie zapisuje ten skrypt do pliku, który można otworzyć, porównać ze skryptem poprzedniego uruchomienia, edytować i wystartować ponownie. Po przerwaniu i wznowieniu uruchomienia „agenci, którzy już zakończyli pracę, zwracają wyniki z pamięci podręcznej, a reszta działa na żywo”.²

Rigorix buduje ten sam kształt od strony niezależnej, a jego architektura czyta się jak podręcznik kompilatorów: planowanie przebiega przez klasyfikację intencji, następnie ekstrakcję parametrów, a potem generowanie grafu DAG; silnik oparty na szablonach wykonuje graf pod nadzorem bramek ryzyka, budżetów i uprawnień, z podpisanymi HMAC kopertami audytowymi jako śladem. Definicja korzyści jest precyzyjna: „Powtarzalność oznacza, że ta sama intencja wytwarza tę samą strukturę wykonania przy tych samych szablonach i politykach”.³

Frameworki były tam już wcześniej, ukrywając tę samą ideę w czasowniku API. LangGraph modeluje logikę agentów jako węzły („funkcje, które kodują logikę agentów”) połączone krawędziami, a jego dokumentacja formułuje wymóg pogrubieniem: „MUSISZ skompilować graf, zanim będzie można go użyć”. Przy kompilacji z checkpointerem „LangGraph zapisuje punkty kontrolne na granicach super-kroków” — i właśnie to sprawia, że na wpół ukończone uruchomienie daje się wznowić.⁴

Od dołu nadeszła zaś warstwa infrastruktury. Temporal, platforma trwałego wykonywania (durable execution), opakowuje pętle rozumowania agentów w przepływy pracy, których postęp utrwala się poza jakimkolwiek procesem: „Temporal śledzi postęp aplikacji i przechowuje wszystkie wyniki Activity”, więc agent po awarii „podejmuje pracę tam, gdzie ją przerwał”, zamiast rozumować od zera. Integracja z Agents SDK od OpenAI, ogłoszona 30 lipca 2025 roku, uczyniła z tego opakowania oficjalnie wspieraną ścieżkę, a nie wzorzec sklejany ręcznie.⁵

Niezależne narzędzie, element produktu, framework, infrastruktura. Cztery kierunki, jeden kształt: model decyduje, artefakt wykonuje.

Analogię do kompilatora warto potraktować dosłownie

Analogie w tekstach o AI są zwykle ozdobą. Ta jest nośna, bo wynikają z niej przewidywania.

Front-end kompilatora parsuje źródło, sprawdza semantykę i emituje reprezentację pośrednią. Dokładnie tym jest faza planowania w tych systemach: klasyfikacja intencji w Rigorix to parsowanie, ekstrakcja parametrów to analiza semantyczna, generowanie grafu DAG to generowanie kodu. Skrypt przepływu pracy jest reprezentacją pośrednią. Back-end robi następnie to, co robią back-endy: planuje równoległość, egzekwuje limity zasobów (Claude Code ogranicza uruchomienie do 16 agentów równocześnie i 1000 łącznie²) i memoizuje. Wynikają z tego cztery konsekwencje.

Plany zyskują pamięci podręczne kompilacji. Semantyka wznawiania to kompilacja przyrostowa. Claude Code przy wznowieniu zwraca wyniki agentów z pamięci podręcznej; Temporal kusi budowniczych agentów tym, że odzyskiwanie od punktu awarii oszczędza tokeny, zamiast ponownie uruchamiać model w celu odtworzenia utraconej pracy.⁵ Następny krok to etapy planu adresowane treścią: ponowne uruchomienie przepływu pracy, którego wczesne etapy się nie zmieniły, pominie je tak, jak make pomija niezmienione pliki obiektowe.

Plany podlegają diffowaniu. Dokumentacja przepływów pracy wprost zachęca do porównania skryptu danego uruchomienia ze skryptem poprzedniego.² Gdy plan jest tekstem, dryf planu staje się widoczny tak samo jak dryf kodu, a „orkiestracja tej migracji zmieniła się od zeszłego kwartału” staje się zdarzeniem do przeglądu w pull requeście, a nie projektem archeologicznym rozciągniętym po transkryptach.

Plan staje się powierzchnią przeglądu. Zanim przepływ pracy się uruchomi, Claude Code pokazuje zaplanowane fazy i jeszcze przed wyrażeniem zgody oferuje opcję „View raw script”.² To ten element łączy się z kierunkiem, w którym zmierza przegląd. Argumentowałem, że agenci zastąpili recenzenta, nie recenzję: praca człowieka przeniosła się z inspekcji diffów na własność intencji. Skompilowany plan jest artefaktem, w którym ten przeniesiony przegląd się odbywa, bo to jedyne miejsce, w którym intencja jest czytelna, zanim wykonanie cokolwiek wyda. Nie da się przejrzeć dziesięciu tysięcy decyzji podejmowanych na żywo. Da się przejrzeć czterdziestolinijkowy skrypt. Można oczekiwać, że zatwierdzanie dużych operacji agentowych przeniesie się z akceptowania diffa po fakcie na akceptowanie planu przed faktem.

Dryf wyzwala rekompilację, nie łatanie. Gdy skompilowany plan zawodzi, bo świat się zmienił — API zmieniło nazwę, zależność podbiła wersję — błędnym ruchem jest ręczna edycja grafu DAG. To łatanie kodu wynikowego. Właściwa pętla ponownie uruchamia front-end: ta sama intencja, nowe środowisko, świeży plan. Trwałe środowiska uruchomieniowe już dziś absorbują przejściowe awarie wewnątrz artefaktu za pomocą ponowień; dryf środowiskowy to ta klasa awarii, która ucieka do kompilatora. Harnessy obrosną w detektory dryfu unieważniające plany tak, jak systemy budowania unieważniają pamięci podręczne, a „rekompilacja przy dryfie” stanie się stałą pętlą, a nie ręczną akcją ratunkową.

Gdzie wygrywa każdy z trybów

Tabela to granica, nie ranking. Wszystko poniżej tej granicy wkrótce stanie się znacznie tańsze i znacznie bardziej godne zaufania. Wszystko powyżej pozostaje kosztowne — bo tak powinno być.

Czego kompilacja nie kupuje

Trzy rzeczy pozostają na żywo, a udawanie, że jest inaczej, to droga, którą ten wzorzec zostanie przereklamowany.

Eksploracja. W nieznanej bazie kodu lub przy autentycznie nowym problemie plan jest odkryciem. Nie ma jeszcze czego kompilować, bo pracą jest właśnie decydowanie. Kompilowanie przed zrozumieniem wytwarza pewny siebie artefakt własnej niewiedzy — a środowisko uruchomieniowe wykona go bezbłędnie.

Nowe stany błędów. Skompilowany plan obsługuje awarie, które przewidział jego autor. Polityki ponowień to deterministyczne odpowiedzi na spodziewane kłopoty. Gdy kłopoty są niespodziewane, deterministyczne ponawianie jest pętlą, a nie naprawą, i właściwym ruchem jest eskalacja z powrotem do front-endu, gdzie model może spojrzeć na rzeczywisty błąd i pomyśleć.

Smak. Przepływ pracy to osąd zamrożony w momencie kompilacji, a zamrożony osąd się starzeje. Świeży osąd wykonany niechlujnie bije nieaktualny osąd wykonany bezbłędnie, bo wersja nieaktualna zawodzi z pełnym przekonaniem. Nikt nie powinien kompilować decyzji o tym, jakie wrażenie ma sprawiać produkt.

Jest też ostrzeżenie do przeniesienia ze strony weryfikacji. Graf DAG jest powierzchnią kontroli, a wszystko, co plan pomija, po cichu przestaje być częścią zadania — to ta sama dynamika, która sprawia, że widoczne testy stają się faktyczną specyfikacją. Kompilacja skupia cały osąd modelu na temat zadania w jednym artefakcie, co skupia pracę człowieka na własności tego artefaktu. Przegląd nie znika, gdy plan się kompiluje. Przenosi się na etap planowania i dostaje do dyspozycji jedną stronę o wysokiej dźwigni.

Stanowisko

Zasada, według której teraz działam, jest prosta: pierwsze wykonanie dowolnego zadania to badanie i zasługuje na agenta działającego na żywo; drugie wykonanie to build i zasługuje na artefakt. Claude Code dostarcza tę zasadę jako UX: wystarczy raz zlecić Claude’owi napisanie przepływu pracy, zapisać skrypt uruchomienia jako polecenie i uruchamiać go ponownie w nieskończoność.² Rigorix dostarcza ją jako nadzór. Temporal — jako infrastrukturę. LangGraph dostarczył ją lata wcześniej jako czasownik API, którego nikt nie odczytał jako manifestu.

Agenci chcą kompilować z tego samego powodu, z którego chcieli programiści. Decydowanie jest kosztowne i cenne. Wykonywanie powinno być nudne, inspekcjonowalne i darmowe w powtarzaniu. Branża spędziła lata 2024 i 2025 na dowodzeniu, że modele potrafią decydować. Praca roku 2026 polega na zapewnieniu, że będą musiały decydować tylko raz.

Najważniejsze wnioski

• Pierwsze uruchomienie to badanie, drugie to build. Nowe zadanie warto uruchamiać z agentem na żywo; w chwili, gdy zaczyna się powtarzać, należy zamrozić je w artefakt i przestać płacić za świeży osąd nad rozwiązanym problemem.
• Najpierw warto skompilować nudne 80%. Obowiązki wydaniowe, przebiegi migracji, partie tłumaczeń, przejścia audytowe: wysoka powtarzalność, tania weryfikacja. Eksploracja, debugowanie i smak pozostają na żywo.
• Warto przyjąć pętlę rekompilacji przy dryfie. Gdy skompilowany przepływ pracy psuje się, bo świat się zmienił, nie należy łatać artefaktu ręcznie. Trzeba odesłać model, by wygenerował plan na nowo wobec nowej rzeczywistości, przejrzeć diff i ponownie zamrozić.
• Przeglądać należy plan, nie transkrypt. Gdy wykonanie jest deterministyczne, plan jest stroną o najwyższej dźwigni w całym systemie. Czyta się go tak, jak czyta się skrypt migracji — bo właśnie tym jest.

FAQ

Co to znaczy, że agent AI kompiluje swój plan?

Oznacza to, że wynikiem pracy agenta jest deterministyczny, inspekcjonowalny artefakt — skrypt przepływu pracy lub graf DAG — a nie sekwencja działań na żywo. Model przeprowadza rozumowanie na etapie planowania i emituje artefakt; środowisko uruchomieniowe niebędące modelem wykonuje go z semantyką odtwarzania, wznawiania i audytu. Dostępnymi już przykładami są dynamiczne przepływy pracy Claude Code (napisany przez model skrypt JavaScript wykonywany przez środowisko uruchomieniowe) oraz Rigorix (zadania w języku naturalnym kompilowane do wykonywalnych grafów DAG).

Czym różni się przepływ pracy AI od agenta AI?

Kanoniczne definicje Anthropic z 2024 roku: przepływy pracy to „systemy, w których LLM-y i narzędzia są orkiestrowane poprzez predefiniowane ścieżki kodu”, podczas gdy agenci „dynamicznie kierują własnymi procesami i użyciem narzędzi”. Aktualizacja na rok 2026 jest taka, że granica staje się fazą wewnątrz jednego systemu, a nie wyborem między dwoma systemami: agent wykonuje swój dynamiczny przebieg raz, na etapie planowania, i sam generuje predefiniowane ścieżki kodu.

Czy skompilowane przepływy pracy agentów są lepsze od agentów autonomicznych?

Dla powtarzalnych zadań o dobrze określonym kształcie — tak: skompilowany przepływ pracy jest tańszy w przeliczeniu na uruchomienie, wznawialny z wynikami z pamięci podręcznej i możliwy do przejrzenia, zanim się wykona. Dla eksploracji, nowych stanów błędów i decyzji wymagających osądu — nie: skompilowany plan to osąd zamrożony w momencie kompilacji, a te zadania wymagają osądu stosowanego na bieżąco. Praktyczny podział przebiega według liczby uruchomień: pierwsze uruchomienie zostaje na żywo, a kompiluje się wszystko, co będzie uruchamiane po raz drugi.

Które narzędzia kompilują dziś intencję agenta do deterministycznych artefaktów?

Cztery zweryfikowane przykłady według stanu na lipiec 2026. Dynamiczne przepływy pracy Claude Code: model pisze skrypt orkiestracyjny w JavaScripcie, środowisko uruchomieniowe go wykonuje, a zapisane skrypty stają się poleceniami wielokrotnego użytku. Rigorix: otwartoźródłowe, napisane w Ruście środowisko uruchomieniowe kompilujące zadania w języku naturalnym do grafów DAG wykonywanych w ramach ograniczeń polityk, budżetów i uprawnień. LangGraph: grafy trzeba skompilować przed uruchomieniem, z punktami kontrolnymi na granicach super-kroków. Temporal: przepływy pracy trwałego wykonywania, które utrwalają postęp agenta i wznawiają od punktu awarii.

Źródła