Úvod
Vytváření efektivních AI agentů vyžaduje více než jen propojení jazykových modelů s nástroji. Skutečnou výzvou je, jak agenti uvažují o složitých problémech, zvládají velké množství informací a provádějí vícekrokové workflow efektivně. V tomto komplexním průvodci se zaměříme na pokročilé techniky implementace AI agentů, především na plánování – klíčovou schopnost, která odlišuje výkonné agenty od základních implementací. Plánování umožňuje AI agentům rozdělit složité úkoly na zvládnutelné kroky, překonat omezení kontextového okna a provádět workflow rychleji a ekonomičtěji. Ať už stavíte výzkumné agenty, automatizační systémy nebo inteligentní asistenty, pochopení implementace plánování do AI agentů výrazně zlepší jejich výkon a spolehlivost.
{{ youtubevideo videoID=“qPfpV4ZAnXA” provider=“youtube” title=“Pokročilí AI agenti Ep.1: Jak přimět AI agenta plánovat” class=“rounded-lg shadow-md” }}
Co jsou AI agenti a proč na nich záleží?
Agenti umělé inteligence představují zásadní posun v přístupu k řešení problémů pomocí jazykových modelů. Na rozdíl od tradičních aplikací, které zpracovávají vstup a generují výstup v jednom kroku, AI agenti fungují jako autonomní systémy, které vnímají prostředí, rozhodují se a vykonávají akce iterativně. AI agent typicky zahrnuje jazykový model („mozek“), sadu nástrojů nebo funkcí, které může použít, a řídicí smyčku určující, kdy který nástroj použít. Tato architektura umožňuje agentům řešit složité, vícekrokové úlohy, které by jeden LLM nedokázal zvládnout. Například agent může potřebovat vyhledat informace na webu, tyto informace zpracovat, provést výpočty a vše syntetizovat do smysluplné odpovědi. Síla agentů spočívá ve schopnosti uvažovat o potřebných krocích a provádět je v pořadí, přičemž se z výsledků jednotlivých kroků učí pro další akce.
Význam AI agentů prudce vzrostl, jak organizace objevují jejich potenciál pro automatizaci, výzkum, zákaznickou podporu a znalostní práci. Firmy stále častěji nasazují agenty pro úkoly, jako je analýza dat, generování obsahu, zákaznická podpora nebo řešení složitých problémů. Jak však agenti zvládají složitější úkoly, čelí zásadním výzvám. Jednou z nejkritičtějších je omezení jazykových modelů, zejména jejich kontextového okna – tedy maximální délky textu, který mohou najednou zpracovat. Když agenti musí pracovat s rozsáhlými dokumenty, dlouhými výsledky vyhledávání nebo složitými vícekrokovými workflow, rychle narážejí na pokles přesnosti a výkonu. Právě zde se plánování stává nezbytným.
Co je problém kontextového okna a proč je plánování důležité
Omezení kontextového okna představuje jednu z největších výzev v moderním návrhu AI agentů. I když nedávné pokroky posunuly kontextová okna až na 100 000 tokenů či více, výzkum odhalil překvapivý problém: větší kontextové okno automaticky neznamená lepší výkon. Tento jev, označovaný výzkumníky z Chroma jako “context rot” (rozklad kontextu), ukazuje, že jazykové modely mají potíže přesně vyhledávat a zpracovávat informace v obrovských kontextech. V praxi, když LLM potřebuje najít konkrétní informaci schovanou v 10 000 tokenech textu, jeho přesnost dramaticky klesá oproti situaci, kdy je stejná informace v kratším kontextu. Problém se ještě zhoršuje, pokud kontext obsahuje rušivé prvky – informace související s dotazem, ale neposkytující odpověď.
Výzkumný tým Chroma provedl rozsáhlé testy vylepšenou verzí testu „jehla v kupce sena“, který tradičně měřil, jak dobře modely najdou konkrétní informaci v rozsáhlých dokumentech. Tento test měl však nedostatek: neodrážel reálné situace, kdy dokumenty obsahují související, ale matoucí informace. Zavedením rušivých odstavců – textů diskutujících o tématu jehly, ale neodpovídajících na konkrétní otázku – výzkumníci zjistili, že přesnost modelů prudce klesá. Například Claude 4.5 si udržuje lepší přesnost než jiné modely v různých scénářích s rušivými prvky, ale i ty nejlepší modely vykazují výrazné zhoršení s rostoucí délkou kontextu. Tento výzkum zásadně změnil pohled vývojářů na konstrukci AI agentů: místo spoléhání na prohledávání obřích kontextů je třeba agentům pomoci plánovat a rozdělit problém na menší, lépe zvládnutelné části.
Jak plánování řeší problém kontextu
Plánování představuje změnu paradigmatu v architektuře AI agentů. Místo toho, aby agent reaktivně odpovídal na každý krok a prohledával obrovské kontexty, plánování nutí agenta promyslet celý problém dopředu a vytvořit strukturovaný postup. Je to obdobné, jako když lidé řeší složité úkoly: také nezačneme bezhlavě pracovat, ale nejprve pochopíme problém, rozdělíme ho na kroky a vytvoříme plán. Když AI agent vytvoří plán před zahájením práce, může se v každém kroku soustředit jen na relevantní část kontextu. To výrazně snižuje zátěž jazykového modelu a zvyšuje přesnost. Například místo toho, aby LLM prohledával 50 000 tokenů kvůli několika informacím, plánovací agent nejprve vytvoří plán: „Krok 1: Najít informace o X, Krok 2: Najít informace o Y, Krok 3: Syntetizovat obě části.“ V každém kroku tedy pracuje jen s příslušnou částí kontextu a udržuje vysokou přesnost.
Plánovací přístup rovněž umožňuje agentům efektivněji zvládat složité workflow. Pokud má agent jasný plán, dokáže identifikovat, které kroky lze provést paralelně, které na sebe navazují a jak optimalizovat celkový postup. To je zvlášť cenné tam, kde je třeba použít více nástrojů nebo provést vícero API volání. Místo sekvenčních volání a čekání na dokončení každého kroku může dobře naplánovaný agent identifikovat nezávislé úkoly a spustit je současně. Tato paralelizace může zkrátit dobu provedení 3-4x oproti tradičním reaktivním agentům, jak ukazují pokročilé architektury typu LLMCompiler. Plánování navíc zlepšuje správu chyb a zotavení – agent může v případě potíží přeplánovat pouze z daného bodu, nikoli začínat od začátku, což systém činí robustnější a efektivnější.
FlowHunt a automatizace AI agentů: zjednodušení složitých workflow
FlowHunt nabízí výkonnou platformu pro tvorbu a automatizaci workflow AI agentů bez nutnosti hlubokých technických znalostí. Uživatelé zde mohou navrhovat sofistikované architektury agentů včetně plánovacích agentů prostřednictvím intuitivního rozhraní bez kódování. Ve FlowHunt můžete definovat stav agenta, vytvořit kroky plánování, nastavit integrace nástrojů a sledovat provádění agenta – vše bez nutnosti psát složitý kód. To demokratizuje vývoj AI agentů a umožňuje týmům budovat pokročilé automatizační systémy, které by jinak vyžadovaly značné vývojářské kapacity. Přístup FlowHunt k automatizaci agentů dokonale ladí s plánovací architekturou popsanou v tomto článku: uživatelé zde mohou tvořit agenty, kteří rozdělují složité úkoly na zvládnutelné kroky, udrží přesnost napříč velkým množstvím informací a efektivně provádějí workflow.
Platforma zároveň nabízí vestavěné monitorování a analytiku výkonu agentů, takže týmy vidí, kde jejich agenti uspějí a kde je potřeba vylepšení. To je klíčové pro iteraci návrhu agentů a optimalizaci jejich chování v čase. FlowHunt se integruje s populárními poskytovateli LLM a nástrojovými ekosystémy, takže snadno připojíte agenty ke všem potřebným zdrojům. Ať už stavíte výzkumné agenty pro webové vyhledávání a syntézu informací, automatizační agenty koordinující více systémů nebo zákaznickou podporu zvládající složité dotazy, FlowHunt poskytuje potřebnou infrastrukturu pro efektivní realizaci.
LangGraph: základ pro pokročilou implementaci AI agentů
LangGraph je framework určený pro tvorbu stavových AI agentů pomocí architektury stavového automatu. V jádru LangGraph reprezentuje workflow agenta jako orientovaný graf, kde každý uzel představuje stav nebo akci a hrany představují přechody mezi stavy. Tento přístup nabízí oproti tradičnímu sekvenčnímu programování několik výhod: logika agenta je explicitní a vizualizovatelná, umožňuje složitější řízení toku včetně cyklů a podmínek a poskytuje jasnou strukturu pro správu stavu během provádění agenta. Při stavbě agenta v LangGraphu vlastně definujete stavový automat, kterým se agent řídí při řešení úkolu.
Koncept stavového automatu je základem pochopení fungování pokročilých agentů. Ve stavu agenta v LangGraphu jsou obsaženy všechny informace potřebné pro rozhodování a akce. Pro plánovacího agenta tento stav může zahrnovat původní dotaz uživatele, aktuální plán, hotové úkoly, čekající úkoly a výsledky z použitých nástrojů. Jak agent prochází workflow, v každém kroku stav aktualizuje – například po dokončení úkolu ho označí jako splněný a uloží výsledek. Když má agent rozhodnout o dalším kroku, zkoumá aktuální stav a určí vhodnou akci. Tento přístup zajišťuje, že agent má vždy po ruce potřebné informace a udrží konzistenci napříč prováděním.
Implementace plánování v LangGraph: Deep Agent State
Implementace plánování v LangGraph spočívá ve vytvoření strukturovaného stavu, který sleduje postup agenta podle plánu. “Deep Agent State” je datová struktura obsahující dvě hlavní složky: todos (úkoly k dokončení) a files (získané informace). Každý todo položka představuje konkrétní úkol, který má agent splnit, a obsahuje popis úkolu a jeho aktuální stav (čeká, probíhá, dokončeno). Tato struktura umožňuje agentovi jasně evidovat, co je třeba udělat, co právě řeší a co už splnil. Sledování stavu je zásadní, protože agentu umožňuje chápat svůj pokrok a inteligentně rozhodovat o dalším postupu.
Implementace zahrnuje také tzv. reducer pattern pro správu aktualizací stavu, zejména když se více úkolů provádí paralelně. Reducer je funkce, která přijímá aktuální stav a aktualizaci a vrací nový stav. Tento pattern je v LangGraphu klíčový, protože zajišťuje, že při paralelních aktualizacích stavu (například když dva úkoly skončí současně) se informace správně spojí a nic se neztratí. Například pokud dva úkoly skončí současně a oba chtějí změnit stav, reducer zajistí, že obě změny budou zohledněny. Tento sofistikovaný princip odlišuje produkční implementace agentů od jednoduchých prototypů. Reducer pattern umožňuje i složitější scénáře správy stavu, například agregaci výsledků z více paralelních úkolů nebo řešení konfliktů při současných aktualizacích různých částí stavu.
Workflow plánovacího agenta: od dotazu k provedení
Plánovací agent se řídí specifickým workflow, které ukazuje, jak plánování zlepšuje výkon agenta. Po zadání dotazu uživatelem agent nejprve vstupuje do fáze plánování, kde pomocí jazykového modelu vytvoří komplexní plán pro řešení dotazu. Plán rozkládá složitý úkol na menší, zvládnutelné kroky. Například pokud uživatel žádá “Dejte mi krátké shrnutí MCP (Model Context Protocol)”, agent může vytvořit plán: „Krok 1: Vyhledat informace o MCP, Krok 2: Pochopit, co je MCP a jeho klíčové vlastnosti, Krok 3: Syntetizovat informace do stručného shrnutí.“ Tyto kroky agent zapíše do seznamu todos ve stavu a označí je jako čekající.
Po vytvoření plánu vstupuje agent do fáze provádění. Čte seznam todos a postupně řeší jednotlivé úkoly. Pro první úkol (vyhledání informací) agent spustí webový vyhledávací nástroj s příslušným dotazem. Výsledky vyhledávání jsou vráceny a uloženy do stavu. Agent označí tento úkol jako splněný a přechází na další. Ve druhém kroku může agent použít jazykový model ke zpracování a pochopení výsledků vyhledávání a vyzvednutí klíčových informací o MCP. Opět výsledek uloží do stavu a označí úkol za splněný. Nakonec ve třetím kroku agent všechny shromážděné informace syntetizuje do stručného shrnutí, které přímo odpovídá na původní dotaz. Po celou dobu agent udržuje jasný přehled o tom, co již splnil, co právě dělá a co zbývá. Tato struktura zajišťuje, že agent neztratí přehled o postupu a spolehlivě zvládá složité vícekrokové úkoly.
Pokročilé architektury plánování: Za hranice základního plánování
Základní plánování znamená oproti reaktivním agentům velký posun, ale existují i pokročilé architektury, které jej posouvají ještě dál. Architektura Plan-and-Execute („naplánuj a proveď“) je základní plánovací přístup: agent vytvoří plán a poté ho krok za krokem provádí. Tato architektura má ale limity: úkoly řeší sekvenčně a každý krok vyžaduje volání LLM. Architektura ReWOO (Reasoning WithOut Observations) řeší některé z těchto omezení tím, že plánovač může používat přiřazení proměnných. V ReWOO může plánovač odkazovat na výstupy předchozích úkolů pomocí syntaxe jako “#E2” (výstup úkolu 2), takže na výsledcích předchozích úkolů mohou záviset další, aniž by bylo nutné po každém kroku konzultovat plánovače. To snižuje počet volání LLM a umožňuje efektivnější provádění úkolů.
Architektura LLMCompiler představuje špičku plánovacích agentů a přináší několik inovací, které dramaticky zvyšují výkon. Plánovač nejprve generuje orientovaný acyklický graf (DAG) úkolů místo jednoduchého seznamu. Každý úkol v DAG obsahuje nástroj, který má být použit, argumenty, které se předají, a seznam závislostí (které jiné úkoly musí být dokončeny před tímto). Dále, jednotka pro načítání úkolů přijímá streamovaný výstup plánovače a plánuje úkoly hned, jakmile jsou jejich závislosti splněny. To umožňuje masivní paralelizaci: pokud plánovač identifikuje deset nezávislých úkolů, lze je všechny spustit současně. Argumenty úkolů navíc mohou být proměnné odkazující na výstupy předchozích úkolů, což umožňuje ještě rychlejší provádění než tradiční paralelní volání nástrojů. Kombinace těchto vlastností může podle výzkumu poskytnout zrychlení až 3,6x oproti tradičním agentům. Tyto pokročilé architektury ukazují, že plánování není jedna technika, ale spektrum přístupů s různými kompromisy mezi složitostí, výkonem a náklady.
Nástroje a integrace: vybavení plánovacího agenta
Aby byl plánovací agent efektivní, potřebuje přístup k vhodným nástrojům pro získávání informací a provádění akcí. Mezi nejběžnější nástroje patří webové vyhledávání (pro zjišťování informací na internetu), databázové dotazy (přístup ke strukturovaným datům), API volání (pro komunikaci s externími službami) a volání jazykového modelu (pro zpracování a uvažování o informacích). V implementaci LangGraph jsou nástroje agentovi poskytovány přes pečlivě navržené rozhraní. Agent může nástroje spouštět generováním specifických volání funkcí a výsledky jsou agentovi vráceny ke zpracování. Klíčem k efektivní integraci nástrojů je jejich jasné definování s přesnými vstupy a výstupy a to, že agent chápe, kdy a jak každý nástroj použít.
Nad rámec základních nástrojů obsahují pokročilí plánovací agenti často i specializované nástroje pro správu vlastního stavu a postupu. Například nástroj „číst todos“ umožňuje agentovi zkontrolovat aktuální plán a zjistit, jaké úkoly zbývají. Nástroj „zapsat todos“ pak umožňuje agentovi plán aktualizovat, označit úkoly za splněné nebo přidat nové podle průběhu. Tyto meta-nástroje (nástroje pracující se stavem agenta) jsou zásadní pro schopnost agenta plán upravovat podle nových zjištění. Pokud agent během provádění zjistí, že původní plán nestačí nebo je chybný, může pomocí zápisu todos plán revidovat. Tato schopnost adaptivního plánování odlišuje produkční implementace agentů od jednoduchých prototypů. Kombinace doménově specifických nástrojů (pro vlastní práci) a meta-nástrojů (pro správu uvažování a plánování agenta) vytváří silný systém zvládající složité a nepředvídatelné situace.
Praktický příklad: implementace výzkumného agenta
Abychom ukázali, jak plánování funguje v praxi, vezměme si výzkumného agenta, který má shromáždit informace o složitém tématu. Pokud dostane dotaz „Poskytněte komplexní přehled Model Context Protocol (MCP) a jeho využití“, agent postupuje následovně. Nejprve vytvoří plán: „Krok 1: Vyhledat obecné informace o MCP, Krok 2: Vyhledat případy použití MCP a aplikace, Krok 3: Vyhledat technické detaily implementace MCP, Krok 4: Syntetizovat všechny informace do komplexního přehledu.“ Tyto čtyři úkoly agent zapíše do seznamu todos, všechny označí jako čekající. Poté přistoupí k provádění. Pro krok 1 spustí webové vyhledávání s dotazem „Co je Model Context Protocol MCP?“ a získá výsledky. Označí krok 1 za splněný a výsledek uloží. Pro krok 2 hledá „využití a případy použití MCP“, opět uloží výsledek. Pro krok 3 hledá technické detaily implementace. Nakonec v kroku 4 použije jazykový model ke zpracování a syntéze všech informací do uceleného přehledu odpovídajícího původnímu dotazu.
Během celého procesu agent udržuje jasný přehled o svém postupu. Pokud v kterémkoli bodě zjistí, že plán nestačí (například pokud výsledky vyhledávání neobsahují potřebné informace), může plán upravit a přidat další úkoly. Tato adaptivní schopnost je zásadní pro reálné situace, kde původní plán nemusí stačit. Agent může zjistit, že potřebuje další informace o konkrétních implementacích MCP, nebo že musí pochopit, jak se MCP liší od alternativních přístupů. Díky možnosti upravit plán během provádění agent zvládne takové situace elegantně a neposkytne neúplné informace. Tento příklad ukazuje sílu plánování: přináší strukturu a přehled do uvažování agenta, ale zároveň si zachovává flexibilitu pro adaptaci dle nových zjištění.
{{ cta-dark-panel
heading=“Zrychlete svůj workflow s FlowHunt”
description=“Vyzkoušejte, jak FlowHunt automatizuje AI obsah a SEO workflow – od výzkumu a generování obsahu po publikaci a analytiku – vše na jednom místě.”
ctaPrimaryText=“Objednat demo”
ctaPrimaryURL=“https://calendly.com/liveagentsession/flowhunt-chatbot-demo"
ctaSecondaryText=“Vyzkoušet FlowHunt zdarma”
ctaSecondaryURL=“https://app.flowhunt.io/sign-in"
gradientStartColor="#123456”
gradientEndColor="#654321”
gradientId=“827591b1-ce8c-4110-b064-7cb85a0b1217”
}}
Optimalizace výkonu: snižování nákladů a zrychlení provádění
Jedním z hlavních důvodů pro implementaci plánování u AI agentů je dramatické zlepšení výkonu. Tradiční agenti ve stylu ReAct vyžadují volání LLM pro každou akci, což znamená, že úkol s deseti kroky potřebuje deset volání LLM. Agenti založení na plánování obvykle potřebují jen dvě až tři volání LLM: jedno pro fázi plánování, jedno nebo více pro provedení konkrétních úkolů, které vyžadují uvažování, a případně jedno pro přeplánování, pokud původní plán nestačí. Toto snížení počtu volání LLM znamená přímou úsporu nákladů, zejména při použití drahých modelů jako GPT-4. Pro organizace, které denně spouští tisíce agentních workflow, může být rozdíl mezi ReAct a plánovacími agenty značný – úspora může dosáhnout desítek tisíc dolarů měsíčně.
Kromě úspor plánování umožňuje i výrazné zrychlení. U tradičních agentů musí každý krok skončit dříve, než začne další, což vytváří sekvenční úzké hrdlo. Plánovací agenti, zejména s DAG architekturou jako LLMCompiler, umí identifikovat nezávislé úkoly a provádět je paralelně. Pokud je potřeba hledat informace o tématu A a současně o tématu B a tyto úkoly jsou nezávislé, lze je provést zároveň. Paralelizace tak může zkrátit celkový čas provedení 3-4x oproti sekvenčnímu postupu. Pro uživatelské aplikace znamená rychlost lepší zážitek, pro dávkové zpracování větší objem práce za stejný čas. Kombinace úspory nákladů a zrychlení činí plánovací agenty atraktivními pro jakoukoli organizaci využívající AI agenty ve větším měřítku.
Zvládání složitosti: když je třeba plán upravit
Reálné scénáře málokdy kopírují dokonale připravený plán. Plánovací agenti musí zvládat situace, kdy původní plán nestačí nebo je chybný. To vyžaduje pokročilou správu chyb a schopnost přeplánování. Pokud agent narazí na nečekanou situaci – například nástroj vrátí chybu, výsledky hledání neobsahují očekávané informace nebo je úkol složitější, než se zdálo – musí se adaptovat. Nejefektivnější přístup je umožnit agentovi přeplánovat na základě nových zjištění. Pokud byl původní plán vyhledat informace a syntetizovat je, ale hledání nic nepřinese, agent to musí rozpoznat a plán upravit: zkusit jiné dotazy, najít alternativní zdroje nebo úkol rozdělit jinak.
Implementace adaptivního plánování vyžaduje pečlivou správu stavu i rozhodovací logiku. Agent musí sledovat nejen, co už vykonal, ale i co se o problému dozvěděl. Pokud hledání „MCP“ nic nenajde, měl by zkusit „Model Context Protocol“ nebo „MCP protokol“, než to vzdá. Pokud volání nástroje selže, musí agent rozhodnout, zda opakovat, zkusit jiný nástroj, nebo problém eskalovat. Tato rozhodnutí vyžadují, aby agent uvažoval o svém pokroku a přizpůsobil strategii. Právě zde vyniká plánovací agent: protože má explicitní plán, dokáže zhodnotit, zda plán funguje, a informovaně rozhodnout o úpravě. Reaktivní agent naproti tomu žádnou takovou strukturu nemá a rozhoduje se za pochodu bez znalosti celkové struktury úkolu.
Monitoring a ladění plánovacích agentů
S rostoucí sofistikovaností plánovacích agentů je stále důležitější monitoring a ladění. Na rozdíl od jednoduchých aplikací, kde je snadné sledovat průběh, plánovací agenti znamenají více rozhodovacích bodů, volání nástrojů a aktualizací stavu. Efektivní monitoring vyžaduje přehled o několika aspektech provádění agenta: vytvořený plán, splněné úkoly, výsledky jednotlivých volání nástrojů a rozhodnutí agenta v každém kroku. LangGraph nabízí vestavěnou podporu v podobě platformy LangSmith, která vizualizuje průběh agenta jako graf. Lze přesně vidět, které uzly byly vykonány, v jakém pořadí a jaký stav si agent předával. Tato vizualizace je nedocenitelná pro pochopení chování agenta a odhalování míst pro zlepšení.
Při ladění plánovacích agentů je zásadní rozumět také promptům použitým pro generování plánů. Kvalita plánu přímo ovlivňuje výkon agenta, proto je při slabém výkonu často první krokem analýza plánovacího promptu. Můžete zjistit, že prompt neposkytuje dostatek kontextu, nebo že není jasné, jaké plány se očekávají. Iterace promptu často dramaticky zlepší výsledky. Monitoring výsledků volání nástrojů zase odhalí, zda nástroje vrací očekávané výsledky, nebo je potřeba jejich konfiguraci upravit. Pokud například webový vyhledávač vrací nerelevantní výsledky, může být potřeba změnit formát dotazu nebo použít filtry. Kombinací vizualizace průběhu workflow s analýzou promptů a výsledků nástrojů lze systematicky zlepšovat výkon plánovacích agentů.
Osvědčené postupy pro tvorbu plánovacích agentů
Na základě výzkumu i praktických zkušeností lze doporučit několik osvědčených postupů pro efektivní plánovací agenty. Za prvé věnujte čas tvorbě kvalitních plánovacích promptů. Prompt by měl jasně popisovat úkol, uvádět příklady dobrých plánů a specifikovat požadovaný formát plánu. Kvalitní prompt výrazně zlepšuje plány a snižuje potřebu přeplánování. Za druhé pečlivě navrhněte strukturu stavu. Stav by měl obsahovat všechny potřebné informace pro rozhodování agenta, ale nesmí být zbytečně objemný. Dobře navržený stav umožňuje agentovi snadno sledovat pokrok a rozhodovat o dalším kroku. Za třetí poskytujte jasně definované nástroje s dobrou dokumentací. Každý nástroj musí mít jasný účel, přesně definované vstupy a výstupy a mít řešené chyby. Dobře navržené nástroje zlepšují výsledky agentů.
Za čtvrté implementujte robustní správu chyb a přeplánování. Počítejte s tím, že věci půjdou špatně – nástroje selžou, hledání vrátí nečekané výsledky, plán bude nutné revidovat. Vytvořte mechanismy pro detekci těchto situací a adaptaci agenta. Za páté monitorujte a iterujte. Využívejte monitoring k pochopení výkonu agentů, identifikujte úzká místa a selhání a postupně vylepšujte návrhy. Malá zlepšení v promtu, návrhu nástrojů nebo správě stavu mohou výrazně zvýšit výkon. Za šesté zvažte kompromis mezi složitostí plánování a rychlostí provádění. Složitější plánování (například DAG) může zlepšit výkon,