AI agent vs. chatbot (2026): rozdíly a kdy co použít

Pokud hodnotíš konverzační AI pro podporu, prodej nebo interní nástroje, pravděpodobně sis všiml, že dodavatelé používají výrazy „chatbot“ a „AI agent“ velmi odlišně podle toho, co prodávají. Některé produkty označené jako „AI agent“ jsou jen tenké obaly kolem jazykového modelu bez přístupu k nástrojům. Některé produkty označené jako „chatbot“ zvládají více autonomního uvažování než systémy, které si říkají agenti.

Tento článek definuje tři kategorie konverzačních AI systémů podle jejich architektury, vysvětluje, čeho je každá z nich skutečně schopná, a popisuje, kdy kterou použít. Cílem je dát ti dostatečný technický základ, abys produkty hodnotil podle jejich skutečné architektury, ne podle brandingu.

Poznámka k terminologii

Odvětví se zatím neshodlo na konzistentních definicích, proto tento článek používá tři kategorie:

1. Pravidlový chatbot: Systém postavený na klasifikaci záměrů, extrakci entit a skriptovaných dialozích. Při generování odpovědí nepoužívá jazykový model. Jde o tradiční architekturu chatbota, která existuje od 10. let 21. století.

2. LLM chatbot (nebo copilot): Systém, který používá velký jazykový model k porozumění a generování odpovědí, ale funguje ve vzoru požadavek, odpověď, bez autonomního používání nástrojů nebo vícekrokového uvažování. Do této kategorie spadá mnoho produktů označovaných na trhu jako „AI chatbot“. Jsou flexibilnější než pravidloví chatboti, protože LLM zvládá otevřený jazyk, ale neprovádějí akce v externích systémech ani neplánují vícekrokové workflow.

3. AI agent: Systém postavený kolem LLM, který dokáže uvažovat o úkolech, používat nástroje, udržovat paměť napříč interakcemi a autonomně vykonávat vícekroková workflow. LLM funguje uvnitř smyčky, ve které pozoruje, uvažuje, jedná a vyhodnocuje, zda je úkol hotový.

Autonomie a schopnosti rostou zleva doprava. Většina produktů označovaných v roce 2026 jako „AI chatbot“ leží někde na tomto spektru.

Zbytek článku pokrývá všechny tři kategorie, i když většina architektonických detailů se týká pravidlových chatbotů a AI agentů, protože mezi nimi je největší rozdíl. Sekce o LLM chatbotech je kratší, protože architektonicky jde o omezenou verzi AI agenta: stejný jazykový model, ale bez smyčky používání nástrojů.

Co je pravidlový chatbot?

Pravidlový chatbot vede konverzace s uživateli přes text nebo hlas pomocí předdefinované logiky. Je postavený na kombinaci klasifikace záměrů, extrakce entit a skriptovaných dialogů.

Jak pravidloví chatboti fungují

Typická architektura chatbota má tři komponenty:

1. Natural Language Understanding (NLU): Analyzuje zprávu uživatele, aby určila záměr (co uživatel chce) a extrahovala entity (konkrétní data, například data, názvy produktů nebo čísla objednávek). Většina NLU systémů používá kombinaci regex vzorů, shody klíčových slov a trénovaných klasifikátorů.

2. Dialogue Manager: Stavový automat, který určuje další krok podle aktuálního stavu konverzace a rozpoznaného záměru. Každý stav má sadu možných přechodů a Dialogue Manager postupuje podle definovaného toku.

3. Response Generator: Načte šablonovanou odpověď spojenou s aktuálním stavem. U jednoduchých chatbotů jde o vyhledávací tabulku. U o něco sofistikovanějších obsahuje šablona sloty, které se vyplní extrahovanými entitami.

Zjednodušený tok vypadá takto:

User: "What's the status of order #12345?"
  → NLU: intent=order_status, entity={order_id: 12345}
  → Dialogue Manager: state=check_order → call order_status_api(12345)
  → Response: "Order #12345 shipped on April 7 and is expected by April 11."

Architektura vypadá takto:

To funguje dobře pro problémy s uzavřenou doménou, kde je sada možných záměrů malá a dobře definovaná. Tímto způsobem lze postavit FAQ bota, plánovač schůzek nebo nástroj pro kontrolu stavu objednávky.

Omezení pravidlové architektury

Model stavového automatu se rozpadá, když se konverzace stanou nepředvídatelnými. Konkrétně:

