OpenAI Agents API: mit jelent a Zapier-, Make- és n8n-felhasználóknak?

Az OpenAI szeptember 10-én nyilvános bétában elérhetővé tette az OpenAI Agents API-t, egy olyan felügyelt szolgáltatást, amely a cég saját Codex nevű fejlesztői ügynökét hajtó motort adja a fejlesztők kezébe egyetlen API-híváson keresztül. A bejelentés legtöbbet idézett részlete az volt, hogy az ügynökök irányításáért (angolul orchestration) az OpenAI nem kér külön díjat, így sok automatizációs szakember rögtön feltette a kérdést: ha a karmester ingyen van, minek fizessek havidíjat a Zapiernek, a Make-nek vagy az n8n-nek? A kérdés teljesen jogos, a válasz viszont jóval árnyaltabb annál, amit a lelkes LinkedIn-posztok sugallnak.

Egy magyar kis- vagy középvállalat szemszögéből a történet a pénztárcánál kezdődik. Az orchestration valóban díjmentes, a webkeresés, a fájlkeresés és a kódfuttatás viszont hívásonként vagy percenként számláz, a modell tokenjei pedig ugyanúgy fogynak, mint eddig. Ez az írás 2026. szeptember 22-i állapot szerint veszi végig, mit tud pontosan az új API, mennyibe kerül forintra átszámolva, mit nem old meg a triggerektől az OAuth-ig, végül azt is, mikor érdemes az n8n-nél vagy egy másik platformnál maradni és mikor éri meg közvetlenül az OpenAI-ra építeni.

Röviden

• Az OpenAI Agents API az OpenAI 2026. szeptember 10-én nyilvános bétába küldött felügyelt szolgáltatása, amely tartós munkamenetet, automatikus kontextustömörítést, igény szerinti eszközkeresést, programozott eszközhívást és alügynököket ad a fejlesztőknek, az ügynökök futtatását pedig az OpenAI infrastruktúrája végzi.
• Az orchestrationért nincs külön díj, de a hivatalos árlista szerint a webkeresés 1 000 hívásonként 10 dollár plusz a behúzott tartalom tokenjei, a fájlkeresés 1 000 hívásonként 2,50 dollár, a kódfuttató konténer pedig a memóriától függően 0,03 és 1,92 dollár közötti összeg 20 perces munkamenetenként.
• Saját számításunk szerint egy óránként tíz webkeresést futtató ügynök csak keresési díjban heti 16,80 dollárt költ, ami kerekített 320 Ft-os árfolyammal nagyjából 5 400 Ft, a behúzott tartalom tokenjeivel együtt pedig GPT-6 Astrával egyetlen hét alatt több mint kétszer annyiba kerül, mint az n8n Starter csomag havi 20 eurós díja.
• Az Agents API nem kezel triggereket, nincs hozzá kész connector-könyvtár OAuth-kezeléssel, a naplózás és a költségek átláthatósága pedig kezdetleges, vagyis pont azt nem adja meg, amiért a legtöbb KKV a Zapiert, a Make-et vagy az n8n-t használja.
• A legtöbb magyar KKV-nak a hibrid megoldás a legjobb: az eseményeket és az alkalmazások összekötését továbbra is az automatizációs platform intézi, a hosszú, sok lépéses gondolkodást igénylő részfeladatot pedig egy HTTP-hívással átadja az Agents API-nak.
• Közvetlenül az Agents API-ra akkor érdemes építeni, ha van a csapatban fejlesztő, a feladat napokig futó kutatás vagy kódolás, a bekötendő külső rendszerek száma pedig kicsi.

Mi az OpenAI Agents API és miben más, mint az eddigi OpenAI-eszközök?

Az OpenAI Agents API egy felügyelt szolgáltatás, amely az OpenAI Codex-ügynökét működtető, nyílt forráskódú futtatókeretet (harness) teszi elérhetővé egyetlen API-hívással. A fejlesztőnek így nem kell saját ciklust írnia a modellhívások, az eszközök és a memória kezelésére, mert a munkamenetet, a kontextust és az alügynököket az OpenAI szerverei tartják életben, akár napokig.

Ahhoz, hogy értsük, miért lett ekkora visszhangja, érdemes tisztázni, mi az a harness. Az AI-ügynök olyan program, amely egy nyelvi modellt eszközökkel (webkeresővel, fájlokkal, külső rendszerek API-jaival) köt össze és egy kitűzött cél felé több lépésben, önállóan halad. A modell maga csak szöveget vagy eszközhívási kérést ad vissza, valakinek tehát végre kell hajtania a kért műveletet, vissza kell adnia az eredményt, figyelnie kell a kontextus méretére, kezelnie kell a hibákat, végül el kell döntenie, mikor van kész a feladat. Ezt a vezérlő réteget hívja a szakma harnessnek. Eddig ezt írta meg a fejlesztő a saját szerverén, vagy ezt rakta össze vizuálisan valaki az n8n, a Make vagy a Zapier felületén.

