„A munkát kiadom, a döntést soha” – Interjú az Agentic AI gyakorlati alkalmazásáról
Gyakran hallani, hogy az Agentic AI alapjaiban forgatja fel a vállalati működést, de kevesen látják, hogyan működik ez a mindennapokban. Miben változtatta meg ez a technológia a gondolkodásmódodat a munkafolyamatok tervezésével kapcsolatban?
Korábban egy munkafolyamat tervezésekor azt kérdeztem: melyik lépést tudom egy képlettel vagy szkripttel automatizálni? Ma azt kérdezem: melyik lépéshez kell emberi ítélőképesség, és melyiket tudom olyan egyértelműen leírni, hogy egy ügynök önállóan végrehajtsa.
A havi és félévi zárás ismétlődő lépései – mint a várható hitelezési veszteség, a halasztott adó, a portfólió-átértékelés vagy az értékesítési jutalék – ma leírt, ellenőrizhető eljárások, úgynevezett skillek. Ezeket egy ügynök futtatja, én pedig a végeredményt hagyom jóvá.
A dokumentáció szerepe is megfordult: nem utólagos kötelesség, hanem maga az infrastruktúra, mert az ügynök abból tudja, hogyan dolgozunk. Öt hónap alatt 43 rövid döntési feljegyzés készült, és ezek az embereket és az ügynököket egyformán irányítják. Megtanultam, hogy nem a számítás a szűk erőforrás, hanem a figyelem és a kontextus. Ezért a fő munkamenet csak dönt, a jól körülhatárolt munkát pedig specializált alügynököknek adja ki. Egy feladatot akkor tartok kiadhatónak, ha egy mondatban meg tudom fogalmazni: ez az eredmény, ezekben a fájlokban, így ellenőrizzük. Ez egy emberi csapatban is működik, csak ott ritkán kényszerít rá bármi.
Hol van szerinted a határ az AI teljes önállósága és az emberi felügyelet között? Hogyan kezelhetők a gyakorlatban az ebből adódó biztonsági vagy etikai kockázatok?
Nálam a határt nem a feladat nehézsége jelöli ki, hanem az, hogy visszafordítható-e. Ahol a hiba könnyen visszacsinálható – például külön ágon kódot ír, lekérdez, dokumentációt frissít –, ott az ügynök nagy önállóságot kap. Ami viszont kifelé megy vagy nehezen fordítható vissza (éles adatba írás, e-mail küldése, bejegyzés a projektkezelőbe), ahhoz mindig kifejezett jóváhagyás kell. A titkári ügynököm például alapból csak piszkozatot ír. A elv egyszerű: a munkát kiadom, a döntést soha.
A második pillér az ellenőrzés: egy ügynök jelentése bizonyíték, nem bizonyítás. Ha azt írja, hogy a teszt zöld, újrafuttatom. A kódot egy másik gyártó modellje nézi át külön folyamatban, hogy ne örökölje a szerző feltevéseit. Ez a gyakorlatban is kellett: egyszer az átnéző egy nem létező hiányt jelentett blokkolónak, amit egy keresés másodpercek alatt megcáfolt. Volt fordított eset coversely is, amikor a mi „ellenőrzésünk” volt a hibás, ezért ma már az ellenőrzést is ellenőrizzük.
Adatvédelmi szabály, hogy éles pénzügyi adatot tartalmazó kódot nem küldünk külső átnézőnek, a hozzáférést pedig szolgáltatásfiókok és rétegenkénti jogosultságok szabályozzák. Etikai alapelvünk, hogy a forrásadat hibáját jelentjük a felelősének, és nem „szabályozzuk körül” csendben. Egy ügynök könnyen eltüntetne egy hibát, de az nem az ő döntése.
Milyen konkrét üzleti vagy technológiai problémával küzdöttél, amit egy egyedi Agentic AI architektúrával nagyságrendekkel hatékonyabban meg tudsz már oldani?
A STRT-nál – amelynek a KÜRT Akadémia is része – senior controllerként dolgozom. A cégcsoport több jogi személyből áll, így a konszolidált IFRS-beszámoló, a cash flow, a szegmensinformáció és a vezetői riportok korábban kézzel vezetett Excel-munkafüzetekben készültek, zárásonként heteknyi munkával.
Egyedül, Claude Code-dal és ügynökökkel öt hónap alatt építettem fel egy Google Cloud-alapú adattárházat. A könyvelési rendszer főkönyve automatikusan érkezik, és öt rétegen keresztül jut el a kész kimutatásokig. Ma 145 SQL-modell és 200-nál több automatikus ellenőrzés fut minden éjjel. Egy saját monitorozó szolgáltatás jelez, ha egy már lezárt időszak száma elmozdul. A félévi kimutatások reprodukálható lekérdezésből jönnek, a könyvvizsgálói munkafüzet pedig szkriptből generálódik.
Mindez tizedannyi idő alatt készült el, mint amennyit egy hagyományos fejlesztés igényelt volna. A nagyságrendi különbség nem abból jön, hogy az AI gyorsabban ír SQL-t, hanem abból, hogy a számviteli szaktudásom veszteség nélkül fordítható le működő rendszerre – fejlesztőcsapat közbeiktatása nélkül.
Technikai szemmel nézve: milyen architekturális vagy prompt-tervezési megközelítéseket használsz?
Nem promptokra tervezek, hanem kontextusra. A projekt gyökerében egy szabályfájl rögzíti a rétegeket, az elnevezéseket és a dokumentációs fegyelmet, amit minden munkamenet betölt. Mellette egy LLM-re optimalizált wiki áll: sok kis oldal és egy index, amely megmondja, melyik feladathoz melyik oldal kell. Az ügynök így csak azt olvassa be, amire éppen szüksége van.
Nyolc specializált alügynök dolgozik (architekt, SQL-elemző, fejlesztő, DevOps, projektmenedzser, titkár, kutató, átnéző), mindegyik saját eszközkészlettel. Ez egy supervisor/planner–worker minta, a kurzus szóhasználatával „worker ignorance”-szel: a munkás csak a feladatleírást kapja meg, nem az egész beszélgetési előzményt.
-
Skillek: Az ismétlődő eljárások 16 skillként élnek – ezek lépésről lépésre leírt folyamatok, gyakorlatilag API-szerződések az ügynök felé.
-
Párhuzamosítás: Minden író ügynök saját git worktree-t és ágat kap.
-
Tervezés: Egy interjúval indul, amelyben az ügynök addig kérdez, amíg közös nem lesz a megértés. A letisztult fogalmak szótárba, a döntések döntési feljegyzésbe kerülnek.
-
Memória: A tartós memória fájlalapú. A korábbi hibák tanulságai (eddig kb. 90 hibaelemzés) visszakerülnek a kontextusba, így ugyanazt a hibát ritkán követi el kétszer.
Számos keretrendszer és eszköz érhető el a piacon. Miben hiszel, és milyen stacket használsz a gyakorlatban?
A legkevesebb absztrakcióban hiszek, ami még működik. A mindennapi munkám Claude Code-ra épül. A modell maga a vezérlő hurok, a tudás pedig sima Markdown-fájlokban él (szabályok, skillek, döntési feljegyzések, wiki), amelyeket ember és gép egyaránt olvas, verziókezel és átnéz. Az integrációkat MCP-n (Model Context Protocol) keresztül kötöm be (levelezés, dokumentumok, projektkezelő), mert szabványos, és nem köt egyetlen keretrendszerhez sem.
A kurzuson végigvettük a LangGraph-ot, a CrewAI-t, az AutoGen-t és a Google ADK-t. Az egyik legfontosabb tanulság az volt, hogy éles környezetben ezeket gyakran lecserélik a modellgyártó saját API-jára. Én transforms is ebbe az irányba megyek: a következő, önállóan és ütemezetten futó rendszereimet saját, Claude-alapú ügynökmegoldásként építem, nem egy általános gráfkeretrendszerre.
Az adatoldalon szándékosan „unalmas” technológiát választok (BigQuery, Dataform, Cloud Run), mert egy pénzügyi rendszerben a reprodukálhatóság fontosabb az újdonságnál. emellett tudatosan két modellgyártót használok: az egyik ír, a másik ellenőriz. Ez a kurzuson tanult Team-of-Thoughts gondolata a gyakorlatban: a valódi sokféleség a különböző modellekből jön, nem ugyanannak a modellnek több példányából. A keretrendszerek jönnek-mennek, a jól leírt folyamat és a mérhető ellenőrzés marad.
Szerinted hogyan fogja átalakítani az Agentic AI a vállalati működést és a csapatok felépítését az elkövetkező 2–3 évben? Milyen új készségekre lesz szükségük a szakembereknek?
A szakértő munkájának súlypontja a végrehajtásról a specifikálásra és az ellenőrzésre tolódik. Egy kis pénzügyi csapat olyan rendszert épít és üzemeltet, amihez korábban külön adat- és fejlesztőcsapat kellett – ez nálunk már nem jóslat, hanem a jelen. A csapatok laposabbak lesznek, mert eltűnik a bürokratikus átadás a szakértő és a fejlesztő között.
Négy készség lesz kulcsfontosságú a jövőben:
-
Pontos feladatfogalmazás: Eredmény, hatókör és ellenőrzési szempontok kristálytiszta meghatározása.
-
Kritikus ellenőrzés: Képesség arra, hogy validáljuk a munkát, és ne higgyük el vakon, hogy kész.
-
Tudásrögzítés: A tudás írásbeli, gépileg is olvasható formába öntése.
-
Felelősségi határok tartása: Tudni, mit nem szabad kiadni (a döntést, az éles rendszerbe írást és a felelősséget).
A szakterületi tudás felértékelődik, mert az ügynök hibátlan kódot ír egy hibás könyvelési logikára is, ha senki nem veszi észre. A vezetőknek pedig meg kell tanulniuk ügynökflottát irányítani úgy, ahogy ma embereket: feladatkiosztással, jogosultságokkal és folyamatos átnézéssel.
Mi az, amire a KÜRT Akadémia Agentic AI képzése felkészített, és hogyan tudod ezt beépíteni a munkádba?
Azért jelentkeztem, mert önállóan futó, több ügynökből álló rendszereket akartam építeni. A képzés nyelvet és elméleti alapot adott annak, amit addig ösztönösen csináltam. A planner–worker hierarchia, a minimális kontextust kapó munkás ügynök, a kritikus vétójogával dolgozó „Team of Rivals” és a context engineering „minden fájl” szemlélete mind visszaköszönt a saját rendszeremben – most már értem is, miért működnek.
Különösen tanulságos volt a Berkeley MAST-kutatás, amely szerint a multi-ágens rendszerek hibáinak több mint 40%-a specifikációs hiba: ez megerősített abban, hogy a tervezés eleje nem luxus. Megkaptam a keretrendszerek (LangGraph, CrewAI, AutoGen, Google ADK) és a protokollok (MCP, A2A) térképét, és azt is, mikor érdemes ezeket elhagyni.
A legnagyobb meglepetés a RAG-blokk volt. Az előadók a szemünk előtt rakták össze a keresést az alapoktól: invertált index, BM25, dense és hibrid keresés, reranker, végül egy MCP-n keresztül Claude-hoz kötött chatbot. Ezt azonnal hasznosítani tudom: a riportjainkra és beszámolóinkra épülő keresőt tervezek, amely a kérdésre forrásmegjelöléssel, a megfelelő kimutatásból válaszol.
Ami még előttem van: az anyagok újraolvasása után egy valóban önállóan, ütemezetten futó ügynökrendszer megépítése. Ehhez a kurzus adta meg a tökéletes térképet.




Hozzászólások