• Rigidní taxonomie záměrů: Každý požadavek uživatele se musí namapovat na předdefinovaný záměr. Pokud uživatel něco vyjádří způsobem, který NLU model neviděl, požadavek spadne do fallback handleru. S rostoucím počtem záměrů se údržba taxonomie a vyhýbání překryvům mezi podobnými záměry stává významnou technickou zátěží.

• Žádné uvažování napříč replikami: Dialogue Manager sleduje pevný graf. Nedokáže kombinovat informace z více replik, aby udělal úsudek, zvážil kompromisy nebo přizpůsobil svůj postup podle kontextu.

• Křehká extrakce entit: Tradiční vyplňování slotů funguje pro strukturované vstupy (data, čísla, produktové SKU), ale má potíže s otevřenými popisy, nejednoznačnými odkazy nebo vícedílnými požadavky.

• Lineární škálování práce: Podpora nového případu použití znamená definovat nové záměry, nové dialogové toky, nové šablony odpovědí a nový integrační kód. Každý přírůstek úměrně zvětšuje plochu pro údržbu.

Hlubší pohled na to, jak se architektury chatbotů v průběhu let vyvíjely, najdeš v článku Od NLP chatbotů ke generativní AI.

Co je AI agent?

AI agent je systém postavený kolem velkého jazykového modelu (LLM), který dokáže uvažovat o úkolech, používat nástroje, udržovat paměť napříč interakcemi a rozhodovat o dalším postupu bez sledování skriptovaného toku.

Termín „agent“ v tomto kontextu pochází z tradice výzkumu AI, kde agent označuje jakýkoli systém, který vnímá své prostředí a provádí akce k dosažení cílů. Ve vlně LLM aplikací v letech 2024-2026 výraz „AI agent“ konkrétně označuje systémy, které používají LLM jako uvažovací engine ve smyčce zahrnující pozorování, plánování, provádění nástrojů a vyhodnocení.

Jak AI agenti fungují

Jádrem architektury AI agenta je smyčka uvažování (někdy nazývaná ReAct smyčka podle článku ReAct, který tento vzor formalizoval). Smyčka má čtyři fáze:

1. Observe: Agent přijme zprávu uživatele spolu s historií konverzace, systémovými instrukcemi a případným načteným kontextem (např. relevantními články z báze znalostí).

2. Reason: LLM zpracuje veškerý dostupný kontext a rozhodne, co dělat dál. Může odpovědět uživateli přímo, položit upřesňující otázku nebo zavolat nástroj. Krok uvažování je místo, kde se agent nejvíce liší od chatbota: místo sledování stavového grafu LLM vygeneruje plán podle svého porozumění úkolu.

3. Act: Pokud se agent rozhodne použít nástroj, vygeneruje strukturované volání funkce (např. search_knowledge_base(query="refund policy for damaged items") nebo create_ticket(customer_id=456, issue="shipping delay")). Systém funkci spustí a vrátí výsledek agentovi.

4. Evaluate: Agent zkontroluje výstup nástroje a rozhodne, zda je úkol hotový, nebo zda je potřeba další krok. Pokud je nutná další práce, smyčka se opakuje od fáze uvažování.

Tady je konkrétní příklad této smyčky v akci:

User: "I ordered a laptop last week but received a monitor instead. 
       I need the right item shipped and a return label for the monitor."

Agent reasoning loop:
  [Reason] User has two needs: correct item shipment + return label.
           Need to look up the order first.
  [Act]    lookup_order(customer_email="user@example.com", timeframe="7d")
           → Returns: Order #7891, laptop SKU-A100, shipped monitor SKU-B200
  [Reason] Order found. Wrong item confirmed. Need to initiate exchange 
           and generate return label.
  [Act]    initiate_exchange(order_id=7891, correct_sku="SKU-A100")
           → Returns: Exchange #EX-442 created, shipping in 1-2 days
  [Act]    generate_return_label(order_id=7891, item_sku="SKU-B200")
           → Returns: Label URL https://...
  [Evaluate] Both tasks complete. Compose response.
  
Agent: "I found your order #7891. The correct laptop (SKU-A100) will ship 
        within 1-2 business days. Here's your return label for the monitor: 
        [link]. Drop it off at any carrier location."

Klíčový rozdíl oproti přístupu chatbota: nikdo nemusel předem definovat záměr „order_wrong_item_exchange_and_return“ ani vytvářet konkrétní dialogový tok pro tento scénář. Agent problém rozložil, zavolal správné nástroje ve správném pořadí a sestavil odpověď.