Az OpenAI szeptember 10-i bejelentése szerint az Agents API ugyanazt az infrastruktúrát használja, amelyen a Codex és a ChatGPT ügynöki funkciói is futnak. A MarkTechPost aznapi összefoglalója saját fordításunkban úgy fogalmaz, hogy a szolgáltatás a kontextuskezelést, az eszközök összehangolását és az alügynökök irányítását intézve „napokig megbízhatóan futva tartja” az ügynököket. A bejelentés kódpéldái a szeptember 3-án megjelent GPT-6 Astra modellt használják. A béta minden API-fejlesztő előtt nyitva áll, a hozzáférést az OpenAI szeptember 21-én tovább szélesítette.

Az OpenAI termékpalettáján ezzel három réteg alakult ki. A Responses API egyedi modellhívásokra szolgál, amelyekhez eszközök is kapcsolhatók, az Agents SDK egy programkönyvtár, amelyet a fejlesztő a saját környezetében futtat és teljesen ő irányít, az új Agents API pedig a felügyelt, futtatással együtt kínált változat. Az AgentStack elemzése emlékeztet arra is, hogy a régebbi Assistants API augusztus 26-án leállt, miután az OpenAI egy évvel korábban bejelentette a kivezetését. Aki tehát még az Assistants API-ra épített, annak most mindenképp döntenie kell az új irányról.

A bejelentésben az OpenAI néhány ügyfél eredményét is közölte, ezek a gyártó saját adatai, ezért kellő fenntartással kezelendők. A Ciridae értékelési pontszáma 0,71-ről 0,85-re javult, miközben a válaszidő a negyedére csökkent, a SafetyKit esetenként 60%-kal alacsonyabb költségről számolt be, a Hypha pedig 86%-kal kevesebb sikertelen ügynöki válaszról. Egyik cég sem egy 12 fős magyar szolgáltató, a számok mégis jelzik, hol várható a haszon: hosszú, sok lépésből álló feladatoknál, ahol eddig a házilag írt vezérlés volt a gyenge pont.

Munkamenet, kontextustömörítés, eszközkeresés, alügynökök: mit tud az Agents API?

Az Agents API öt fő képessége a tartós munkamenet, az automatikus kontextustömörítés, az igény szerinti eszközkeresés, a programozott eszközhívás és az alügynökök kezelése. Ezeket eddig a fejlesztőnek kellett megírnia vagy egy keretrendszerből összeraknia, most viszont az OpenAI szervere intézi őket, így a fejlesztő a feladatra és a bekötött eszközökre koncentrálhat.

Munkamenet (session): az ügynök, amelyik nem felejt

A munkamenet egy tartós ügynökpéldány, amely a hívások között is megőrzi az állapotát az OpenAI infrastruktúráján. A MarkTechPost leírása szerint a munkamenetet létre kell hozni, a haladását folyamatos adatfolyamon (streaming) vagy webhookon keresztül lehet követni, a feladat folytatható, sőt menet közben új irányba is terelhető. Vegyünk egy képzeletbeli budapesti könyvelőirodát, ahol az ügynök hétfő reggel elkezdi összevetni negyven ügyfél bejövő számláit a NAV Online Számla rendszerből letöltött adatokkal. Kedden az egyik kolléga szól, hogy két ügyfelet hagyjon ki, mert náluk év közben könyvelőváltás történt, az ügynök pedig ott folytatja, ahol abbahagyta, a korábbi munkát nem kell újra elvégeznie.

A saját harnessnél ugyanez azt jelentette, hogy a fejlesztőnek adatbázisba kellett mentenie minden lépést, újraindításkor vissza kellett töltenie az állapotot, a szerver esetleges leállására is külön fel kellett készülnie. Ez a munka most lekerül a válláról, ami egy kisebb fejlesztőcsapatnál napokat spórolhat meg egy-egy projektben.

Kontextustömörítés: amikor megtelik a munkamemória

A modell kontextusablaka az a tokenben mért szövegmennyiség, amelyet a modell egyszerre lát (a token nagyjából egy szótagnyi vagy szórésznyi szövegdarab). Egy hosszú munkamenetben a korábbi lépések, keresési találatok és fájlrészletek előbb-utóbb kitöltik ezt az ablakot. Az Agents API automatikusan tömöríti a korábbi kontextust, amikor a munkamenet a határhoz közelít. Az AiCybr leírása szerint a feladathoz szükséges információk ilyenkor is megmaradnak.

A tömörítés lényegében összefoglalás, márpedig minden összefoglalásban elveszhet egy-egy részlet. Ha az ügynök egy számla bruttó összegét vagy egy ügyfél egyedi fizetési határidejét a tömörítés előtt látta, nem biztos, hogy utána is pontosan emlékszik rá. Tapasztalatunk szerint ezért minden olyan adatot, amelyre a folyamat végén szükség lesz, érdemes az ügynökkel egy külső táblázatba vagy adatbázisba is kiíratni ahelyett, hogy a munkamemóriájára bíznánk.

Eszközkeresés: kevesebb token minden körben

