Kolikrát se ti stalo, že jsi pustil Claude Code nebo Cursor na větší úkol a agent se zasekl ve smyčce? Pět minut čte stejný soubor, pak se pokusí upravit kód během review fáze, nebo nasadí změnu do produkce dřív, než proběhly testy. Píšeš další a další instrukce do promptu, měníš model za větší, a výsledek je pořád stejně nepředvídatelný.
Problém není v tom, že jsou modely hloupé. Problém je v tom, že agent dostane 30 nástrojů a otevřený prostor — a nikdo mu neřekne, co smí použít v jaké fázi. Řešení, které dnes používají produkční týmy, se jmenuje Statewright: open-source state machine guardrails, které omezují nástroje agenta podle aktuální fáze úkolu. V tomto článku ti ukážu, jak to nasadit do svého Claude Code workflow za 15 minut.
Proč větší model nepomůže
Běžná reakce na nepředvídatelného agenta je výměna modelu. Sonnet za Opus, Opus za novější Opus, přidat další systémový prompt, zvětšit kontext. To někdy pomůže na okamžik — a pak se zase dostaví ta samá smyčka. Důvod je prostý: model dostává prostor na to, aby si vybíral z desítek nástrojů, a žádná struktura mu neříká, co smí kdy použít.
Tým za Statewrightem to formuluje takhle: agenti jsou návrhy, stavy jsou zákony. Model navrhne, co by udělal, ale state machine tvrdě vynucuje, jaká akce je v dané fázi vůbec dostupná. Výsledek podle jejich SWE-bench experimentů: lokální modely pod 14 GB, které samy o sobě selhávaly v 8 z 10 případů, se stejnými úkoly a stejným hardwarem zvládly 10 z 10. Není to magie — je to zúžení prostoru.
Observability ti řekne, co se pokazilo poté. State machine zabrání tomu, aby se to pokazilo vůbec.
To je rozdíl, který cítíš v produkci. Sledovat trace s 400 kroky a dohledávat, kde se agent zlomil, je drahé. Zabránit agentovi spustit Edit v plánovací fázi je zadarmo.
Jak state machine pro agenta funguje
Koncept je starý jako programování samo, ale v kontextu AI agentů se teprve rozmáhá. Místo toho, aby měl agent přístup ke všem nástrojům pořád, definuješ pracovní postup jako konečný automat — sérii stavů, přechodů a pravidel. Každý stav má:
- Povolené nástroje — jen ty, které dávají v této fázi smysl
- Podmínky přechodu — co se musí stát, aby agent mohl pokročit dál
- Instrukce pro model — stručný popis, co teď má a nesmí dělat
Typický bugfix workflow má čtyři fáze: plánování → implementace → testování → dokončení. V plánovací fázi má agent k dispozici jen Read, Grep, Glob — čte kód, chápe problém, nic nemění. Až když je plán hotový, přejde do implementace, kde se odemknou Edit a omezený Bash (bez git push a bez destruktivních operací). V testovací fázi povolíš jen konkrétní testovací příkazy. Finální fáze může vyžadovat tvůj zásah.
Když se agent pokusí zavolat nástroj, který v aktuální fázi není povolený, dostane odmítnutí se zprávou: „V fázi planning jsou dostupné jen Read/Grep/Glob. Pro úpravu kódu přejdi do implementing zavoláním statewright_transition." Model si pak sám přeformuluje plán místo toho, aby se mlčky zhroutil.
Instalace v 15 minutách
Statewright funguje jako plugin přes Model Context Protocol. Instalace do Claude Code:
/plugin marketplace add statewright/statewright
/plugin install statewright
Po dokončení se otevře prohlížeč, kde si vytvoříš účet a vygeneruješ API klíč. Ten vložíš zpět do Claude Code a můžeš začít. Pro Cursor nebo Codex je postup podobný — Statewright běží jako samostatný MCP gateway, který sedí mezi agentem a jeho nástroji.
Spuštění workflow:
❯ start the bugfix workflow — fix the failing tests in calc.py
◆ [statewright] Workflow activated: bugfix
◆ Current phase: planning. Let me read the code first.
Read 2 files
[statewright] planning => implementing
◆ Edit calc.py: 1 line changed
[statewright] implementing => testing
◆ Bash: pytest -x — 7 passed
[statewright] testing => completed
◆ Workflow complete. 46 seconds.
Klíčové je, že přechody mezi stavy nejsou na modelu — na nich je state machine. Model navrhne „chci editovat", ale jestli editace opravdu proběhne, rozhoduje engine v Rustu, který běží deterministicky bez LLM v smyčce.
Praktické workflow, které dnes stojí za to nasadit
Ne každý úkol potřebuje state machine. Tam, kde agent udělá jednu úpravu a skončí, je to overkill. Statewright se vyplatí v těchto případech:
1. Bugfix workflow. Agent musí přečíst kód, pochopit příčinu, navrhnout fix, ověřit testy. Bez struktury často skočí z prvního Read rovnou k Edit bez pochopení problému — nebo naopak nekonečně čte bez akce. State machine ho donutí dodržet pořadí.
2. Code review. V review fázi by agent nikdy neměl editovat kód — má jen číst, hodnotit a vypsat seznam připomínek. To je přesně ten případ, kdy state machine zabraňuje zničení rozpracovaného PR.
3. Refaktoring velkých souborů. Agent dostane rozsáhlý úkol, state machine ho rozsekne na menší fáze (každá s vlastním testem), a mezi fázemi vynutí git commit. Pokud se něco rozbije, máš granulární historii.
4. Multi-model routing. Statewright umožňuje přiřadit každé fázi jiný model — například rychlý Haiku na diagnostiku, výkonný Opus na implementaci, Sonnet na review. Tohle je po vzoru gpt-5.6 model routing: různé fáze mají různé nároky na kvalitu vs. rychlost.
Hranice, na kterou narazíš
Statewright není stříbrná kulka. Záležitosti, na které si dej pozor:
Model musí být dostatečně velký. Autoři uvádějí prahovou hranici kolem 13 GB. Pod tím mají lokální modely problém se samotnou úpravou souborů — znají chybu, ale neumí seříznutou editaci, místo toho přepíšou celý soubor. State machine tenhle limit nezvedne; prostě jasně ukáže, kde leží.
Definice workflow je ruční práce. Začneš s předpřipravenými šablonami (bugfix, review, feature), ale pro specifické týmové procesy si workflow napíšeš sám. Má smysl začít jedním a postupně přidávat další.
Integrace závisí na klientovi. Per-state model routing funguje nativně jen u klientů, kteří umí programově přepínat model (Pi, Rust harness). U jiných je routing spíš doporučení než tvrdé pravidlo.
Není náhrada za evaluace. State machine omezí nekázeň agenta, ale nezměří, jestli jeho výstup je správný. Obojí potřebuješ — struktura zabraňuje chaosu, evaly kontrolují výsledek.
Kdy použít state machine a kdy ne
Pokud používáš Claude Code nebo Cursor na jednorázové úkoly — rychlý skript, jedna funkce, oprava překlepu — state machine přidává režii, kterou nepotřebuješ. Agent zvládne úkol bez ní.
Pokud ale agenta používáš systematicky na složitější agentic workflow — bugfixing nad velkým kódem, refaktoring modulů, multi-krokovou automatizaci — tam se ti Statewright vyplatí už po několika málo nasazeních. Místo toho, abys hlídal, jestli agent zase nesmazal špatnou věc nebo neudělal git push dřív, než se testy zezelenají, tenhle hlídání převedeš na stroj.
Závěr: méně prostoru, méně selhání
Trend v AI agentech v roce 2026 nejde směrem „větší modely, delší prompt". Jde směrem „menší, kontrolovaný prostor, ve kterém model operuje". Statewright je jednou z nejkonkrétnějších implementací tohoto trendu — open-source, Rust-based, funguje přes MCP s tvými stávajícími nástroji.
Pokud chceš začít, nainstaluj plugin, vezmi jednu rutinu (třeba bugfix) a spusť ji se state machine na cvičném repozitáři. Změř si průměrný počet kroků agenta a počet nutných zásahů před nasazením a po něm. Podle všech dostupných dat uvidíš rozdíl — méně kroků, méně zaseknutí, předevětší předvídatelný výsledek. A přesně to od agentů v produkci potřebuješ: ne geniálnost, ale spolehlivost.