Používání nástrojů a volání funkcí

Používání nástrojů (také nazývané volání funkcí) dává AI agentům schopnost působit na svět, nejen generovat text. LLM dostane seznam dostupných nástrojů s jejich schématy (názvy parametrů, typy, popisy) a může se rozhodnout, že kterýkoli z nich během smyčky uvažování vyvolá.

Běžné kategorie nástrojů pro AI agenty orientované na zákazníky zahrnují:

Schéma nástroje funguje jako smlouva mezi LLM a externím systémem. Dobře navržené schéma dává LLM dostatek informací k výběru správného nástroje a předání správných parametrů bez dodatečného promptování.

Pokud chceš vidět používání nástrojů postavené od nuly, náš podrobný návod na vytvoření AI agenta, který provádí skutečné akce, přidává přesně jeden takový nástroj: popsaný HTTP požadavek, který agent volá uprostřed konverzace, zdarma a bez kódu. Aby se tyto zápisové akce spouštěly ve správném pořadí a až po vyhledání objednávky, přidáš podmínku spuštění a předáš id dál.

Paměť a správa kontextu

Chatboti obvykle ukládají stav konverzace jako sadu vyplněných slotů (např. order_id=12345, intent=order_status). AI agenti potřebují bohatší model paměti, protože zpracovávají otevřené konverzace, ve kterých se relevantní informace může objevit kdykoli.

Většina implementací AI agentů používá více vrstev kontextu:

• Historie konverzace: Surová sekvence zpráv v aktuální relaci.
• Pracovní paměť: Mezivýsledky z volání nástrojů a kroků uvažování, které ovlivňují následná rozhodnutí.
• Načtený kontext: Články z báze znalostí, produktová dokumentace nebo záznamy zákazníků načtené pomocí retrieval-augmented generation (RAG) podle aktuálního dotazu.
• Dlouhodobá paměť (volitelné): Trvalé skutečnosti o uživateli nebo účtu, které se přenášejí mezi relacemi (např. preferovaný jazyk, minulé problémy, úroveň předplatného).

Správa kontextu v rámci tokenového okna LLM je skutečná technická výzva. Jak se konverzace prodlužují a volá se více nástrojů, kontext může překročit kapacitu modelu. Strategie jako sumarizace, posuvná okna a selektivní vyhledávání pomáhají udržet agenta funkčního bez ztráty kritických informací.

Střední cesta: LLM chatboti a copiloti

Většina produktů prodávaných v roce 2026 jako „AI chatboti“ spadá do kategorie mezi pravidlové chatboty a plné AI agenty. Tyto systémy používají LLM k porozumění vstupu uživatele a generování odpovědí v přirozeném jazyce, ale nemají přístup k nástrojům a autonomně nevykonávají vícekroková workflow.

Typický LLM chatbot funguje takto: uživatel pošle zprávu, systém načte relevantní kontext z báze znalostí (pomocí RAG), předá zprávu a kontext do LLM a vrátí vygenerovanou odpověď. Neexistuje smyčka uvažování, výběr nástrojů ani iterativní provádění. Každá zpráva uživatele spustí jedno volání LLM.

Tato architektura je významné zlepšení oproti pravidlovým chatbotům. LLM zvládá otevřený jazyk bez potřeby předdefinované taxonomie záměrů, generuje přirozené odpovědi místo vyplňování šablon a dokáže pracovat v jakémkoli jazyce, který model podporuje. Pro čisté Q&A případy použití, kde je cílem odpovídat na otázky z báze znalostí, může LLM chatbot stačit.

Omezení se ukáže, když uživatel potřebuje, aby systém něco udělal: vyhledal objednávku, vytvořil ticket, zpracoval refundaci, zkontroloval sklad nebo koordinoval více zdrojů dat. LLM chatbot může pouze navrhnout, aby tyto akce provedl uživatel sám, nebo eskalovat na člověka. AI agent je může vykonat přímo.

V praxi není hranice mezi LLM chatbotem a AI agentem vždy ostrá. Přidání jediného nástroje (např. vyhledání objednávky) k LLM chatbotovi ho posune směrem k agentnímu konci spektra. Rozlišení je spíše o míře autonomie než o pevné hranici. Přesto na architektonickém rozdílu záleží: LLM chatbot bez smyčky uvažování zpracovává vždy jeden požadavek, zatímco agent může řetězit více pozorování a akcí k řešení složených problémů.

