Představme si asistenta, který dostane jednoduchý úkol: objednat náhradní nabíječku. Najde obchod, stiskne tlačítko a oznámí splněno. Jenže obchod ještě čeká na výběr varianty, košík se nezměnil nebo platba vůbec nezačala. Stroj udělal přesně to, co mu dovolilo rozhraní. Člověk přesto nemá to, co si objednal. Právě v téhle mezeře mezi akcí a výsledkem se bude rozhodovat, zda nám nákupní AI ušetří práci, nebo přidá další kontrolní směnu.
Dobrým podkladem k téhle debatě je Latch, který jsme představili v aktuálních Rychlých zprávách. Nabízí lákavou zkratku: vložit do webu jeden skript a zpřístupnit jeho vyhledávání, košík, formuláře a navigaci AI agentům. To je užitečný integrační nápad. Zároveň na něm velmi dobře vyniká, proč bychom si měli dávat pozor na slovo „úspěch“.
Web přestává být obrázkem, do kterého se trefujeme
Člověk v obchodě obvykle pozná, kde hledat zboží a které tlačítko přidává položku do košíku. Automatický asistent musí význam ovládání nějak odvodit, případně dostat jeho přesný popis. WebMCP umožňuje stránce nabídnout akce jako pojmenované nástroje s popsanými vstupy. Místo pokynu „najdi někde tlačítko a klikni“ tak může agent dostat například nástroj pro vyhledání produktu.
Latch tuto práci zjednodušuje tím, že prohlédne existující prvky stránky a nástroje z nich sestaví automaticky. Nepotřebuje k tomu samostatný MCP server. Nástroj pro formulář vyplňuje pole a vyvolává jeho odeslání, nástroj pro košík kliká na nalezený ovládací prvek. Pokud potřebné rozhraní WebMCP v prohlížeči není dostupné, inicializace podle kódu skončí bez registrace nástrojů. Vložit skript tedy neznamená zajistit podporu každému návštěvníkovi.
Přínos je srozumitelný i bez slibů o revoluci v nakupování. Malý provozovatel nemusí každou běžnou akci ručně popisovat od začátku. Zůstává u své stránky a jejího ovládání, místo aby vedle ní budoval druhou službu. Úspora integrační práce ale neodstraňuje povinnost zjistit, co takto zpřístupněná akce skutečně udělá.
„Klikl jsem“ není potvrzení objednávky
Nejzajímavější část příběhu najdeme v rozdílu mezi vysvětlením produktu a jeho implementací. Průvodce na webu Latch správně varuje, že pouhý příznak úspěchu agentovi nestačí: potřebuje skutečné výsledky vyhledávání, aktualizovaný košík nebo vytvořenou rezervaci. Zároveň tvrdí, že Latch skutečný strukturovaný výsledek obsluhy stránky vrací automaticky. To už je silnější slib, než jaký dokládá přečtený veřejně poskytovaný skript.
V aktuálně dostupném souboru latch.js nástroj add_to_cart vybere tlačítko, zavolá jeho click() a vrátí text, že na ně klikl. V této obsluze nečeká na potvrzení serveru a nečte nový obsah ani cenu košíku. Podobně nástroj pro formulář po vyvolání odeslání vrací zprávu, že formulář odeslal; samotná tato větev nepotvrzuje, že rezervace vznikla. Ani vyhledávání v této implementaci nevrací slíbený seznam nalezených položek, ale zprávu o provedené akci.
To není důkaz, že nákup vždy selže. Je to důkaz, že návratová zpráva tohoto nástroje sama úspěšný nákup nepotvrzuje. Prohlížeč nebo agent může výsledek následně zjistit jinou cestou. Takový další krok ale musí opravdu existovat a pracovat s aktuálním stavem. Článek vychází z dokumentace a čtení veřejného skriptu, nikoli z provozního testu v konkrétním obchodě.
Rozdíl není slovíčkaření. I obyčejný webový formulář může po pokusu o odeslání skončit u validace povinného pole. Dostupnost zboží se může změnit a požadavek může odmítnout server. Když si agent zamění zprávu o vlastním pohybu za potvrzení výsledku, jen přesunul nejistotu o jednu vrstvu dál. Člověk už nehlídá tlačítko; hlídá asistenta, který o tlačítku mluví příliš sebejistě.
Bezpečné objevování neznamená neškodné odesílání
Latch zdůrazňuje, že objevování prvků stránky je pouze pro čtení. To odpovídá rozlišení, které je potřeba zachovat: najít formulář a popsat jeho pole je jedna činnost, vyplnit ho a vyvolat odeslání druhá. Ve chvíli zavolání nástroje už skript mění stav stránky a může spustit její běžné akce. Označení „read-only“ proto není univerzálním bezpečnostním razítkem pro celý postup.
V přečtených obsluhách pro košík a formuláře není vlastní samostatný krok lidského schválení. Případné potvrzení tedy musí zajistit jiná část řetězce, například prohlížeč, agent nebo samotná aplikace. Neznamená to, že Latch obchází jejich ochrany. Znamená to, že je nesmíme automaticky připsat skriptu, který pouze propojí existující ovládání s voláním nástroje.
Na Radyzu jsme už popsali dokončování nákupů přes WebMCP u Shopify s potvrzením kupujícím. Podstatný je právě rozdíl mezi možností objednávku připravit a oprávněním ji závazně odeslat. Tentýž princip má smysl u rezervace placené služby nebo změny zákaznických údajů. Přesnější popis tlačítka sám neřeší, kdo a za jakých podmínek smí rozhodnout.
Z českého pohledu navíc stojí za pozornost obyčejné popisky. Detekce košíkových tlačítek ve skriptu hledá anglické výrazy a určité technické atributy či třídy. České „Do košíku“ bez dalších rozpoznaných značek proto nelze považovat za automaticky pokryté. To není rozsudek nad použitelností projektu, ale praktický důvod nevěřit univerzálnímu příslibu dřív, než někdo projde vlastní web.
Zelená kontrolka může měřit něco jiného než zákazník
Latch má i obchodní model: otevřený skript doplňuje volitelný hostovaný přehled používání. Licence zveřejněného kódu je MIT a provozovatel může soubor hostovat sám. Analytika se v poskytovaném skriptu zapíná projektovým klíčem a odesílá mimo jiné název nástroje, výsledek jeho volání a cestu stránky. To je jiná vrstva než samotná registrace nástrojů; provozovatel by ji měl posuzovat zvlášť.
Také tady se vrací otázka významu výsledku. Analytická obálka označí dokončené volání za úspěšné, pokud jeho návrat neobsahuje příznak chyby. Jestliže obsluha košíku vrátí zprávu o kliknutí, může takový přehled zaznamenat úspěšné volání, aniž by tím potvrdil přidání správného zboží. Metrika nemusí být chybná. Chybný by byl náš závěr, že počítá dokončené objednávky.
Pro obchodníka je to důležité i ekonomicky. Návštěvy agentů a jejich volání vypadají jako nová kategorie návštěvnosti, kterou bude lákavé sledovat a optimalizovat. Platit se ale bude pořád za skutečné nákupy, ne za správně vyvolané události v prohlížeči. Přehled, který měří technický průchod nástrojem, potřebuje vazbu na obchodní výsledek stejně jako každá jiná analytika.
Podle nás má první rozumný pilot vypadat méně slavnostně než oznámení „jsme připraveni na AI“. Začít vyhledáváním a akcemi s malým dopadem. U každého nástroje sepsat, co jeho odpověď opravdu potvrzuje. Na testovacím prostředí projít neplatný formulář, nedostupné zboží i opožděnou odpověď a ověřit, že agent nehlásí dokončení předčasně. Teprve potom přidávat závazné kroky s jasným schválením.
Tohle je redakční doporučení, nikoli certifikační postup projektu. Jeho smysl je prostý: nepřenášet účet za špatně definovaný výsledek na zákazníka. Jednořádková integrace může být poctivá úspora práce. Jednořádkové ujištění, že tím máme hotovo, už ne.
Latch ukazuje užitečnou cestu, jak dát agentům na webu čitelnější ovládání. Zároveň připomíná, že nejdůležitější rozhraní často začíná až za tlačítkem: co se opravdu stalo, kde to lze ověřit a kdo směl dát poslední souhlas. Asistent, který umí kliknout, je pomocník. Asistent, který pozná, kdy ještě nemá říkat „splněno“, teprve začíná být spolehlivý.
