AI agenti jako zákazníci [Wiki]

Tato stránka je pouze pro čtení. Můžete si pouze prohlédnout zdrojový kód, ale ne ho měnit. Zeptejte se správce, pokud si myslíte, že něco není v pořádku.
====== AI agenti jako zákazníci ======

//Vytvořeno: **13.6.2026** | Aktualizováno: **~~LASTMOD~~**//

AI agenti začínají být novým typem zákazníka: ne člověk, který kliká ve webovém rozhraní, ale stroj, který používá API, zakládá účty, přijímá potvrzovací e-maily a platí za služby. Tento zápis shrnuje silné myšlenky z textu o „customers without heartbeats“ a dopadech na návrh API, identity a onboardingu.

===== Hlavní teze =====

Základní myšlenka je jednoduchá: budoucí zákazník softwaru nemusí mít lidský heartbeat. Může to být agent, který samostatně vyhodnotí, jaký nástroj použít, zavolá API, zpracuje výsledek a pokračuje v úkolu.

Z toho plyne důležitý posun. Software už nestačí navrhovat jen pro lidi a vývojáře. Je potřeba řešit, jestli ho umí efektivně používat i stroje.

===== Machine interface jako součást produktu =====

Dřív bylo API hlavně vývojářské rozhraní. Lidský vývojář si přečetl dokumentaci, pochopil kontext, ošetřil chyby a z velké JSON odpovědi si vybral jen to, co potřeboval.

U agentů je situace jiná. Odpověď API často končí přímo v context window modelu. Vše, co se do kontextu dostane, ovlivňuje další rozhodování agenta.

Praktický dopad:

  * velké JSON payloady spotřebovávají tokeny,
  * zbytečný boilerplate zhoršuje orientaci modelu,
  * nejasné názvy polí komplikují navazující akce,
  * nepřesné popisy nástrojů snižují šanci, že si je agent vůbec vybere,
  * špatně strukturované chyby znemožňují agentovi rozumně pokračovat.

Silná věta z původní myšlenky: JSON odpověď už není jen developer experience detail. Stává se výkonnostní charakteristikou cizího produktu, protože agent ji používá jako vstup pro další rozhodnutí.

===== Agent si API nevybírá jako člověk =====

Člověk je vůči špatnému API překvapivě tolerantní. Když už integraci jednou napíše, často ji drží roky, protože přepsání stojí čas.

Agent takhle loajální být nemusí. Pokud má k dispozici víc nástrojů, vybírá podle popisu, očekávaného výstupu a toho, jestli se mu nástroj hodí do aktuálního úkolu. Popis typu „získá data“ je slabý. Lepší popis říká:

  * co přesně se vrací,
  * kdy má smysl nástroj použít,
  * jaké jsou vstupy,
  * jak vypadají chyby,
  * co má agent zkusit při selhání.

Pro lidského vývojáře je dokumentace samostatná věc. Pro agenta je popis nástroje často přímo rozhodovací povrch.

===== MCP, REST a CLI nejsou hlavní bitva =====

Debaty o tom, jestli má být rozhraní přes MCP, REST API, CLI nebo jiný mechanismus, jsou důležité, ale nejsou tím nejpodstatnějším. Protokoly se budou měnit.

Důležitější otázka je pořadí:

  * nejdřív navrhnout rozhraní použitelné strojem,
  * až potom řešit konkrétní transport nebo protokol.

Zajímavý signál je, že některé firmy dnes publikují MCP servery dřív než klasické veřejné REST API. Není podstatné, jestli MCP zůstane dominantní protokol. Podstatné je, že první veřejné rozhraní těchto služeb už míří na agenty, ne na lidské vývojáře.

===== Skutečný problém je identita agenta =====

Historicky mělo přiznání „jsem agent“ spíš nevýhody. Agentní provoz mohl být blokovaný, throttlovaný nebo účtovaný jako scraping. Racionální strategie proto často byla tvářit se jako běžný uživatel nebo běžný skript.

To se začíná měnit. Pokud budou existovat ověření agenti, může identifikace přinášet lepší přístup místo horšího zacházení. Text zmiňuje tři vrstvy identity:

  * podpis požadavku může prokázat, kdo agenta vytvořil,
  * peněženka může prokázat, že agent umí zaplatit,
  * adresa umožní agentovi dokončovat běžné internetové flow.

Právě třetí bod je prakticky důležitý. Mnoho služeb na internetu stále předpokládá e-mailovou adresu: registrace, potvrzovací odkaz, faktura, reset hesla, notifikace, receipt. Bez adresy se agent zasekne ve flow, které nebylo navržené pro něj.

===== E-mail jako nudné, ale funkční primitivum =====

E-mailová adresa sama o sobě neprokazuje skutečnou identitu. Neříká, kdo jsi. Ale říká, kam ti služba může poslat potvrzení, odkaz, notifikaci nebo doklad.

To je důvod, proč je e-mail pro agenty zajímavý. Nevyžaduje, aby celý internet přijal nový standard. Funguje s existujícími signup flow už dnes.

[[https://agentmail.to/|AgentMail]] v tomhle kontextu není jen „služba na posílání e-mailů“. Je to pokus dát agentům vlastní inboxy, aby mohli projít běžnými procesy, které dnešní web už zná.

===== Co z toho plyne pro návrh služeb =====

Pokud má software počítat s agentními zákazníky, nestačí mít jen API. Je potřeba přemýšlet nad celým průchodem agenta službou.

Praktický checklist:

  * Má API stručné a předvídatelné odpovědi?
  * Vrací jen data, která agent opravdu potřebuje?
  * Jsou chyby strukturované tak, aby agent věděl, co zkusit dál?
  * Jsou popisy nástrojů napsané pro strojové rozhodování, ne jen pro člověka?
  * Umí se agent zaregistrovat?
  * Umí dokončit ověření přes e-mail?
  * Umí získat vlastní API token?
  * Umí zaplatit nebo projít billingem?
  * Je jasné, jak se rozlišuje legitimní agent od škodlivého bota?

===== Shrnutí =====

Nejsilnější myšlenka textu je, že AI agenti nejsou jen nový způsob, jak lidé ovládají software. Mohou být samostatnou třídou zákazníků.

To mění význam API, dokumentace, payloadů, chybových hlášek, identity i onboardingu. Software, který bude dobře použitelný stroji, může být v agentní ekonomice vybíraný častěji. Software, který stále předpokládá pouze lidského uživatele, může zůstat pro agenty neviditelný nebo nepoužitelný.

===== Zdroje =====

  * Původní text vložený do konverzace: „The customers without heartbeats are already here. Your API decides if you get them."
  * [[https://agentmail.to/|AgentMail]]