Agentek

Miért érdekel ez téged?

Az előző fejezetben az agentic RAG-nál már láttad a csírát: a rendszer nem egyszer keres, hanem iteratívan tervez, keres, értékel és újrapróbál. Az agent ennek az általánosítása — egy modell, amely nem egyetlen választ ad, hanem egy célt próbál elérni, több lépésen és eszközön keresztül.

Gondolj rá úgy, mint egy új munkatársra, akinek átadsz egy feladatot, hozzáférést adsz néhány eszközhöz, és hagyod, hogy maga találja ki a lépéseket — szemben egy workflow-val, ami egy pontos, előre megírt recept. Az agent önállósága a legnagyobb ereje és a legnagyobb kockázata is egyszerre.

2023-ban az agent szó még leginkább demót és Twitter-hype-ot jelentett: az AutoGPT-szerű rendszerek látványosan indultak, majd pár lépés után körbe-körbe jártak, és elégették a teljes API-budgetet. 2026-ra ez megváltozott. A frontier modellek annyival jobban követik az instrukciókat, hívnak toolt és tartják a tervüket, hogy az agent már nem kutatási kuriózum, hanem termelő rendszer: coding agentek pull requesteket nyitnak, support agentek zárnak jegyeket, kutatóagentek órákon át olvasnak dokumentumokat. A kérdés már nem az, hogy „működik-e egyáltalán", hanem az, hogy „mikor éri meg, és hogyan tartom kordában".

Ez a fejezet arról szól, mi is az agent pontosan, milyen ciklus hajtja, milyen bevált mintákból építkezel, és — a legfontosabb mérnöki döntés — mikor van egyáltalán szükséged rá egy egyszerű workflow helyett. Ha ezt a fejezetet megérted, onnan már a 6. Multi-agent, a 7. Tool engineering és a 9. State és memory fejezetek építkeznek.

Az agent hat összetevője részletesen

A definíció hat eleme nem véletlenszerű felsorolás — mindegyik egy külön mérnöki felület, ahol elronthatod vagy jóra hangolhatod az agentet. Érdemes egyesével végigmenni rajtuk, mert a legtöbb hibás agent azért hibás, mert egyet közülük elhanyagoltak.

• Modell A „gondolkodó" motor, amely eldönti a következő lépést. Nem mindegy, melyiket választod: egy erős reasoning modell (pl. a Claude vagy GPT csúcsváltozatai) sokkal ritkábban ragad be körkörös lépésekbe, de körönként drágább és lassabb. Gyakori minta, hogy a tervezéshez erős, az egyszerű részlépésekhez olcsóbb, gyorsabb modellt használsz — erről szól a 12. Optimalizáció.
• Instrukciók (system prompt) Az agent „munkaköri leírása": mi a célja, milyen szabályokat tart be, mikor kérdez vissza, mikor áll le. Egy jól megírt agent-prompt tipikusan explicit módon leírja a mozgásteret („ha bizonytalan vagy egy visszafordíthatatlan lépésben, kérdezz vissza"), nem csak a szerepet. Ez a context engineering egyik legfontosabb terepe.
• Toolok Azok a függvények, amelyeken keresztül az agent hatni tud a világra: keresés, adatbázis-lekérdezés, e-mail-küldés, kódfuttatás. Az agent minőségét gyakran nem a prompt, hanem a toolok neve, leírása és hibakezelése korlátozza — ezért kap külön fejezetet a 7. Tool engineering.
• Állapot (state) Az adott futás munkamemóriája: az eddigi üzenetek, tool-eredmények, részcélok. Ha az állapot rosszul van kezelve (pl. minden körben az egész history-t visszaküldöd tömörítés nélkül), a context window gyorsan megtelik és a költség négyzetesen nő. Részletesen a 9. State és memory fejezetben.
• Vezérlési ciklus Az a kód, amely körbe-körbe futtatja a „gondolkodj → cselekedj → értékelj" lépést. Ez a te kezedben van, nem a modellében — te döntöd el, hogyan hívod a modellt, hogyan futtatod a toolokat, és mikor lépsz ki. A következő szekció erről szól.
• Kilépési feltételek Az a szabályhalmaz, amely garantálja, hogy a loop biztosan véget ér: cél elérve, maximális lépésszám, token- vagy költségbudget, timeout, vagy emberi megszakítás. Ezek nélkül az agent elméletileg örökké futhat — a gyakorlatban addig, amíg a számla vagy a türelmed el nem fogy.