Minden eszköznek, amelyet az ügynök használhat, van egy leírása, amelyet a modellnek látnia kell ahhoz, hogy tudja, mikor és hogyan hívja meg. Ha egy ügynök hatvan eszközt kap és eszközönként nagyjából 150 token a leírás (ez saját becslésünk), akkor minden egyes körben mintegy 9 000 token megy el csak az eszközök bemutatására. A GPT-6 Astra 10 dolláros bemeneti tokenárán ez körönként 0,09 dollár, vagyis kerekített 320 Ft-os árfolyammal körülbelül 29 Ft, egy húszkörös feladatnál pedig már nagyjából 580 Ft, mielőtt az ügynök bármi hasznosat csinált volna.

Az eszközkeresés (tool search) ezt úgy oldja meg, hogy az ügynök csak a feladathoz ténylegesen szükséges eszközök leírását tölti be, amikor szüksége van rájuk. A MarkTechPost szerint ez csökkenti a tokenfelhasználást, ráadásul megőrzi a modell gyorsítótárát is. A gyorsítótárazott bemenet azért számít, mert az OpenAI árlistáján az Astra gyorsítótárazott bemeneti tokenje millió tokenenként 1 dollár a normál 10 dollár helyett, így ha az eszközlista nem változik minden körben, az ismétlődő rész tizedannyiba kerül.

Programozott eszközhívás: a köztes adat nem megy át a modellen

A programozott eszközhívás (programmatic tool calling) azt jelenti, hogy a modell nem egyesével kéri az eszközhívásokat, hanem kódot ír, amely párhuzamosan hív több eszközt, láncba fűzi őket és kódban szűri az eredményeket. Tegyük fel, hogy egy képzeletbeli debreceni webshop ügynökének meg kell találnia a múlt heti 300 rendelés közül azokat, amelyeknél a futárszolgálat késést jelzett. A hagyományos megoldásban mind a 300 rendelés adata átfolyna a modell kontextusán, programozott hívásnál a kód eleve kiszűri a tizenkét érintett rendelést és csak ezek kerülnek a modell elé. Ez kevesebb tokent, gyorsabb futást és kisebb tévedési esélyt jelent, mert a modellnek nem kell háromszáz sorban kutakodnia.

Alügynökök: munkamegosztás gépi kollégák között

Az alügynökök (subagents) önálló kontextussal kapnak meg egy-egy részfeladatot, míg a fő ügynök összehangolja és összefésüli az eredményeiket. Képzeljünk el egy 12 fős kecskeméti asztalosüzemet, ahol egy egyedi konyhabútor árajánlatához az egyik alügynök a lapanyagok és vasalatok aktuális árait kutatja, a második a meglévő ajánlatokból kikeresi a hasonló méretű korábbi munkákat, a harmadik pedig megírja az ajánlat szövegét a cég sablonja szerint. A fő ügynök a végén egyetlen, ellenőrizhető ajánlattervet ad le.

Az alügynököknek van egy kevésbé reklámozott oldala is: mindegyik a saját kontextusával dolgozik, tehát a saját tokenjeit fogyasztja. Három párhuzamos alügynök nagyjából háromszoros tokenköltséggel jár a részfeladatokban, még ha a teljes futás gyorsabb is lesz. Ez nem baj, csak tudni kell róla, mielőtt valaki minden apró feladatra alügynök-hadsereget indít.

Futtatókörnyezet: OpenAI-szerver, saját szerver vagy partner

Az ügynök által írt kód egy elszigetelt futtatókörnyezetben (sandbox) fut. A MarkTechPost szerint ez lehet az OpenAI által üzemeltetett sandbox, amely ugyanaz, mint a Codex és a ChatGPT mögött, lehet saját szerver, amely kimenő WebSocket-kapcsolattal csatlakozik, vagy kilenc partner valamelyike: a Blaxel, a Cloudflare, a Daytona, a DigitalOcean, az E2B, a Modal, az Oracle, a Runloop és a Vercel. Az AiCybr összefoglalója szerint az ügynök eszközként MCP-szervereket, egyedi függvényeket és beépített eszközöket (például webkeresést) is használhat. Az MCP (Model Context Protocol) nyílt szabvány, amellyel egy külső rendszer egységes módon kínálhatja fel a műveleteit az AI-ügynököknek, így egy meglévő MCP-szerver viszonylag kevés munkával bekapcsolható.

Mibe kerül valójában az OpenAI Agents API?

Az OpenAI Agents API-nak nincs alapdíja és az orchestrationért sem kell fizetni, a számla viszont három tételből áll össze: a modell tokenjeiből, a beépített eszközök hívásonkénti díjából és a kódfuttató konténerek percdíjából. Egy KKV-nál jellemzően a modellválasztás és a webkeresések száma dönti el, hogy havi néhány ezer vagy több tízezer forint lesz a végösszeg.

Az alábbi táblázat az OpenAI hivatalos API-árlistájának 2026. szeptember 22-i állapotát mutatja. A forintos oszlopot kerekített 320 Ft-os dollárárfolyammal számoltuk (a tényleges árfolyam szeptember 21-én nagyjából 317 Ft volt), így ezek tájékoztató értékek.

