Dynamic Workflows: przestań liczyć, że LLM będzie pamiętał cały workflow

"Przecież napisałem mu to na początku"

Tak.

Tylko potem wydarzyło się:

• kilkadziesiąt tool calli,
• kilka failing testów,
• dużo przeczytanych plików,
• zmiana planu,
• wyniki subagentów,
• być może compaction contextu.

Po godzinie model może:

• pominąć punkt instrukcji,
• uznać zadanie za zakończone za wcześnie,
• nie wrócić do wcześniejszego TODO,
• zinterpretować "gotowe" inaczej niż Ty.

To nie oznacza, że Claude źle działa.

Oznacza, że używamy probabilistycznego modelu jako pamięci wymaganej kolejności kroków.

To zła odpowiedzialność.

Context window nie jest workflow engine'em

Mamy dwa osobne problemy.

Problem reasoning

Jak zaimplementować feature?

Claude jest do tego świetnym narzędziem.

Problem orchestration

Po implementation zawsze musi odbyć się review, po blockerach fix, a po fixie verification.

To da się zapisać deterministycznie.

implementation
-> review
-> blockers?
   yes -> fix -> verification -> review
   no  -> final verification

Model nie powinien "pamiętać", że ten graf istnieje.

Graf powinien istnieć poza pamięcią modelu.

Dynamic Workflows

Claude Dynamic Workflows rozwiązują właśnie ten rodzaj problemu.

Zamiast prowadzić orchestration turn-by-turn w jednej rozmowie, Claude może przygotować wykonywalny skrypt workflow.

Runtime wykonuje ten skrypt.

Workflow może:

• uruchamiać subagentów,
• robić fan-out równolegle,
• czekać na wyniki,
• przekazywać wyniki do kolejnych etapów,
• wykonywać warunki,
• wykonywać pętle,
• uruchamiać osobne verification passes.

Schemat:

Claude
-> tworzy workflow script
-> Workflow runtime
   +-- research agents
   +-- implementation
   +-- reviewer
   +-- tester
   +-- conditions
   +-- verification

Kluczowa różnica:

Kolejność kroków nie istnieje już wyłącznie jako zdanie sprzed 40 tysięcy tokenów.

Jest częścią wykonywalnej struktury.

Dwa różne loopy

To dobry moment na uporządkowanie pojęć.

Agent loop

W pojedynczym tasku:

Claude
-> tool
-> result
-> Claude
-> tool
-> result
-> ...

To pętla wykonywania jednego zadania przez agenta.

Workflow loop

Na wyższym poziomie:

implementation
-> review
-> blockers?
   yes -> fix -> review

To pętla pomiędzy etapami pracy.

Dynamic Workflow pozwala tę drugą warstwę zapisać jawnie.

Co zyskujesz?

1. Verification faktycznie się wydarzy

Jeśli jest w workflow, nie zależy od pamięci aktualnej sesji.

2. Duża ilość pracy nie musi zalewać jednego contextu

Subagenci dostają wydzielone zadania.

Workflow trzyma wyniki i przekazuje je dalej.

3. Parallelism jest jawny

Jeżeli review i test analysis mogą działać niezależnie:

implementation
-> review
-> tests
-> merge findings

nie musisz liczyć na to, że main agent sam optymalnie odtworzy tę strategię przy każdym wykonaniu.

4. Workflow można poprawiać

Jeżeli odkrywasz:

Po fixie powinien wrócić reviewer, nie tylko testy.

zmieniasz workflow.

Nie musisz pamiętać o dopisywaniu zdania do każdego kolejnego prompta.

Nie każdy task potrzebuje workflow

Jeżeli zadanie brzmi:

Napraw ten pojedynczy failing test.

zwykły Claude Code agent loop prawdopodobnie wystarczy.

Dynamic Workflow zaczyna mieć sens, gdy:

• zadanie ma kilka obowiązkowych etapów,
• korzystasz z wielu subagentów,
• potrzebujesz niezależnej verification,
• część pracy można wykonać równolegle,
• wymagane kroki zaczynają ginąć w długim context window.

Przykład z codziennego SDLC

Chcesz standard dla większej implementacji:

1. analyze requirements
2. inspect existing architecture
3. implement
4. run relevant tests
5. independent review
6. independent test analysis
7. fix blockers
8. re-run verification
9. final summary

Przed:

jeden duży prompt
-> mam nadzieję, że Claude pamięta 1-9

Po:

workflow
-> etapy 1-9 są jawne
-> Claude podejmuje decyzje wewnątrz etapów

To bardzo ważny podział odpowiedzialności:

Claude
= jak wykonać inteligentny krok

workflow
= jaki krok ma być wykonany i co następuje potem

Czy to już durable workflow engine?

Nie należy mieszać tych rzeczy.

Dynamic Workflow rozwiązuje orchestration zadania Claude i pozwala wyciągnąć control flow poza jeden context.

Jeżeli potrzebujesz workflow, który:

• czeka dwa dni na approval,
• musi przeżyć awarię całej platformy,
• reaguje na webhooki z kilku systemów,
• ma trwały stan niezależny od sesji,

wchodzisz w kategorię zewnętrznych durable orchestratorów.

Ale dla dużej części codziennego agentic codingu nie musisz od tego zaczynać.

Najpierw wyciągnij wymagane etapy z pamięci LLM-a do wykonywalnego workflow.

Wdróż to dziś

1. Znajdź task, dla którego piszesz długie "potem zrób..."

Dobry kandydat:

implement
-> test
-> review
-> fix
-> test

2. Rozpisz obowiązkowe etapy

Nie w formie prompta.

W formie grafu:

A
-> B
-> C
   fail -> D -> B
   pass -> E

3. Wykonaj zadanie jako Dynamic Workflow

Pozwól Claude przygotować workflow zamiast prowadzić całość wyłącznie turn-by-turn.

4. Obejrzyj wygenerowany skrypt

Sprawdź:

• czy obowiązkowe kroki są jawne,
• gdzie uruchamiane są subagenty,
• które etapy są równoległe,
• kiedy następuje verification,
• jaki jest warunek zakończenia.

5. Zapisz dobry workflow

Jeżeli jest to coś, co powtarzasz w SDLC, nie generuj całej struktury od zera przy każdym zadaniu.

Traktuj workflow jak kolejny artefakt engineeringowy.

Level complete

Poziom jest zaliczony, jeśli potrafisz odpowiedzieć:

Co się stanie, jeśli główny Claude zapomni instrukcję "na końcu uruchom verification"?

i odpowiedź brzmi:

Nic. Verification jest częścią wykonywalnego workflow, więc nie zależy od pamięci modelu.

Na ostatnim poziomie usuniemy jeszcze jedną zależność: konieczność uruchamiania całej pracy w sesji Claude Code na Twoim laptopie.

Materiały

• Dynamic Workflows / Claude Agent SDK cookbook