Porovnání vedle sebe

Dávají pravidloví chatboti ještě smysl?

Pro většinu případů použití v roce 2026 ne. AI agenti jsou dostatečně dobří, dostatečně levní a dostatečně spolehliví, takže začít nový projekt s pravidlovým chatbotem se těžko obhajuje. AI agent zvládá všechno, co chatbot (FAQ, jednoduchá vyhledání, sběr dat), a zároveň zvládá dlouhý chvost požadavků, které chatboti neumí. Nižší je i zátěž údržby: místo definování záměrů a toků pro každý nový případ použití rozšiřuješ bázi znalostí a přidáváš nástroje.

Existuje několik úzkých situací, kde může být pravidlový chatbot stále pragmatickou volbou:

Regulatorní omezení vyžadující deterministické, předem schválené odpovědi. V některých regulovaných odvětvích (zdravotnická sdělení, finanční compliance) musí být každá odpověď před nasazením zkontrolována a schválena. Chatbot se šablonovanými odpověďmi to splňuje už z návrhu. AI agenty lze omezit pomocí guardrails, ale výstup je stále generovaný, ne předem schválený slovo od slova.

Extrémní citlivost na náklady při masivním škálování. Pokud zpracováváš desítky milionů jednorázových interakcí měsíčně a případ použití je skutečně jednoduchý (např. kontrola zůstatku, potvrzení rezervace), náklady na LLM inference za interakci se nemusí vyplatit. Tato hranice se s poklesem cen modelů stále posouvá, ale na začátku roku 2026 při velmi vysokých objemech pořád existuje.

Legacy systémy bez migrační cesty. Některé organizace mají pravidlové chatboty hluboce integrované do infrastruktury a nemají rozpočet ani časový plán na jejich nahrazení. V těchto případech otázka nezní „co je lepší“, ale „co můžeme udělat právě teď“.

Mimo tyto okrajové případy je AI agent lepší výchozí volba. Otázka se posunula z „máme použít AI agenta, nebo chatbota“ na „jak nakonfigurujeme a omezíme AI agenta pro naši konkrétní doménu“.

Kde jsou AI agenti nejsilnější

AI agenti jsou jasná volba pro většinu nových projektů konverzační AI v roce 2026. Několik scénářů, kde je rozdíl mezi agenty a pravidlovými chatboty největší:

Složité požadavky podpory napříč více systémy. Výše uvedený příklad výměny objednávky je typický. Uživatel má složený problém, který vyžaduje vyhledat data, rozhodovat a provést více akcí. Chatbot by potřeboval samostatný tok pro každou možnou kombinaci problémů.

Otevřené produktové otázky. „Který plán je vhodný pro tým 15 lidí, který potřebuje integraci WhatsApp a HIPAA compliance?“ vyžaduje uvažování napříč produktovou dokumentací, cenovými pravidly a požadavky na compliance. Agent dokáže načíst relevantní dokumenty a syntetizovat odpověď. Chatbot by potřeboval nemožně rozsáhlou taxonomii záměrů, aby pokryl všechny možné produktové otázky.

Prodejní konverzace. Kvalifikace leadů, odpovídání na námitky a doporučování produktů podle popsaných potřeb potenciálního zákazníka jsou ze své podstaty neskriptované. Agent, který rozumí produktu a má přístup k CRM datům, je mnohem efektivnější než chatbot sledující větvený skript.

Vícejazyčná podpora ve velkém měřítku. LLM nativně zvládají více jazyků, takže AI agent může obsluhovat zákazníky v desítkách jazyků bez samostatných NLU modelů nebo šablon odpovědí pro každý jazyk. Pravidlový chatbot vyžaduje explicitní vícejazyčná trénovací data a šablony pro každý podporovaný jazyk. Vícejazyčná nasazení LLM přesto stále vyžadují práci: konzistenci terminologie, kalibraci tónu podle lokality, QA pro jazyky s menším množstvím zdrojů a kontrolu compliance pro regionální regulace. Jazykový model odstraňuje technickou zátěž pro každý jazyk, ale neodstraňuje potřebu lokalizačního dohledu.

Scénáře vyžadující úsudek a eskalaci. AI agent dokáže posoudit, zda má dostatečnou jistotu ve své odpovědi, detekovat frustraci zákazníka pomocí analýzy sentimentu a rozhodnout se eskalovat na člověka s úplným kontextem. Takové adaptivní chování se ve stavovém automatu kóduje obtížně.