Friss fejlemény (2026. szeptember 22.): az OpenAI a cikk lezárásának napján kiadta a GPT-6 Sol és a GPT-6 Luna modellt. A hivatalos árlista szerint a GPT-6 Sol millió tokenenként 2 dollár bemenet, 0,20 dollár gyorsítótárazott bemenet és 10 dollár kimenet, a GPT-6 Luna pedig 0,10, 0,01 és 0,50 dollár, vagyis nagyjából fele annyiba kerülnek, mint a GPT-5.6-os elődjeik. A GPT-5.6 Solra és Lunára vonatkozó számok így mostantól az előző generációt mutatják, az olcsó sávban pedig a GPT-6 Luna lett az OpenAI legkedvezőbb ajánlata.

A konténereket az árlista szerint percre pontosan számlázzák, de munkamenetenként legalább öt percet felszámolnak. A webkeresésnél pedig könnyű elsiklani a „plusz tokenek” rész felett: a keresőindexből visszakapott szövegrészleteket a modell bemenetként olvassa el, ezért azokat a választott modell bemeneti tokenárán is kifizeted.

Egy óránként tíz keresést futtató ügynök heti költsége

Az AgentStack elemzése nyomán sokat idézett példa szerint egy óránként tíz keresést futtató ügynök egy hét alatt eléri az n8n Starter csomag havidíját. Érdemes ezt végigszámolni, mert jól mutatja, hol rejtőzik a költség. Az alábbi számítás saját becslésünk, a keresésenként behúzott szövegmennyiséget 2 000 tokenre feltételeztük.

• Óránként 10 keresés, napi 24 órában, heti 7 napon át: 10 × 24 × 7 = 1 680 keresés hetente.
• A keresési díj: 1 680 × 0,01 dollár = 16,80 dollár, ami 320 Ft-os árfolyammal 5 376 Ft.
• A behúzott tartalom: 1 680 × 2 000 token = 3,36 millió bemeneti token hetente.
• GPT-6 Astrával ez 3,36 × 10 dollár = 33,60 dollár, vagyis körülbelül 10 750 Ft, GPT-5.6 Lunával viszont csak 3,36 × 0,20 dollár = 0,67 dollár, azaz nagyjából 215 Ft.
• A heti végösszeg (a modell saját gondolkodása és válaszai nélkül) Astrával körülbelül 50,40 dollár, azaz 16 130 Ft, Lunával körülbelül 17,47 dollár, azaz 5 590 Ft.

Az n8n hivatalos árlapja szerint a Starter csomag éves számlázás mellett havi 20 euró, ami a szeptember 21-i, nagyjából 364 Ft-os euróárfolyammal 7 280 Ft. Astrával tehát már a keresések egyetlen hete is több mint kétszer annyiba kerül, mint egy havi n8n-előfizetés, míg a kisebb modellel egy hét alatt a havidíj háromnegyedénél tartunk. Egy hónapra vetítve csak a keresési díj 7 200 hívásnál 72 dollár, azaz 23 040 Ft.

A tisztesség kedvéért tegyük hozzá, hogy ez az összevetés almát hasonlít körtével. Az n8n havidíjában nincs benne a webkeresés, ha tehát egy n8n-folyamatban keresel, azért is fizetsz valamilyen kereső-API-nak vagy ugyanúgy az OpenAI-nak, a modell tokenjei pedig ott is fogynak. A példa tanulsága ezért nem az, hogy az Agents API drága, hanem az, hogy a „nincs orchestration-díj” mondatból senki ne következtessen ingyenes működésre. A költséget a feladat szerkezete határozza meg, nem a platform neve.

Kódfuttatás: a percdíj és az ötperces minimum

A kódfuttatás 20 perces munkamenetenként 0,03 és 1,92 dollár közé esik, attól függően, mennyi memóriát kap a konténer. Az 1 GB-os konténer percdíja így 0,0015 dollár, de az ötperces minimum miatt egy háromperces futás is 0,0075 dollárba kerül. Tegyük fel, hogy egy képzeletbeli pécsi nagykereskedés ügynöke munkanaponként 200 alkalommal futtat egy rövid, háromperces táblázatfeldolgozó szkriptet, 22 munkanapos hónappal számolva.

• 1 GB memóriával: 4 400 futás × 0,0075 dollár = 33 dollár, ami körülbelül 10 560 Ft havonta.
• 4 GB memóriával: 4 400 futás × 0,03 dollár = 132 dollár, ami körülbelül 42 240 Ft havonta.

A két sor között egyetlen beállítás a különbség. Egy egyszerű CSV-feldolgozásnak ritkán kell 4 GB memória, a fejlesztők viszont hajlamosak a biztonság kedvéért nagyobbat választani, ami ennél a számlázásnál négyszeres költséget jelent. Ha sok, néhány másodperces futásod van, érdemes őket egy munkamenetbe kötegelni, hogy ne fizess minden egyes alkalommal öt percet.

A legnagyobb tétel a modell, nem a platform

