Agent, chatbot vagy workflow? Hol térül meg az AI ügynök egy KKV-nál, hol bukik el, milyen guardrail kell, és hogyan néz ki egy 6 hetes pilot költségbecsléssel.
6 hetes agent pilot
Egy zárt végű, API-val elérhető folyamat. 30-50 valós példa eval-szet, siker-kritérium számmal.
Ugyanaz a feladat determinisztikus workflow-val (n8n). Ez a viszonyítási alap, nem a manuális munka.
Tool use, lépés- és költséglimit, human-approval a visszafordíthatatlan műveletekre.
Task success rate, költség/feladat, beavatkozás-arány. Go: ≥85% success és a workflow-nál olcsóbb.
2026-ban az „AI ügynök" a leggyakrabban félreértett kifejezés a KKV-s ajánlatkérésekben. Három különböző dolgot hívnak így: a chatbotot, ami válaszol; a workflow-t, amelyben egy LLM-lépés is van; és a tényleges ügynököt, amely maga dönti el, milyen eszközt hív meg és mikor áll le. A három között nagyságrendi különbség van költségben, kockázatban és abban, hogy mit lehet vele elérni.
Ez a cikk a harmadik kategóriáról szól, de úgy, hogy közben pontosan kijelöli a határt a másik kettőhöz képest. A kérdés nem az, hogy „kell-e agent", hanem hogy melyik folyamatnál éri meg a nyílt végű döntéshozatal többletköltségét és kockázatát, és melyiknél jobb egy determinisztikus workflow egyetlen LLM-hívással.
Amit itt leírunk, az a saját projektjeinkből és a partnerhálózatunk tapasztalataiból jön: ügyfélszolgálati, back-office és adatgyűjtési agentek, amelyek élesben futnak, és olyanok is, amelyeket a pilot után leállítottunk, mert a workflow olcsóbb és megbízhatóbb volt. A számok nagyságrendek, nem benchmark-eredmények; a saját eval-szeteden mért érték az egyetlen, ami számít.
A cikk végén egy 6 hetes pilot-terv és egy költségbecslés áll, amivel a saját folyamatodra tudod lefuttatni a go/no-go döntést. Ha az AI-implementáció általános kérdései érdekelnek (érettség, use case-ek, ROI), azt az AI implementáció magyar KKV-knál 2026-ban cikkben írtuk le; ez a cikk ott folytatja, ahol az abbahagyta.
A három fogalom nem szintje egymásnak, hanem más-más architektúra. A választás nem „mennyire modern", hanem „mennyi döntést bízunk a modellre".
| Szempont | Chatbot | Workflow + LLM-lépés | Agent |
|---|---|---|---|
| Ki dönti el a következő lépést? | Nincs következő lépés | A fejlesztő, előre | A modell, futás közben |
| Eszközhívás (tool use) | Nincs vagy 1 fix | Fix sorrendben | Modell választja, ismételten |
| Lépésszám | 1 | Fix (pl. 4) | Változó (2-30) |
| Determinisztikus? | Részben | Igen, a struktúra | Nem |
| Tipikus költség / feladat | 1-5 Ft | 5-30 Ft | 30-500 Ft |
| Hibakezelés | Újrakérdez | Retry / fallback ág | Önkorrekció, de kumulálódó hiba |
Egy bemenet, egy kimenet. A RAG chatbot is ide tartozik: keres, majd válaszol, de nem indít el semmit a világban. Kockázata alacsony, mert nem cselekszik.
A folyamat gráfját a fejlesztő rajzolja meg: űrlap érkezik → LLM kategorizál → CRM-be írás → e-mail-vázlat. Az LLM egy vagy két csomópont a gráfban, a többi determinisztikus. Az n8n, Zapier és Make mind ezt a modellt támogatja, és 2026-ban a KKV-s AI-projektek 70-80%-a ilyen. A lead-asszisztens esettanulmány is workflow, nem agent.
A modell kap egy célt és egy eszközkészletet, majd egy ciklusban dönt: melyik eszközt hívja, mit kezd az eredménnyel, befejezte-e a feladatot. A ciklus addig fut, amíg a modell „kész"-t nem jelent, vagy amíg el nem éri a lépéslimitet. Az érték abban van, hogy nem kell előre felrajzolni minden ágat; a kockázat abban, hogy a modell rossz ágat is választhat.
Megjegyzés: Ha a folyamat lépései előre felsorolhatók, workflow-t építs. Az agent akkor indokolt, ha a lépések sorrendje vagy száma a bemenettől függ, és ezt nem éri meg előre lekódolni.
Az agent technikai magja a tool use (function calling): a modell nem szöveget ír, hanem egy strukturált hívást ad vissza, amit a te kódod hajt végre, majd az eredményt visszaadja a modellnek. Ez a ciklus.
# Egyszerűsített agent-loop (Anthropic Messages API, Python)
tools = [
{
"name": "get_order",
"description": "Rendelés lekérése rendelésszám alapján az ERP-ből.",
"input_schema": {
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"],
},
},
{
"name": "create_credit_note",
"description": "Jóváírás létrehozása. VISSZAFORDÍTHATATLAN — csak jóváhagyás után.",
"input_schema": {
"type": "object",
"properties": {
"order_id": {"type": "string"},
"amount_huf": {"type": "integer"},
"reason": {"type": "string"},
},
"required": ["order_id", "amount_huf", "reason"],
},
},
]
messages = [{"role": "user", "content": ticket_text}]
for step in range(MAX_STEPS): # lépéslimit: guardrail #1
response = client.messages.create(
model=MODEL, max_tokens=1024, system=SYSTEM_PROMPT,
tools=tools, messages=messages,
)
if response.stop_reason != "tool_use":
break # a modell kész
for block in response.content:
if block.type == "tool_use":
result = dispatch(block.name, block.input) # a te kódod, saját validációval
messages.append({"role": "assistant", "content": response.content})
messages.append({"role": "user", "content": [
{"type": "tool_result", "tool_use_id": block.id, "content": result}
]})
A dispatch függvény a tiéd. Itt dől el minden: itt validálsz, itt kérsz emberi jóváhagyást, itt logolsz. A modell csak javasol egy hívást; hogy végrehajtod-e, az a te döntésed.
A Model Context Protocol (MCP) azt oldja meg, hogy ne minden agenthez kelljen külön megírni a CRM-, ERP- vagy fájlrendszer-kapcsolatot. Egy MCP-szerver egyszer leírja az eszközöket (név, leírás, séma), és bármelyik MCP-képes kliens használni tudja. 2026-ban a nagy modellszolgáltatók kliensei és az elterjedt agent-keretrendszerek is támogatják.
KKV-nál az MCP gyakorlati haszna: ha már van egy belső MCP-szerver a rendelésekhez, akkor a következő agent (vagy egy fejlesztő saját asszisztense) ugyanazt használja, nem kell újra integrálni. A hátránya: egy MCP-szerver ugyanúgy támadási felület, mint egy REST API, és a jogosultságkezelést neked kell megoldanod.
Három terület, ahol 2026-ban élesben futó agentek mérhető megtakarítást hoznak. Mindháromban közös: az eszközök API-n elérhetők, a feladat vége egyértelműen felismerhető, és a hibás lépés visszafordítható vagy jóváhagyáshoz kötött.
A klasszikus chatbot válaszol; az agent megoldja a ticketet. „Hol a rendelésem?" → lekéri a rendelést, a fuvarozó API-jából a státuszt, megírja a választ, és ha a csomag 3 napja áll, jóváhagyásra felteszi a kompenzációs javaslatot.
Tipikus eredmény: a ticketek 35-50%-a emberi érintés nélkül zárul, a többinél az ügyintéző kész összefoglalót és javasolt választ kap. Az e-commerce AI chatbot esettanulmányunk az első fázisa ennek; az agent-réteg a második.
Feltétel: a rendelés-, szállítás- és számlázási adat API-n elérhető. Ha ezek Excelben vannak, előbb az integráció, utána az agent.
Példa: szállítói számla érkezik, az agent megkeresi a hozzá tartozó megrendelést, összeveti a tételeket, eltérés esetén e-mailt fogalmaz a szállítónak, egyezés esetén könyvelésre továbbítja. A lépések száma a számla bonyolultságától függ, ezért itt az agent-modell jobb, mint a fix workflow.
Tipikus eredmény: napi 1-3 óra megtakarítás back-office munkatársanként, a téves párosítások 60-80%-os csökkenése. A dokumentumfeldolgozó rétegről külön cikk készül; az alapokat az AI automatizáció szolgáltatásunknál írtuk le.
Versenytárs-árak, pályázati kiírások, beszállítói adatlapok összegyűjtése strukturált formába. Az agent böngész, kinyer, ellenőriz, táblázatba ír. Az érték nem az egyes lekérdezés, hanem az, hogy a heti 4-6 órás manuális gyűjtés 20 percnyi ellenőrzéssé válik.
Feltétel: az eredményt ember ellenőrzi felhasználás előtt. Az adatgyűjtő agent hibázhat, de a hiba olcsó, ha nem kerül közvetlenül döntésbe.
A pilotjaink kudarcai négy okra vezethetők vissza. Ezek nem a modell hibái, hanem a feladat és az agent-modell rossz párosítása.
„Döntsd el, adjunk-e kedvezményt ennek az ügyfélnek." Erre nincs eval-szet, nincs egyértelmű helyes válasz, és a modell magabiztosan fog rosszul dönteni. Az agent a végrehajtásban jó, nem az üzleti mérlegelésben. A döntést az ember hozza, az agent a döntés utáni 8 lépést csinálja.
Ha az eszköz egy weboldal, amit „kattintani kell", vagy egy Excel, amit e-mailben küldenek, az agent lassú, drága és törékeny lesz. Egy 2026-os browser-agent 20-40 lépésből old meg egy űrlapkitöltést, amit egy API-hívás egy lépésben. Az integráció előbb, az agent utána.
Ha egy lépés 95%-ban helyes, egy 10 lépéses agent-futás 60%-ban lesz teljesen helyes (0,95¹⁰ ≈ 0,60). Ezért fontos, hogy minden lépés ellenőrizhető legyen, és a hibás lépés ne rontsa el a következőt. A hallucinációk elleni védekezés cikkben leírt eval-módszerek itt lépésenként alkalmazandók.
Egy agent, amely nem talál választ, hajlamos újra és újra próbálkozni. Lépéslimit nélkül egy ticket 200-400 Ft helyett 5 000 Ft-ba kerülhet, és ha ez napi 300 ticketnél fordul elő, a havi számla egy nagyságrenddel nő. A limit nem opció, hanem alapkövetelmény.
Figyelem: Ha egy szállító „autonóm agentet" ajánl visszafordíthatatlan műveletekre (kifizetés, törlés, szerződéskötés) emberi jóváhagyás nélkül, kérd el az eval-szetet és a beavatkozás-arányt. Ha nincs, a rendszer nem éles használatra kész.
A guardrail nem egy prompt-sor („légy óvatos"), hanem a dispatch réteg körüli kód és folyamat. Öt réteg, amit minden éles agentünkben megvalósítunk:
| Réteg | Mit véd | Hogyan |
|---|---|---|
| Lépés- és tokenlimit | Költség, végtelen ciklus | MAX_STEPS 10-25, feladat-szintű tokenkeret |
| Eszköz-jogosultság | Jogosulatlan művelet | Az agent csak a feladathoz szükséges tool-okat kapja; olvasás és írás külön |
| Human-in-the-loop | Visszafordíthatatlan műveletek | Jóváhagyási sor: kifizetés, törlés, külső kommunikáció |
| Bemenet-szűrés | Prompt injection a ticketből, e-mailből | A tool-eredményt adatként, nem utasításként kezeljük; injektált utasítás-minták szűrése |
| Napló és visszajátszás | Audit, hibakeresés | Minden lépés (prompt, tool-hívás, eredmény, költség) trace-ben; bármely futás visszajátszható |
// Human-in-the-loop guardrail a dispatch rétegben (TypeScript)
const IRREVERSIBLE = new Set(['create_credit_note', 'send_email', 'delete_record']);
async function dispatch(name: string, input: unknown, ctx: RunContext) {
ctx.steps += 1;
if (ctx.steps > ctx.maxSteps) throw new AgentHalt('step-limit');
if (ctx.costHuf > ctx.budgetHuf) throw new AgentHalt('budget');
const tool = registry.get(name);
const args = tool.schema.parse(input); // séma-validáció, nem bízunk a modellben
if (IRREVERSIBLE.has(name)) {
const approval = await approvals.request({ runId: ctx.runId, tool: name, args });
if (approval.status !== 'approved') return { status: 'pending-approval' };
}
const result = await tool.execute(args, ctx);
await trace.record({ runId: ctx.runId, step: ctx.steps, name, args, result });
return result;
}
A jóváhagyási sor a gyakorlatban egy Slack-üzenet vagy egy belső admin-felület egy „Jóváhagy / Elutasít" gombbal. A cél nem az, hogy minden lépést ember nézzen, hanem hogy a 3-5%-nyi visszafordíthatatlan lépés ne fusson át ellenőrzés nélkül.
A pilot célja nem a „működik-e", hanem a „megéri-e a workflow-hoz képest". Ezért a viszonyítási alap nem a manuális munka, hanem egy determinisztikus workflow ugyanarra a feladatra.
| Hét | Feladat | Kimenet |
|---|---|---|
| 1 | Feladat-kiválasztás, eval-szet | 30-50 valós eset, elvárt kimenettel; siker-kritérium számmal |
| 2 | Workflow baseline | n8n vagy kód alapú workflow, lefuttatva az eval-szeten; success rate + költség/feladat |
| 3 | Agent v1 | Tool-ok, system prompt, lépéslimit; első futás az eval-szeten |
| 4 | Guardrail + HITL | Jóváhagyási sor, jogosultságok, trace; hibaelemzés lépésenként |
| 5 | Shadow mode | Éles bemeneten fut, de nem cselekszik; ember hasonlítja össze a javaslatot a valósággal |
| 6 | Döntés | Success rate, költség/feladat, beavatkozás-arány; go / no-go / vissza a workflow-hoz |
Ha a workflow 90%-ot hoz és az agent 88%-ot háromszoros áron, a válasz a workflow. Ez nem kudarc, hanem a pilot legértékesebb eredménye: 6 hét alatt derült ki, nem 6 hónap alatt.
Két költség van: az építés és az üzemeltetés. Mindkettőnél a nagyságrend számít, nem a pontos szám; a saját folyamatod adatai felülírják ezeket.
| Tétel | Nagyságrend (nettó Ft) | Megjegyzés |
|---|---|---|
| 6 hetes pilot (fenti terv) | 1,2-2,5 M | Tartalmazza a workflow-baseline-t is |
| Éles bevezetés pilot után | 1,5-4 M | Integrációk száma dönt |
| Integráció hiányzó API-hoz | 0,3-1 M / rendszer | Ha az ERP/CRM nem ad API-t |
| Jóváhagyási felület | 0,3-0,8 M | Slack-alapú olcsóbb, admin-UI drágább |
Példa: ügyfélszolgálati agent, napi 200 ticket
LLM-költség / ticket (2026 Q3 nagyságrend, közepes modell):
átlag 6 lépés × ~4 000 token = ~24 000 token → 40-120 Ft / ticket
200 ticket × 22 nap × 80 Ft = ~350 000 Ft / hó
Infra (trace, sor, hosting): 30-60 000 Ft / hó
Felügyelet, prompt- és eval-karbantartás: 100-200 000 Ft / hó
Összesen: ~500-600 000 Ft / hó
Megtakarítás:
200 ticket × 40% auto-zárás × 6 perc = 480 perc = 8 óra / nap
8 óra × 22 nap × 6 000 Ft (terhelt óradíj) = ~1 050 000 Ft / hó
Nettó: ~450-550 000 Ft / hó; a 3 M Ft-os bevezetés 6-7 hónap alatt térül.
A számítás érzékeny két tényezőre: az auto-zárási arányra és a lépésszámra. Ha az auto-zárás 25%, a megtérülés egy évre nyúlik; ha a lépésszám limit nélkül 15-re nő, az LLM-költség megduplázódik. Ezért a pilot méri mindkettőt, mielőtt bárki bevezetésről dönt.
Tipp: Az agent költségét mindig feladat-szinten mérd (Ft / lezárt ticket), ne token-szinten. A tokenár évente csökken, a lépésszám viszont a te promptodtól és guardrail-jeidtől függ; az utóbbit tudod befolyásolni.
Akkor, ha a folyamat lépéseinek száma vagy sorrendje a bemenettől függ, az eszközök API-n elérhetők, és a hibás lépés visszafordítható vagy jóváhagyáshoz köthető. Ha a lépések előre felsorolhatók, a determinisztikus workflow olcsóbb és megbízhatóbb.
Egy jól felépített pilot 6 hét alatt ad számszerű választ: success rate az eval-szeten, költség egy feladatra és beavatkozás-arány a shadow-héten. A döntéshez ez a három szám kell, nem a demó.
Igen, ha az agent csak a feladathoz szükséges eszközöket kapja, az olvasás és az írás külön jogosultság, a visszafordíthatatlan műveletek emberi jóváhagyáshoz kötöttek, és minden lépés naplózva van. Jogosultság-szűkítés és jóváhagyási sor nélkül nem javasoljuk.
Egy napi 200 ticketet kezelő ügyfélszolgálati agent 2026-os nagyságrendben 500-600 ezer Ft havonta (LLM-költség, infra, felügyelet együtt), és 6-7 hónap alatt térül meg, ha a ticketek 40%-a emberi érintés nélkül zárul. A saját számod a pilotban mért auto-zárási aránytól és lépésszámtól függ.
Az AI ügynök 2026-ban nem hype és nem csodaszer: egy architektúra, amely bizonyos folyamatoknál olcsóbb és rugalmasabb, mint a fix workflow, másoknál drágább és törékenyebb. A különbséget nem a technológia dönti el, hanem a feladat természete: API-n elérhető eszközök, zárt végű cél, visszafordítható vagy jóváhagyható lépések.
A kudarcok szinte mindig ugyanabból jönnek: nyílt végű üzleti döntést bíznak a modellre, hiányzó API-t akarnak agenttel áthidalni, vagy nincs lépés- és költséglimit. Ezek mind a pilot első két hetében kiderülnek, ha az eval-szet és a workflow-baseline megvan.
A gyakorlati sorrend: válassz egy folyamatot, építsd meg workflow-ként, mérd meg, aztán próbáld agentként ugyanazon az eval-szeten. Ha az agent jobb vagy olcsóbb, van mit bevezetni. Ha nem, 6 hét alatt megspóroltál egy féléves projektet.
Kapcsolódó cikkeink: AI implementáció magyar KKV-knál 2026-ban, LLM hallucinációk elleni védekezés, n8n vs Zapier vs Make.
Ha van egy folyamat, amelyről el szeretnéd dönteni, hogy workflow vagy agent, foglalj egy 30 perces hívást: végignézzük az eszközöket, az adatokat és a kockázatokat, és megmondjuk, melyik irányba érdemes elindulni. Ha agent, akkor a fenti 6 hetes pilot a kiindulópont.
A szerzőről
Corevanix Kft.
Tech partner
Budapesti technológiai partner — SAP/ERP integráció, webfejlesztés, AI automatizáció és mobil app fejlesztés. A megrendelő saját környezetében dolgozunk, a leszállított kód teljes egészében a megrendelőé.
Jogalap, adatfeldolgozói szerződés az AI-szolgáltatóval, EU adatrezidencia, pszeudonimizálás, megőrzés és training opt-out, érdekmérlegelés, AI Act, checklist.
A prompt kód: repo, verziózás, review, sablon-struktúra, few-shot, eval-készlet, regressziós teszt, injection-védelem, költség és observability egy helyen.
OCR + LLM pipeline, JSON-sémás kinyerés, validáció és human-in-the-loop, SAP/ERP integráció, hibaarány-mérés és ROI: így automatizálj számlát és szerződést.