Automatizace e-shopu s AI agenty: kde workflow potřebuje člověka

Co má postup e-shopu vlastně přinést

Autor provozuje přibližně deset specializovaných nastavení v Codexu a repozitáři. Hledá cestu k širší automatizaci, ale diskuse o firemních agentech pro e-commerce ukazuje jednoznačný problém: jak rozšířit automatizaci bez toho, aby se ztrácela odpovědnost a vznikaly tiché chyby?

Proto nestačí přejít přímo k autonomní síti agentů. Smysluplnější je kombinace oddělených vrstev kontextu, specializovaných rolí a převážně deterministického toku práce.

Odborně jde o stavový workflow s lidským dohledem. Agent zde není samostatný kolega s volnou odpovědností. Je to omezený automatický krok v předem stanoveném procesu. Deterministická část řídí pořadí a podmínky, agent pomáhá s jasně vymezeným rozhodnutím a člověk přebírá rizikové nebo nejednoznačné případy.

Ve srovnání s tím, co diskuse někdy označuje jako „multiagentní systém“, je zásadní rozdíl v odpovědnosti. Více rolí bez sdíleného stavu a výstupního schématu nemusí vytvořit lepší automatizaci. Naopak přidává koordinační daň a další místa, kde se může ztratit informace.

Kde agent pomůže a kde už ne

Automatizaci je vhodné stavět podle ověřitelnosti a nevratnosti akce. Agent se hodí například k:

• klasifikaci zákaznického požadavku a výběru předem definovaného postupu;
• návrhu popisu produktu, který následně projde kontrolou;
• porovnání údajů objednávky, skladového záznamu a faktury;
• návrhu odpovědi podpory z omezené znalostní báze.

Bez lidského schválení by agent neměl samostatně potvrzovat refund, měnit cenu, upravovat DPH, přepisovat stav objednávky ani publikovat nabídku na marketplace. Stejně tak úkoly s nejasným zadáním nebo kvalitativní rozhodnutí se nezlepší automaticky tím, že je přidělíme „autonomnímu agentovi“. Člověk musí zůstat na řídicí pozici, která může proces zastavit, opravit zadání a převzít případ.

Praktické know-how z diskuse tedy zní: maximalizujte determinismus tam, kde lze pravidla a výsledek přesně ověřit, a ponechte AI jen na omezeném podílu rozhodnutí. Postupujte tak, aby každý agent dostal jen úzce definovaný scope.

Jak to funguje pod kapotou a kde má postup limity

Předání mezi agenty není přenosem stavu. Znamená to většinou nový prompt a další vzorkování tokenů. Co není uvedené ve strukturovaných polích, může pro následujícího agenta prakticky chybět. Souhrn na rozhraní může například odstranit rozlišení mezi výměnou a refundem, aniž by systém vyhlásil chybu.

Při překročení kontextového okna se navíc může payload tiše zkrátit. Systém pak pokračuje s neúplným zadáním. Je proto potřeba průběžně kontrolovat, zda se předávaná data zachovala v očekávaném rozsahu. Chyba se může přenést dál a celý řetězec pak skončí chybným výsledkem bez viditelného incidentu.

V sekvenčním procesu se chyby také sčítají. Při pěti nezávislých krocích s 80% věrností každého z nich není výsledná věrnost 80 %: v tomto zjednodušeném modelu vychází 0,8^5 = 32,768 %, tedy zaokrouhleně 32,8 %. U korelovaných kroků tento výpočet neplatí.

Síť agentů se proto vyplatí hlavně při paralelizovatelných úlohách, jejichž výstupy lze sloučit do jednoho schématu. Pro sekvenční řetěz je vhodnější jednoduchý graf nebo stavový engine.

Největší limity má přechod z jednoho dobře nastaveného agenta na velkou síť rolí. Více specializovaných promptů bez sdíleného stavu, výstupního schématu a explicitního dohledu přidává více přenosů, více výzev pro kontrolu a méně místa pro samotný úkol.

Jak postup navrhnout v e-shopu

Nejprve vytvořte mapu rozhodovacích bodů. U každého bodu uveďte vlastníka dat, pravidlo, možné výstupy a způsob kontroly. Potom rozdělte práci na tři vrstvy:

1. Deterministický workflow: načtení objednávky, kontrola stavu, výpočet, volba schválení, zápis a retry.
2. Agentní krok: klasifikace, návrh textu, vyhledání ve znalostní bázi nebo porovnání údajů.
3. Lidská eskalace: refund, změna ceny, DPH, právní text, výjimka nebo opakovaný nesoulad.

Mezi vrstvami přenášejte strukturovaná data, ne volný souhrn. Příklad schématu může obsahovat order_id, action, amount, currency, vat_rate, reason, evidence a confidence. Akce má mít jasný stav, například pending, approved, rejected nebo needs_review.

Dedikované nástroje podporují jednotlivé části návrhu. n8n nebo Temporal jsou vhodné pro stavovou páteř, integrace, timeouty, retry a kontrolu skutečného zápisu. LangGraph umožňuje větvení, checkpointing a lidský interrupt. OpenAI Agents SDK je užitečný pro úzké handoffy, guardrails a tracing. Pydantic nebo JSON Schema definují kontrakty dat; LangSmith a OpenTelemetry pomáhají sledovat rozhodnutí a předání.

Audit však neobsahuje přímé srovnání Paperclipu, OpenClawu a Hermese s tímto návrhem. Z diskuse proto nelze vyvozovat, který orchestrátor bude pro konkrétní e-shop nejlepší. Codex může zůstat užitečnou vývojářskou vrstvou, ale sám o sobě nenahrazuje produkční workflow, audit ani schvalování.

Co si z toho vzít

• Začněte mapou procesu, dat a bodů, ve kterých je nutné lidské rozhodnutí.
• Používejte agenty pro omezená rozhodnutí, ne jako vlastníky celého procesu.
• Předávejte mezi kroky strukturovaná data a kontrolujte skutečný zápis.
• Drahé a nevratné akce nechávejte schválit člověkem.
• Sledujte úspěšnost úkolů, podíl eskalací, náklad na objednávku a chyby, které prošly s odpovědí 200 OK.
• Nepřidávejte více rolí, dokud neprokážete výhodu oproti jednoduššímu workflow.

Více agentů je vhodné zavádět tam, kde lze práci paralelizovat a výstupy sloučit do společného schématu.

Deterministický workflow:
- načte data
- provede kontrolu
- vypočítá výsledek
- rozhodne, zda je nutné schválení
- provede zápis a případně retry

Agent:
- pracuje pouze s úzce definovaným scope
- vrací strukturovaný výstup
- nepřebírá nevratné akce

Člověk:
- schvaluje refund, změnu ceny, DPH, právní text nebo výjimku
- může proces zastavit, opravit zadání a převzít případ

Předávaná data:
order_id, action, amount, currency, vat_rate, reason, evidence, confidence, status