A leggyakoribb KKV-esetnél, az e-mailek feldolgozásánál látszik a legjobban, mennyire a modellválasztáson múlik a végösszeg. Vegyünk egy képzeletbeli debreceni webshopot, amely havonta 1 800 vásárlói levelet kap. Saját becslésünk szerint egy levél feldolgozása az ügynöknek 6 000 bemeneti tokent (levél, rendelési adatok, eszközleírások, utasítások) és 800 kimeneti tokent jelent.

Az Astra nagyjából 46-szor drágább ugyanarra a feladatra, egy egyszerű levélkategorizáláshoz pedig ritkán van szükség a képességeire. Ehhez képest egy havi 20 eurós n8n-előfizetés vagy egy havi 12 dolláros Make-csomag a teljes költség kisebbik része, ha nagy modellt használsz, kis modell mellett viszont épp a platformdíj lesz a legnagyobb tétel. Mindkét irányból ugyanaz a következtetés jön ki: előbb a feladathoz illő modellt kell kiválasztani, a platformról csak utána érdemes vitatkozni.

Mennyibe kerül ehhez képest a Zapier, a Make és az n8n?

A három nagy automatizációs platform belépő fizetős csomagja a hivatalos árlapok szerint 2026. szeptember 22-én havi 12 dollártól (Make Core) havi 20 euróig (n8n Starter, éves számlázással) terjed, a Zapier Professional pedig havi számlázással 19,99 dollárról indul. Az igazi különbség az elszámolási egységben rejlik, ez dönti el, melyik platform lesz olcsó a te folyamataidra.

A különbség a gyakorlatban így néz ki. Ha a debreceni webshop 1 800 levelét egy ötlépéses folyamat dolgozza fel, az n8n-ben ez 1 800 futtatás, ami belefér a Starter csomag 2 500-as keretébe. A Make-ben ugyanez nagyjából 9 000 kredit, ami még befér a Core csomag 10 000-es keretébe, a Zapierben viszont, ahol a trigger nem számít bele, négy művelettel számolva 7 200 task, amihez a 750 taskos belépő szint messze kevés, ezért a Zapier árlapján egy magasabb, drágább szintet kell választani. A platformok részletes összevetése külön témát érdemel, itt elég annyi, hogy a nagy volumenű, sok lépéses folyamatoknál az n8n futtatásalapú elszámolása a legkiszámíthatóbb.

Az integrációk számában a Zapier vezet 9 000-nél több alkalmazással és 400-nál több AI-eszközzel, a Make 3 000-nél több, az n8n pedig 1 500-nál több integrációt kínál. Mindhárom platform saját ügynöki funkciókat is épít. A Zapier árlapján külön Agents csomag szerepel, amelynek ingyenes szintje havi 400 aktivitást ad, Pro szintje évi 400 dollárba, vagyis havi 33,33 dollárba kerül. A Make új generációs AI Agents funkciója bétaként minden csomagban elérhető a szokásos kreditrendszeren belül, az n8n pedig AI Agent node-dal és folyamatosan bővülő MCP-támogatással dolgozik. Az OpenAI tehát olyan szereplők mellé lép be, amelyek maguk is ügynököket kínálnak, csak éppen triggerekkel és connectorokkal körülbástyázva.

Mit nem old meg az OpenAI Agents API a Zapierhez és az n8n-hez képest?

Az Agents API nem figyeli, mikor érkezik új e-mail, űrlap vagy megrendelés, nincs hozzá több ezer kész alkalmazás-csatlakozó, a jelszavak és OAuth-tokenek kezelése a fejlesztőre marad, a naplózás és a költségek követése pedig kezdetleges. Pontosan ezek adják a Zapier, a Make és az n8n valódi értékét egy KKV számára.

Triggerek: ki szól az ügynöknek, hogy dolga van?

A trigger az az esemény, amely elindít egy automatizmust: beérkezik egy levél, valaki kitölt egy űrlapot, új rendelés jön a webshopba, vagy elérkezik a hétfő reggel nyolc óra. Az AgentStack elemzése szerint az Agents API-ból éppen ez hiányzik, az ügynök ugyanis csak akkor indul el, ha valaki meghívja. A munkamenetnél említett webhook ráadásul kifelé irányuló értesítés a haladásról, külső események figyelésére tehát nem alkalmas. Aki közvetlenül az Agents API-ra épít, annak ezért kell egy saját szerver vagy ütemező, amely figyeli a postafiókot, fogadja az űrlapot és a megfelelő pillanatban meghívja az ügynököt.

Az AgentStack szerzője a saját munkafolyamatait is megszámolta: nála 11 a 3-hoz volt az arány a külső esemény által indított folyamatok javára. Egy tipikus magyar KKV-nál hasonló az arány, hiszen a legtöbb automatizmus arra reagál, ami a cég körül történik, ahelyett hogy magától indulna el egy kutatási feladattal.

Connectorok és OAuth: a bejelentkezés láthatatlan munkája