Pozadí k tomu, jak se platformy konverzační AI vyvíjejí pro podporu těchto případů použití, najdeš v Průvodci platformou konverzační AI.

Jak AI agenti fungují v produkci

Surový LLM bez omezení by byl v zákaznicky orientovaném prostředí nepoužitelný. Produkční AI agenti jsou nakonfigurováni pomocí vrstev kontroly, které určují, co agent smí říkat, co smí dělat a kdy má přestat a předat konverzaci člověku. Tyto prvky nejsou převzaté z architektury chatbotů, jsou nativní pro fungování agentních platforem.

Guardrails a pravidla chování. Agent funguje v konfigurovatelných hranicích: povolená témata, omezení tónu a osobnosti, prahy eskalace a schválené sady nástrojů. Pokud se zákazník zeptá na téma mimo rozsah agenta, guardrails určují, zda agent odmítne, přesměruje nebo eskaluje. Provozním týmům to dává předvídatelnost, kterou potřebují, bez tvrdého kódování dialogových toků.

Ukotvení ve znalostech (RAG). Aby se snížily halucinace, odpovědi agenta jsou ukotvené v kurátorované bázi znalostí pomocí RAG (retrieval-augmented generation). Agent před vygenerováním odpovědi načte relevantní dokumenty a systém může dohledat, které zdrojové dokumenty ovlivnily každou odpověď. Více o tom, jak mitigace halucinací funguje v praxi, najdeš v článku Co jsou AI halucinace?.

Přístup k nástrojům a oprávnění k akcím. Agent může provádět akce v externích systémech (vytvářet tickety, zpracovávat refundace, aktualizovat záznamy, spouštět workflow) přes API nebo MCP servery. Ke kterým nástrojům má agent přístup, se konfiguruje pro každé nasazení. Agent podpory může mít přístup pro čtení k datům objednávek a přístup pro zápis do ticketovacího systému, ale žádný přístup k úpravám fakturace. Tato oprávnění jsou produkční obdobou principu nejmenších oprávnění.

Quickchat AI Agents je jedním příkladem platformy, která kombinuje všechny tři vrstvy: konfigurovatelné guardrails, odpovědi ukotvené pomocí RAG s dohledatelností zdrojů a používání nástrojů přes API a MCP.

Kompromisy mezi náklady a výkonem

Volba mezi chatbotem a AI agentem je zčásti architektonické rozhodnutí a zčásti ekonomické rozhodnutí.

Ekonomika chatbotů

Pravidloví chatboti mají téměř nulové mezní náklady na interakci. Náklady na infrastrukturu tvoří hostování lehké aplikace s databází záměrů a odpovědí. Pro vysoce objemové a málo složité případy použití se to nákladově těžko překonává.

Skryté náklady jsou v údržbě. Každý nový případ použití vyžaduje technický čas na definování záměrů, vytvoření toků, napsání šablon a integraci API. Jak se rozsah chatbota zvětšuje, náklady na údržbu se skládají. Organizace se stovkami záměrů často utratí za údržbu chatbota více, než by utratily za platformu AI agenta.

Ekonomika AI agentů

AI agenti mají náklady na interakci, protože každá konverzace zahrnuje LLM inference (účtované podle tokenů) plus případnou režii provádění nástrojů. Náklady na vyřešenou konverzaci se liší podle délky konverzace, počtu volání nástrojů a použitého modelu.

Náklady na konverzaci vyřešenou AI agentem se výrazně liší podle délky konverzace, volby modelu a počtu volání nástrojů, ale většina dodavatelů účtuje mezi $0.30 a $2.00 za vyřešenou konverzaci. Pro srovnání, Gartner odhaduje průměrné náklady na interakci podpory zpracovanou člověkem na $5-$15 podle kanálu a složitosti. Některé zveřejněné ceny za vyřešení na začátku roku 2026: Intercom Fin účtuje $0.99 za vyřešení, Quickchat AI účtuje $0.50 za vyřešení v plánu Enterprise a Salesforce Agentforce účtuje $2.00 za konverzaci.

Ekonomický výpočet se posouvá ve prospěch AI agentů s rostoucí složitostí konverzací. Pravidlový chatbot, který zvládne jen 40% příchozích požadavků, stále směruje zbývajících 60% na lidské agenty. AI agent s vyšší mírou vyřešení (dodavatelé uvádějí hodnoty od 60% do 90%+ podle domény a kvality báze znalostí) snižuje celkové náklady provozu podpory, i když každá jednotlivá AI interakce stojí více než interakce s chatbotem.

