Beyond Dynamic Workflows: kiedy workflow wychodzi poza Claude
- data
- kategoria
- AI Agents
- także w
- Automation · AI Engineering · Engineering Practices
- czytanie
- 2 min / 415 słów
Dynamic Workflows rozwiązują bardzo konkretny problem:
analyze
-> implement
-> review
-> fix
-> verify
Zamiast liczyć, że Claude będzie pamiętał całą kolejność kroków, zapisujesz ją jako wykonywalny workflow.
To działa dobrze, dopóki większość pracy dzieje się wewnątrz świata Claude.
Problem zaczyna się wtedy, gdy workflow rozrasta się poza agenta.
Na przykład:
GitHub event
-> Claude analizuje problem
-> uruchom backend job
-> poczekaj na rezultat
-> wywołaj API
-> poczekaj na approval
-> zapisz stan
-> uruchom kolejnego agenta
-> stwórz PR
Tutaj Claude nadal może wykonywać inteligentne kroki.
Ale nie powinien być odpowiedzialny za pilnowanie całego systemu.
Claude nie musi być właścicielem całego workflow
To ważna zmiana.
Do tej pory mieliśmy:
Dynamic Workflow
-> Claude tasks
-> subagents
-> verification
Teraz możemy mieć:
external orchestrator
-> workflow
+-- Claude task
+-- backend job
+-- API call
+-- wait
+-- human approval
+-- kolejny Claude task
Claude staje się jednym z wykonawców.
Nie orkiestratorem całej infrastruktury.
Po co zewnętrzny orchestrator?
Wyobraź sobie workflow:
PR opened
-> Claude review
-> jeżeli blocking issue: komentarz
-> jeżeli wszystko OK: czekaj na CI
-> CI finished
-> jeżeli fail: uruchom investigation
-> jeżeli pass: czekaj na approval
-> po approval: kolejny krok
Tutaj pojawiają się problemy, których nie chcesz przechowywać w context window ani w pojedynczej sesji agenta:
- retries,
- timeouts,
- długie waity,
- webhooki,
- kolejki,
- concurrency,
- stan workflow,
- human approval,
- recovery po awarii.
Do tego istnieją narzędzia typu:
- Trigger.dev,
- Hatchet,
- Temporal,
- Inngest,
- Restate.
Trigger.dev oferuje m.in. durable tasks, queues, retries, checkpointing, długie waity i human-in-the-loop.
Hatchet ma podobny model oparty o durable tasks, workers i workflows z retries oraz checkpointingiem.
Temporal idzie jeszcze mocniej w stronę Durable Execution: workflow zachowuje stan i może wznowić pracę po crashu, outage albo nawet wielodniowym oczekiwaniu.
Inngest opisuje durable workflows uruchamiane przez event, schedule, webhook albo inną funkcję, z krokami, których wyniki mogą zostać zachowane i użyte po retry.
Dynamic Workflow vs external orchestration
Najprostszy mental model:
Dynamic Workflow
= jak Claude organizuje pracę agentów
External orchestrator
= jak cały system organizuje pracę Claude i wszystkiego dookoła
Przykład:
Trigger.dev
-> task: fetch PR
-> task: start Claude review
-> task: wait for CI
-> task: request approval
-> task: call deployment API
Claude nadal może wykonywać:
review
investigation
reasoning
fix generation
Ale retry API calla albo czekanie trzy godziny na approval nie powinno być problemem LLM-a.
Kiedy zostać przy Dynamic Workflows?
Jeżeli masz:
research
-> implementation
-> review
-> fix
-> verify
i wszystko dzieje się w jednej pracy agenta, nie komplikuj systemu.
Dynamic Workflow wystarczy.
Zewnętrzna orkiestracja zaczyna mieć sens wtedy, kiedy zauważasz:
Coraz więcej kroków mojego workflow nie jest pracą Claude.
Na przykład:
wait
webhook
database update
queue
approval
external job
retry
Wtedy dokładanie kolejnych instrukcji do agenta jest złym kierunkiem.
Przykład: failing CI
W wersji Claude-first:
Dynamic Workflow
-> investigate
-> fix
-> test
-> review
W większym systemie:
CI event
-> Trigger.dev / Hatchet / Temporal
-> start Claude investigation
-> result
-> run deterministic CI job
-> pass?
no -> Claude fix
yes -> wait for approval
-> create PR
Zauważ różnicę.
Claude podejmuje decyzje tam, gdzie potrzebne jest reasoning.
Orchestrator pilnuje reszty.
Wdróż to dziś
Nie instaluj orchestratora tylko dlatego, że istnieje.
Weź workflow z artykułu o Dynamic Workflows i zaznacz każdy krok jako:
CLAUDE
albo:
SYSTEM
Na przykład:
analyze failure -> CLAUDE
find root cause -> CLAUDE
run CI job -> SYSTEM
wait for webhook -> SYSTEM
review implementation -> CLAUDE
wait for approval -> SYSTEM
create PR -> SYSTEM
Jeżeli prawie wszystko jest CLAUDE, zostań przy Dynamic Workflows.
Jeżeli duża część staje się SYSTEM, sprawdź narzędzia typu Trigger.dev, Hatchet, Temporal, Inngest albo Restate.
Level complete
Poziom jest zaliczony, jeśli przestajesz traktować Claude jako właściciela całej orkiestracji i potrafisz oddzielić:
reasoning
od:
durable orchestration
Claude powinien robić to, w czym jest dobry.
System powinien pilnować rzeczy, które powinny być deterministyczne.