Az OAuth az a szabványos engedélyezési eljárás, amellyel egy alkalmazás a jelszavad megadása nélkül, korlátozott jogosultsággal fér hozzá például a Gmailhez vagy a Google Táblázatokhoz. Ennek kezelése sokkal több munka, mint amilyennek látszik: a hozzáférési tokenek lejárnak, frissíteni kell őket, a jogosultsági köröket (scope) pontosan be kell állítani, a hibákat is kezelni kell, amikor egy kolléga megváltoztatja a jelszavát. A Zapier, a Make és az n8n ezt kész connectorokkal intézi, míg az Agents API-nál mindez a te feladatod marad.

Az MCP-szerverek részben enyhítenek a gondon, mert egy kész MCP-szerver egységes módon adja át a műveleteit az ügynöknek. A hitelesítés és a hitelesítő adatok biztonságos tárolása azonban itt is a fejlesztőre hárul, ami nem elméleti kockázat: szeptember 7-én például a LiteLLM nevű eszköz MCP-hitelesítésében aktívan kihasznált bejelentkezés-megkerülési hibát jeleztek, amelyen keresztül a csatolt eszközök is elérhetővé váltak. Az n8n ezzel szemben a 2.37.0-s verziótól már adminisztrátor által kezelt, példányszintű hitelesítő adatokat is kínál, ami egy több munkatársas cégnél sokat számít.

Naplózás és hibakeresés: mi történt kedd hajnalban?

Az n8n-ben, a Make-ben és a Zapierben minden futtatásnak van előzménye, amelyben lépésről lépésre látszik, milyen adat ment be és mi jött ki. Ha egy ügyfélnek kiküldött levélben hibás összeg szerepel, ebből percek alatt kideríthető, melyik lépés rontotta el. Az AgentStack szerint az Agents API részletes naplózása és hibakeresési láthatósága egyelőre gyenge, ami ügyfél felé futó vagy könyvelési folyamatoknál komoly hiányosság. Az ügynököknél külön kockázat a látszólagos siker is: a Moveworks szeptember 14-én éppen azzal a fejlesztéssel állt elő, hogy sikertelen eszközhívásnál az ügynöke kifejezett hibaállapotot jelezzen, ne pedig sikert mutasson ott, ahol nem volt.

Költségláthatóság: melyik ügynök költötte el a keretet?

Az AgentStack elemzése a költségek átláthatóságát is a hiányosságok közé sorolja. A platformokon egy munkafolyamathoz tartozik a futtatásszám vagy a kreditfogyás, így havi szinten könnyű látni, melyik folyamat mennyibe kerül. Az Agents API-nál a számla tokenekből, keresésekből és konténerpercekből áll össze, alügynökök esetén több párhuzamos szálon, ezért ha nem címkézed és naplózod magad a futtatásokat, a hónap végén csak egy összesített összeget látsz majd.

Mit jelent ez konkrétan a Zapier-, a Make- és az n8n-felhasználóknak?

Rövid távon egyik platform felhasználójának sem kell váltania. A Zapier- és Make-felhasználók jellemzően fejlesztő nélkül dolgoznak, nekik az Agents API egyelőre nem alternatíva, az n8n-felhasználóknak viszont új, erős építőkocka lehet, amelyet egy HTTP-hívással be tudnak kötni a meglévő munkafolyamataikba.

Zapier-felhasználóként

A Zapier ereje a 9 000-nél több alkalmazás és az, hogy egy marketinges vagy irodavezető is össze tud rakni egy működő automatizmust. Az Agents API programozói tudást igényel, így egy tipikus Zapier-felhasználónak nem kiváltja a meglévő eszközét, legfeljebb kiegészítheti. A Zapier Professional csomag az árlap szerint tartalmazza a webhookokat, tehát technikailag egy Zap is meghívhat egy Agents API-munkamenetet, a hosszú ideig futó munkamenetek eredményének fogadása azonban már fejlesztői feladat. Ha ügynöki funkcióra van szükséged fejlesztő nélkül, először érdemes a Zapier saját Agents termékét kipróbálni.

Make-felhasználóként

A Make vizuális forgatókönyvei (scenario) HTTP-modullal bármilyen API-t meg tudnak hívni, így az Agents API bekötése itt is megoldható. A kérdés inkább az, megéri-e: a Make új generációs AI Agents funkciója bétaként már a meglévő kreditrendszeren belül fut, ezért egy Make-felhasználónak először ezt érdemes kipróbálnia. Az OpenAI-hoz akkor nyúlj, ha a feladat napokig tartó munkamenetet vagy komolyabb kódfuttatást igényel.

n8n-felhasználóként

Az n8n-felhasználók járnak a legjobban, mert az n8n eleve fejlesztőbarát, saját szerveren is futtatható és a HTTP Request node-dal pár perc alatt bármilyen API meghívható vele. Egy n8n-folyamat fogadhatja a triggert, összegyűjtheti az adatokat a CRM-ből és a webshopból, átadhatja a nehéz részt egy Agents API-munkamenetnek, majd a webhookon visszaérkező eredményt naplózhatja, jóváhagyásra küldheti és továbbíthatja. Az n8n szeptemberi kiadásai (a 2.39.0 és a 2.40.0) ráadásul éppen az ügynöki munkafolyamat-eszközök és az MCP hibakezelésén javítottak, ami ezt a hibrid felállást még stabilabbá teszi.