Podrobný rámec pro výpočet těchto kompromisů najdeš v článku Jak spočítat ROI chatbota.

Měření úspěchu jinak

Chatboti a AI agenti vyžadují odlišné analytické přístupy, protože selhávají různými způsoby.

Metriky chatbotů se zaměřují na pokrytí: kolik záměrů je rozpoznáno, jaké procento zpráv skončí ve fallbacku a jak často uživatelé dokončí definovaný tok. Primárním diagnostickým nástrojem je fallback log, který ukazuje, na co se uživatelé ptají a co chatbot neumí zpracovat.

Metriky AI agentů se zaměřují na kvalitu výsledku: zda agent problém skutečně vyřešil, zda byl zákazník spokojený, kolik to stálo a zda byla odpověď ukotvená v přesných zdrojích. Klíčové metriky zahrnují míru vyřešení AI, náklady na vyřešení, CSAT podle AI interakce a trendy sentimentu podle tématu.

Komplexního průvodce těmito metrikami, včetně nastavení dashboardů a cílových benchmarků, najdeš v článku Chatbot Analytics: průvodce KPI, dashboardy a metrikami.

Dohledatelnost je další dimenze, na které u AI agentů záleží více než u chatbotů. Protože agent odpovědi generuje, místo aby je vyhledával, potřebuješ způsob, jak ověřit, že jeho odpovědi jsou ukotvené ve tvé bázi znalostí a nejsou vymyšlené. Hledej platformy, které ukazují, které zdrojové dokumenty ovlivnily každou odpověď, aby týmy podpory mohly chování agenta průběžně auditovat a zlepšovat.

FAQ

Můžu svého stávajícího chatbota převést na AI agenta?

Ne přímo, protože architektury jsou zásadně odlišné. Mnoho aktiv, která jsi pro chatbota vytvořil (obsah báze znalostí, API integrace, databáze FAQ), ale lze přímo přenést do nastavení AI agenta. Báze znalostí se stane RAG korpusem a API integrace se stanou nástroji, které agent může volat. Zahodíš taxonomii záměrů a definice dialogových toků, které LLM nahradí uvažováním za běhu.

Jsou AI agenti dražší než chatboti?

Na interakci ano. AI agenti mají náklady na LLM inference, které pravidloví chatboti nemají. AI agenti ale typicky vyřeší mnohem vyšší procento požadavků bez zásahu člověka (80%+ oproti 40-60% u tradičních chatbotů), což snižuje celkové náklady podpory. Celkové náklady vlastnictví závisí na objemu konverzací a mixu složitosti.

Halucinují AI agenti?

Mohou. LLM může vygenerovat odpověď, která zní věrohodně, ale je fakticky nesprávná. Proto produkční AI agenti používají RAG (retrieval-augmented generation), aby odpovědi ukotvili v ověřených zdrojových materiálech, a proto jsou funkce dohledatelnosti ukazující, které dokumenty informovaly každou odpověď, kritické pro produkční nasazení.

Dokáže AI agent zvládnout úkoly, které chatbot neumí?

Ano, konkrétně úkoly, které vyžadují uvažování napříč více zdroji dat, vícekrokové provádění, zpracování nových požadavků nepokrytých předdefinovaným záměrem a přizpůsobení chování podle konverzačního kontextu. Chatbot zvládne jen úkoly, které jeho návrháři explicitně předvídali a vytvořili pro ně toky.

A co latence?

Chatboti odpovídají v milisekundách, protože provádějí vyhledání. AI agenti typicky odpovídají za 1-5 sekund podle počtu potřebných kroků uvažování a volání nástrojů. Pro většinu případů použití v zákaznické podpoře a prodeji je tato latence přijatelná. Pro real-time aplikace, kde jsou povinné odpovědi pod jednu sekundu, může být nutný chatbot nebo vrstva cachovaných odpovědí.

Je „AI agent“ jen marketingové přejmenování „chatbota“?

Ne. Rozdíl je architektonický. Chatbot sleduje předdefinovaný skript. AI agent uvažuje o úkolu za běhu a rozhoduje, co dělat. Je to podobné jako rozdíl mezi napevno zakódovaným programem if/else a systémem, který používá model strojového učení k rozhodování. Navenek mohou vypadat podobně (oba vedou textové konverzace), ale vnitřní mechanismy a schopnosti jsou odlišné.