Alapvető agent loop

Minden agent szíve ugyanaz a ciklus: a modell megnézi, hol tart, eldönti a következő lépést, végrehajtja, értékeli az eredményt, frissíti az állapotot — és ezt ismétli, amíg el nem éri a célt vagy egy kilépési feltételt. Olyan ez, mint egy GPS: minden útkereszteződésnél újraszámolja az útvonalat az alapján, hol vagy éppen és merre van a cél.

Ezt a mintát a szakirodalom gyakran ReAct-nek (Reasoning + Acting) hívja: a modell felváltva gondolkodik („mi a helyzet, mi legyen a következő lépés") és cselekszik (toolt hív), a tool eredményét pedig visszaolvassa a következő gondolkodási körbe. A lényeg, hogy a gondolkodás és a cselekvés egymásba fűződik, nem különül el egy nagy tervezésre és egy nagy végrehajtásra.

• Állapot értelmezése Az agent minden körben megnézi, hol tart: mi a cél, mi történt eddig, milyen tool-eredmények érkeztek. Ez az állapot (state) az adott futás munkamemóriája — erről bővebben a 9. State és memory fejezet szól. A gyakorlatban ez azt jelenti, hogy összeállítasz egy kontextust (rendszer-prompt + korábbi üzenetek + eddigi tool-outputok), és ezt adod át a modellnek.
• Következő lépés kiválasztása A modell az állapot alapján eldönti, mi a legjobb következő lépés: hívjon-e toolt, kérdezzen-e vissza a felhasználótól, vagy már adja meg a végső választ. Itt nincs előre bedrótozott útvonal — ez teszi agentté az agentet. Technikailag ez gyakran egy tool-calling hívás: a modell strukturáltan visszaadja, melyik toolt hívná és milyen argumentumokkal (lásd 3. Structured output).
• Tool vagy modell meghívása A kiválasztott műveletet végrehajtja: meghív egy toolt (keresés, API, kódfuttatás) vagy egy másik modellt. A tool minősége itt dönti el a siker felét — ezért kap külön fejezetet a 7. Tool engineering. Fontos: a toolt a te kódod hívja, nem a modell; a modell csak „megrendeli" a hívást, a végrehajtás és a hibakezelés a te felelősséged.
• Eredmény értékelése Megvizsgálja a visszakapott eredményt: sikeres volt-e, releváns-e, közelebb visz-e a célhoz. Itt derül ki, kell-e korrigálni vagy másik utat választani. Egy 500-as HTTP hiba, egy üres találati lista vagy egy értelmetlen válasz mind más reakciót kíván — és a jó agent ezeket meg tudja különböztetni.
• Állapot frissítése Az új eredményt hozzáfűzi az állapothoz, hogy a következő körben már ezzel a friss információval dolgozzon. Az állapot így fokozatosan épül fel a futás során. Hosszú futásoknál itt jön be a tömörítés vagy összefoglalás: nem az egész nyers outputot tartod meg, hanem a lényegét, különben a context window megtelik.
• Folytatás vagy leállás Ellenőrzi a kilépési feltételeket: kész a feladat? elérte a maximális lépésszámot? elfogyott a token- vagy időbudget? Ha nincs kilépési ok, kezdődik minden elölről. Egy tipikus production agentnél a max lépésszám 10–30 körül van, mert efölött ritkán ér el új, hasznos eredményt — inkább körbejár.

Pszeudo-kóddal a ciklus meglepően rövid — a lényeg a while loop, a tool-hívás és a kilépési feltételek:

state = {"messages": [user_input], "steps": 0}

while state["steps"] < MAX_STEPS:          # kilépési feltétel: max lépésszám
    decision = model.decide(state)          # modell választ: tool vagy végső válasz
    if decision.type == "final_answer":
        return decision.content             # cél elérve → kilépés
    result = call_tool(decision.tool, decision.args)  # tool meghívása
    state["messages"].append(result)        # állapot frissítése
    state["steps"] += 1

return "Elértem a lépéslimitet válasz nélkül."  # biztonsági kiút

Amit ebből érdemes megjegyezned: a loop maga triviális. A nehézség nem a ciklusban van, hanem a model.decide mögötti prompt minőségében, a call_tool hibakezelésében és abban, hogy az állapot ne nőjön a végtelenségig. A framework-ök (LangGraph, OpenAI Agents SDK, CrewAI — lásd 17. Frameworkök) lényegében ezt a loopot csomagolják be, plusz állapotkezelést, tracing-et és megszakíthatóságot adnak hozzá.

Amit a naiv loop kihagy

A fenti tíz sor demónak jó, de production rendszerben legalább öt dolgot hozzá kell tenned, különben megbízhatatlan lesz. Ezek a különbség egy „hétvégi hobbi agent" és egy éles rendszer között.

• Hibakezelés és retry A tool-hívások elbuknak: időtúllépés, rate limit, hibás argumentum. A hibaüzenetet nem elnyelni kell, hanem visszaadni a modellnek, hogy javítva próbálja újra (retry with feedback, lásd lejjebb). Egy csupasz try/except: pass a leggyakoribb kezdő hiba.
• Budget és timeout A max lépésszám nem elég: kellhet token-, költség- és időkorlát is. Egy elszabaduló agent 15 perc alatt több tízezer forintnyi API-hívást tud elégetni, ha semmi nem állítja meg. Mindig legyen több, egymást kiegészítő fék.
• Megfigyelhetőség (observability) Minden lépést naplózni kell: mit gondolt a modell, melyik toolt hívta, mit kapott vissza. E nélkül a debug lehetetlen — nem látod, hol tévedt el az agent. Ez a 14. Observability fejezet egyik fő témája; a lépések sorozatát trace-nek hívjuk.
• Megszakíthatóság A felhasználónak vagy az operátornak bármikor le kell tudnia állítani a futást. Egy hosszú, órákig futó agentnél ez nem luxus, hanem alapvető biztonsági kontroll.
• Perzisztencia Ha az agent percekig vagy órákig fut, az állapotot el kell tudni menteni és folytatni egy esetleges összeomlás után. A memóriában tartott state dictionary egy szerverújraindításnál elveszik — production rendszerben az állapot adatbázisba vagy eventstore-ba kerül.

Agentic minták

Nem minden agentet nulláról találsz ki: a gyakorlatban visszatérő, bevált mintákból építkezel. Ezeket érdemes felismerni és fejből tudni, mikor melyiket vesd be — mert a legtöbb probléma egy vagy két minta kombinációjával megoldható.

Egy hasznos felosztás Anthropic „Building effective agents" gondolatmenetét követi: külön kategória a workflow-jellegű minták (prompt chaining, routing, parallelization), ahol a lépések nagyrészt előre rögzítettek, és külön a valódi agentic minták (planner–executor, evaluator–optimizer), ahol a modell futásidőben dönt. A kettő közti határ elmosódó — a lényeg, hogy tudd, melyik esetben mennyi szabadságot adsz a modellnek.

Alapvető vezérlési minták

• Prompt chaining Egy feladatot fix lépések sorozatára bontasz, ahol az egyik lépés kimenete a következő bemenete. Akkor használd, ha a feladat jól ismert részekre bontható (pl. vázlat → szövegezés → lektorálás), és minden köztes eredmény ellenőrizhető. Konkrét példa: marketing e-mail generálásánál előbb kulcsüzeneteket húzol ki, majd azokból írsz vázlatot, végül hangnemre csiszolod — három külön hívás, mindegyik egyszerűbb, mint egy „csinálj mindent" prompt.
• Routing Egy osztályozó (LLM vagy szabály) eldönti, melyik ágra, modellre vagy szakértő promptra irányítsa a kérést. Akkor jó, ha eltérő típusú bemeneteket kell különböző kezelésbe küldeni — mint egy recepció, amely a megfelelő osztályhoz irányít. Ügyfélszolgálatnál például a „számlázási kérdés", „technikai hiba" és „általános érdeklődés" külön promptra és eltérő tool-készletre megy; ráadásul az egyszerű kérdéseket olcsó modellre irányíthatod, a nehezeket drágára.
• Parallelization Egy feladatot független részekre bontasz és egyszerre futtatod (sectioning), vagy ugyanarra több választ kérsz és összesíted (voting). Akkor éri meg, ha a részek nem függenek egymástól, és a párhuzamosítás csökkenti a késleltetést vagy növeli a megbízhatóságot. Példa a votingra: egy kódrészletet háromszor ellenőriztetsz „van-e benne biztonsági rés" kérdéssel, és ha kettő igent mond, jelzed — így csökken a fals negatív. Mikor NE: ha a részfeladatok egymásra épülnek, a párhuzamosítás nem működik.

Tervezés és koordináció

• Planner–executor Egy tervező lépés előbb lebontja a feladatot részlépésekre, majd egy végrehajtó sorban elvégzi azokat. Akkor hasznos, ha a megoldáshoz előbb stratégiát kell alkotni, nem lehet azonnal nekiugrani a részleteknek. Előny: a terv láthatóvá és auditálhatóvá válik, akár emberrel is jóváhagyathatod, mielőtt bármi végrehajtódna. Hátrány: ha a világ menet közben változik, a merev terv elavulttá válhat — ezért gyakran a tervet is újratervezed pár lépésenként.
• Orchestrator–worker Egy központi orchestrator futásidőben bontja fel a feladatot, dinamikusan oszt ki részfeladatokat worker-eknek, majd összegzi az eredményt. Akkor válaszd, ha a részfeladatok száma és jellege előre nem ismert (részletesen 6. Multi-agent). Különbség a planner–executortól: itt a felbontás dinamikus, futásidőben történik, nem egy előre megírt terv szerint. Egy kutatóagent például az orchestratorral eldönti, hány alkérdésre bontja a témát, és annyi worker-t indít.
• Manager agent Egy irányító agent koordinál több specializált agentet: ő dönti el, kihez fordul és mikor. Akkor indokolt, ha elkülönített szakterületek vagy jogosultságok vannak, amelyeket egyetlen agent nem foghat át. Például egy pénzügyi asszisztensnél a „lekérdező" agentnek csak olvasási joga van, a „tranzakciós" agentnek írási — a manager dönti el, mikor melyikhez fordul, és a kritikus lépés előtt emberi jóváhagyást kér.
• Hierarchical agents Agentek több szintű fája, ahol a felsőbb szint delegál az alsóbbnak, az pedig tovább. Nagy, mélyen tagolt feladatoknál segít, de a koordinációs költség és a hibalehetőség szintenként nő. Mikor NE: ha két szint is elég lenne — minden extra szint újabb kontextusátadási pont, ahol információ veszhet el, és a hibák felfelé szaporodnak.
• Agent-as-tool Egy teljes agentet becsomagolsz úgy, mintha egyetlen tool lenne, és egy másik agent hívja meg. Akkor jó, ha egy jól körülhatárolt képességet (pl. kereső agent) újra akarsz használni anélkül, hogy a hívónak ismernie kellene a belső működését (lásd 7. Tool engineering). A hívó agent szemszögéből ez egy sima függvényhívás bemenettel és kimenettel — a belső loop, tervezés, tool-használat rejtve marad. Ez a legfontosabb absztrakció a komplexitás kordában tartásához.
• Agent handoff Egy agent átadja a vezérlést és a kontextust egy másiknak, amely jobban illik az aktuális részfeladathoz. Akkor használd, ha menet közben vált a téma vagy a szükséges szakértelem — de ügyelj rá, hogy a kontextus ne vesszen el az átadásnál. Az OpenAI Agents SDK-ban ez elsőrangú fogalom: az egyik agent explicit „handoff" tétellel adja át a beszélgetést egy másiknak, aki átveszi a teljes eddigi history-t.
• Map–reduce A feladatot sok független darabra osztod (map), mindet külön feldolgozod, majd az eredményeket egyesíted (reduce). Klasszikus eset: 200 dokumentum egyenkénti összefoglalása, majd az összefoglalók összegzése egyetlen áttekintéssé. Ez megkerüli a context window korlátot is: nem kell mind a 200 dokumentumot egyszerre a modellbe tuszkolni, ami amúgy sem férne be és romlana tőle a minőség.

Önjavítás és minőségbiztosítás

• Evaluator–optimizer Egy generáló lépés készít egy megoldást, egy értékelő lépés pontozza és visszajelzést ad, majd a generáló ez alapján javít — ciklusban, amíg elég jó nem lesz. Akkor éri meg, ha van objektív vagy legalább mérhető minőségi kritérium (lásd 11. Evals). Fordításnál például az evaluator jelezheti, hogy egy szakszó pontatlan, és a generátor javítja — több körben, mint egy szerkesztő és egy író párbeszéde.
• Reflection és critique A modell megvizsgálja a saját kimenetét, hibákat keres benne, és javított változatot ad. Olyan ez, mint egy író, aki átolvassa és szerkeszti a saját vázlatát; összetett vagy hibaérzékeny feladatnál emeli a minőséget, cserébe több tokenbe kerül. Fontos korlát: a modell nem mindig látja a saját hibáit, ezért gyakran erősebb, ha külső eval vagy tool (pl. kódfuttatás, teszt) adja a visszajelzést, nem maga a modell.
• Retry with feedback Ha egy lépés elbukik (pl. hibás JSON, sikertelen tool-hívás), a konkrét hibaüzenetet visszaadod a modellnek, hogy javítva próbálja újra. Alapvető megbízhatósági minta minden tool-használó agentnél — a puszta újrapróbálkozás önmagában ritkán segít, a hibaüzenet viszont igen. Ha egy tool „ValidationError: 'amount' must be a positive integer" hibát ad, ezt szó szerint visszaadva a modell tipikusan egy körön belül javít.
• Debate vagy ensemble Több modell vagy agent egymástól függetlenül — vagy egymással vitázva — old meg egy feladatot, majd a végeredményt szavazással vagy döntőbíróval választod ki. Nagy tétű, bizonytalan döntéseknél növeli a megbízhatóságot, de sokszoros a költsége. Mikor NE: rutinfeladatnál, ahol egyetlen jó modell is bőven elég — a debate 3-5-szörös költséget és késleltetést jelenthet minimális minőségjavulásért.

A kódban egy önjavító minta így nézhet ki — figyeld meg, hogy a hibaüzenetet visszaadjuk a modellnek, nem csak vakon újrapróbálunk:

messages = [{"role": "user", "content": task}]

for attempt in range(MAX_RETRIES):        # pl. 3 próbálkozás
    output = model.generate(messages)
    error = validate(output)              # pl. JSON-séma vagy tool-hívás ellenőrzés
    if error is None:
        return output                     # sikeres → kilépés
    # a KONKRÉT hibaüzenetet visszaadjuk, hogy a modell javítson
    messages.append({"role": "assistant", "content": output})
    messages.append({"role": "user",
                     "content": f"Hiba: {error}. Javítsd és próbáld újra."})

raise RuntimeError("Nem sikerült érvényes választ előállítani.")

Amit ebből tanulj: a különbség egy 60%-os és egy 95%-os megbízhatóságú agent között gyakran nem a modell, hanem ez a néhány sor — a hibaüzenet célzott visszacsatolása. A vak retry ezzel szemben ugyanabba a hibába fut újra.

Emberi felügyelet

Két minta arról szól, hogyan tartsd bent az embert a hurokban — ezek nem technikai, hanem felelősségi döntések.

• Human-in-the-loop A folyamat megáll és emberi jóváhagyást kér, mielőtt továbblép. Akkor kötelező, ha egy hibás lépés visszafordíthatatlan vagy nagy kárt okozhat (pénzügyi, destruktív művelet).
• Human-on-the-loop Az agent önállóan fut, de az ember valós időben figyeli és bármikor beavatkozhat vagy leállíthatja. Akkor jó, ha a teljes megállás túl lassú lenne, de a felügyeletet fenn kell tartani.

A gyakorlati megvalósítás gyakran egy „kockázati kapu": az agent szabadon dolgozik az olvasási és előkészítő lépéseken, de amikor egy visszafordíthatatlan művelethez ér (utalás indítása, éles adat törlése, ügyfélnek küldött e-mail), megáll és jóváhagyást kér. Így az ember figyelmét oda irányítod, ahol tényleg számít, nem minden apró lépésnél állsz meg.

Gyakori hibák az agentic minták használatában

A minták önmagukban nem garantálják a sikert — a leggyakoribb kudarcok nem a mintaválasztásból, hanem a naiv alkalmazásukból erednek.

• Túl sok tool egyszerre Ha 40 toolt adsz az agentnek, a modell összezavarodik, rosszat választ vagy egyáltalán nem választ. Tapasztalati ökölszabály: 5-15 jól elnevezett, egyértelmű tool jobb, mint 40 átfedő. Ha sok toolod van, csoportosítsd őket agent-as-tool mintával.
• Nincs progressz-detektálás Az agent ugyanazt a toolt hívja ötször egymás után ugyanazokkal az argumentumokkal, és nem veszi észre, hogy nem halad. Érdemes figyelni az ismétlődő lépéseket, és ilyenkor megszakítani vagy stratégiát váltani.
• A reflection öncsalássá válik A modell „átnézi" a saját munkáját, rábólint, hogy jó, pedig hibás. Az önértékelés gyenge jel — ahol lehet, objektív visszajelzést használj (teszt lefut-e, séma valid-e, API 200-at ad-e), ne a modell véleményét saját magáról.
• Elveszett kontextus handoffnál Agent-átadásnál a fogadó agent nem kapja meg a lényeges előzményt, és nulláról kezdi, vagy rossz feltételezésekből indul. Az átadott kontextust explicit módon, tömören össze kell foglalni, nem csak „dobd át a labdát".

Workflow vagy agent?

Ez a fejezet legfontosabb döntése. A workflow egy előre meghatározott útvonal: te írod meg a lépések sorrendjét, a modell csak a részfeladatokat oldja meg. Az agent ezzel szemben futásidőben, dinamikusan választja meg az útvonalat és a toolokat. A workflow olyan, mint egy vasúti menetrend; az agent, mint egy taxis, aki a forgalom alapján dönti el az útvonalat.

A legtöbb valós rendszer nem tisztán az egyik vagy a másik: workflow-vázba ágyazott, szűk mozgásterű agent-lépésekből áll. A mérnöki döntés nem az, hogy „agent vagy sem", hanem hogy mekkora mozgásteret adsz a modellnek az adott ponton.

A kettő összehasonlítása egy táblázatban

Ha egyben akarod látni a különbségeket, ez a táblázat segít a döntésben. Vedd észre: az agent szinte minden dimenzióban „drágábban" jön ki — csak a rugalmasságban nyer, és pontosan ott, ahol a feladat ezt megköveteli.

Konkrét példa: számla feldolgozása

Tegyük fel, beérkező számlákat kell feldolgoznod: kiolvasni az adatokat, ellenőrizni a szállítót, könyvelni. Ez tipikus workflow: a lépések fixek (OCR → mezőkinyerés → validáció → könyvelés), auditálhatónak kell lennie, és pénzügyi művelet a vége. Itt az agent szabadsága csak kockázat — mit „döntene el" dinamikusan? Semmi olyat, amit ne tudnál előre megírni.

Most cseréld le a feladatot: „derítsd ki, miért ugrott meg 30%-kal ennek a szállítónak a számlázása az elmúlt negyedévben". Itt nem tudod előre a lépéseket — lehet, hogy meg kell nézni a szerződést, a rendeléseket, összevetni a piaci árakkal, e-mailt keresni. Ez agent feladat: feltáró, heterogén forrásokkal, előre nem ismert útvonallal. A tanulság: ugyanaz a domain, de a feladat jellege dönti el, nem a témakör.

Összefoglalás

Az agent egy modell, amely célt, eszközöket, állapotot és mozgásteret kap, majd egy vezérlési ciklusban lépésről lépésre halad a megoldás felé — mindaddig, amíg egy kilépési feltétel meg nem állítja. A ciklus egyszerű (while loop + tool-hívás + kilépési feltétel), a nehézség a részletekben és a megbízhatóságban van: hibakezelés, budget, observability, megszakíthatóság és perzisztencia teszik éles rendszerré a demót.

Az agentic minták — routingtól a reflectionön át a human-in-the-loopig — kész építőkockák: ismerd fel, mikor melyiket vesd be, és kombináld őket bátran. Ismerd a tipikus hibákat is: túl sok tool, önáltató reflection, elveszett kontextus, körkörös lépések. A legfontosabb döntés viszont mindig ugyanaz marad: kell-e egyáltalán agent, vagy egy kiszámítható workflow jobb, olcsóbb és biztonságosabb. Kezdj mindig a legegyszerűbbel, mérj, és csak valódi indokkal adj több szabadságot a modellnek.

Ha erre magabiztosan tudsz válaszolni, készen állsz arra, hogy egy agentből többet építs — és megértsd, mikor éri meg. Innen a 6. Multi-agent fejezet viszi tovább a fonalat, a 7. Tool engineering pedig azt mutatja meg, hogyan tedd valóban megbízhatóvá az agent kezét és lábát: a toolokat.