Hol futnak az ügynökök és mit mond erről a GDPR?

A MarkTechPost összefoglalója szerint a bétaidőszakban az Agents API adatai csak az Egyesült Államokban tárolódnak, a szabályozott munkaterhelésekre pedig a Zero Data Retention (adatmegőrzés nélküli üzemmód) nem érhető el. Egy magyar cégnek ezért személyes adatot csak adatfeldolgozói szerződés, frissített adatkezelési tájékoztató és átgondolt adatminimalizálás után érdemes az ügynökre bízni.

A GDPR szempontjából egy amerikai szerveren futó ügynök, amely ügyfélleveleket, rendelési adatokat vagy számlákat lát, adatfeldolgozásnak és harmadik országba irányuló adattovábbításnak minősül. Ehhez jogalap, megfelelő garanciák és a belső adatkezelési nyilvántartás kiegészítése kell. Kétség esetén jobb adatvédelmi szakemberrel egyeztetni vagy a NAIH útmutatóit fellapozni, mint utólag magyarázkodni. A saját szerveren futó sandbox az AiCybr szerint a hálózat, a hitelesítő adatok és az adatok helye feletti kontrollt a fejlesztőnél hagyja, a modellhívások azonban ettől még az OpenAI-hoz futnak be.

Az n8n-nek itt van egy csendes előnye: saját, akár hazai szerveren is futtatható, így a trigger, a naplók és a hitelesítő adatok a cég kezében maradnak, az ügynökhöz pedig csak az a minimális adat jut el, amelyre ténylegesen szüksége van. Ha az ügynök közvetlenül ügyfelekkel kommunikál, az Európai Unió mesterségesintelligencia-rendeletének (EU AI Act) 50. cikke szerint 2026. augusztus 2. óta jelezni kell, hogy a felhasználó AI-rendszerrel beszél. Ez egy chatablakban egyetlen mondattal teljesíthető, de nem szabad elfelejteni.

Mikor maradj n8n-nél és mikor építs közvetlenül az Agents API-ra?

Maradj az n8n-nél (vagy a Zapiernél, a Make-nél), ha a folyamataidat többségében külső események indítják, sok SaaS-rendszert kötsz össze és fontos a lépésenkénti napló. Közvetlenül az Agents API-ra akkor építs, ha van fejlesztőd, a feladat hosszú, kutató vagy kódoló jellegű, a külső rendszerek száma pedig kicsi.

Az AgentStack szerzője három feltételt nevez meg, amelyek mellett érdemes a meglévő platformnál maradni: ha a munkafolyamatok többségét külső esemény indítja, ha a havi orchestration-költség nagyjából 20 dollár alatt van, illetve ha ügyfél felé futó folyamatokhoz megbízható naplózás kell. Az Agents API-t szerinte új, meglévő ügyfélfüggőség nélküli ügynököknél és olyan feladatoknál érdemes kipróbálni, ahol a webkeresés vagy a kódfuttatás hívásonkénti díja indokolható. Mi ezt egy KKV-ra szabott döntési táblázattal egészítjük ki.

A hibrid felállás a gyakorlatban

A legtöbb magyar KKV-nál a két világ nem egymás vetélytársa, inkább munkatársa. Az automatizációs platform a cég idegrendszere, amely érzékeli az eseményeket és eljuttatja az adatokat oda, ahová kell, az Agents API pedig a nehéz gondolkodást igénylő feladatokra behívott specialista. Vegyünk egy képzeletbeli balatoni panziót, ahová főszezonban naponta több tucat foglalási és módosítási kérés érkezik levélben. Ezek többsége egyszerű, néhány viszont kifejezetten bonyolult: csoportos foglalás, speciális étkezési igények, rendezvény és transzfer egyben.

Az egyszerű leveleket egy n8n-folyamat egy kis modellel kategorizálja és sablonválaszt javasol hozzájuk. A bonyolult kérést ezzel szemben a folyamat egy Agents API-munkamenetnek adja át a foglalási naptár kivonatával és az árlistával együtt. Az ügynök ezután utánanéz a kért rendezvényhelyszín elérhetőségének, kiszámolja a csomagárat, megírja az ajánlat tervezetét, végül az eredményt webhookon visszaküldi az n8n-nek. Az n8n naplózza az egészet, a tervezetet jóváhagyásra elküldi a recepciónak, majd az engedély után kiküldi a vendégnek. A drága gondolkodás így csak ott történik, ahol valóban szükség van rá, miközben a napló és az emberi kontroll is megmarad.

Hogyan próbáld ki az Agents API-t kockázat nélkül?

A legbiztonságosabb út egyetlen jól körülhatárolt, nem ügyfél felé futó feladattal indulni, a triggert és a naplózást a meglévő platformon hagyni, költségkeretet beállítani és két hétig párhuzamosan futtatni a régi megoldással. Így valós számok alapján dönthetsz arról, hogy megéri-e tovább építeni.

• Készíts leltárt. Írd össze a meglévő automatizmusaidat, mindegyiknél jelölve, mi indítja (esemény vagy ütemezés), hány rendszert érint és mennyi benne a valódi mérlegelést igénylő lépés.
• Válassz egyetlen jelöltet. Ideális az a feladat, amely hosszú, több lépéses kutatást vagy fájlelemzést igényel, belső felhasználású és hiba esetén nem okoz kárt, például egy heti versenytárs-árfigyelő összefoglaló.
• Hozz létre külön projektet és költségkeretet. Az OpenAI fejlesztői felületén a kísérletnek legyen saját projektje, saját API-kulcsa és lehetőleg költségriasztása is, hogy a számla elkülönüljön a többi felhasználástól.
• Válaszd ki a modellt tudatosan. Kezdd a legkisebb modellel, amely még elfogadható minőséget ad, nagyobbra pedig csak akkor lépj, ha a mérések szerint szükséges.
• Hagyd a triggert a platformon. Az n8n, a Make vagy a Zapier indítsa a munkamenetet HTTP-hívással, az eredményt pedig webhookon fogadja vissza, így a meglévő naplózás és jogosultságkezelés is megmarad.
• Naplózz mindent saját táblába. Minden futtatásnál rögzítsd az időpontot, a felhasznált tokeneket, a keresések számát, a konténerpercet és az eredményt, mert ezt az Agents API ma még nem adja meg kényelmesen.
• Futtasd két hétig párhuzamosan. A régi megoldás maradjon élesben, az ügynök eredményét pedig egy kolléga vesse össze vele, az eltéréseket feljegyezve.
• Dönts számok alapján. Számold ki a feladatonkénti költséget forintban, a hibaarányt és a megtakarított munkaórát, majd döntsd el, hogy bővíted, módosítod vagy leállítod a kísérletet.

Milyen buktatókra figyelj az első ügynöknél?

A leggyakoribb buktatók a béta állapotból adódó változások, az elszabaduló költségek, az üzleti szabályok megsértése és a túl korai elköteleződés egyetlen szolgáltató mellett. Mindegyik kezelhető, ha az első projekt kicsi, mérhető és visszafordítható.

Az Agents API nyilvános béta, vagyis a működése és az árazása még változhat. Az OpenAI szeptember 29-én tartja a DevDay 2026 fejlesztői konferenciát San Franciscóban, ahol valószínűleg újabb bejelentések érkeznek, ezért nagyobb, éles rendszert érdemes legalább addig halasztani, egy kis kísérletet viszont már most el lehet indítani. A költségek elszabadulása főleg akkor fenyeget, ha egy ügynök ciklusba kerül és újra meg újra keres, vagy ha minden apró feladathoz alügynököket indít, ezért a projektszintű költségfigyelés nem opcionális.

Az üzleti szabályok betartása külön fejezet. Az Artificial Analysis és a Zapier július 6-án közzétett AutomationBench-AA tesztje 657 valószerű üzleti feladaton mérte a modelleket, a legjobb eredmény pedig mindössze 48,6% lett. Minden vizsgált modell megsértett üzleti szabályokat, feladatonként átlagosan 0,46 és 1,26 közötti alkalommal. A pénzügyi folyamatokban a modellek feleakkora sikerességet értek el, mint a supportban vagy az operációban. A tesztben szereplő modelleknek azóta újabb verziói jelentek meg, a tanulság mégis érvényes: ahol pénz vagy ügyfélkapcsolat a tét, ott az emberi jóváhagyást a folyamat szerves részeként kell megtervezni.

A szolgáltatóhoz kötődés kockázatát enyhíti, hogy az Agents API mögötti Codex harness nyílt forráskódú, egy OpenAI-specifikus munkamenet-logikát mégsem lehet egyik napról a másikra egy másik modellgyártóhoz átköltöztetni. Ha a vezérlés nagyobb része az n8n-ben marad, a modell vagy az ügynökszolgáltató később lényegesen kisebb munkával cserélhető, ami a gyorsan változó modellpiacon komoly biztosíték.

Miben segít a Convergo?

A Convergo abban segít, hogy az OpenAI Agents API és a meglévő automatizációs platformod ne egymás ellen, hanem egymást kiegészítve dolgozzon. Workflow automatizáció szolgáltatásunkban n8n-alapú folyamatokat építünk, amelyek fogadják a triggereket, naplóznak és ott hívják be az ügynököt, ahol a feladat valóban megkívánja. Egyedi AI-integráció keretében bekötjük az Agents API-t a CRM-edbe vagy a saját rendszeredbe, átgondolt jogosultságkezeléssel és költségfigyeléssel. Ha még azt sem tudod, melyik folyamatodnál érdemes kezdeni, az AI-felmérés során közösen kiválasztjuk a legjobb jelöltet. Az első lépés egy ingyenes egyeztetés, ahol átnézzük a jelenlegi automatizmusaidat.