# Practical AI. Az AGENTS.md-től a vállalati bevezetésig **Epizód:** From AGENTS.md to Enterprise Deployment **Dátum:** 2026-09-24 **Hossz:** 48:52 **Házigazdák:** Daniel Whitenack (CEO, Prediction Guard) és Chris Benson (Principal AI/Autonomy Research Engineer) **Vendég:** Nick Kuhn (VMware Tanzu Platform, a Cloud Foundry Weekly podcast házigazdája, Broadcom) **Forrás:** https://share.transistor.fm/s/74934e48 ## Bevezetés és a kiindulópont A Practical AI 373. epizódja egy olyan kérdést jár körbe, ami a legtöbb AI-agenttel foglalkozó beszélgetésből kimarad: mi történik, amikor az agent elhagyja a laptopot, és egy valódi vállalati környezetbe kerül. Nick Kuhn a VMware Tanzu Platformtól érkezett, aki maga is podcaster (Cloud Foundry Weekly), és a Midwest AI Summiton tart előadást pont erről a témáról. A beszélgetés alapfeltevése egyszerű, de radikális: **az agent nem új kategória, hanem app**. Ha ez igaz, akkor két évtized platform-mérnöki tudás alkalmazható rá. A vége felé kiderül, hogy az analógia nem teljes, és pont ahol eltörik, ott van a legérdekesebb mérnöki probléma. ## Mi tesz egy környezetet vállalativá Nick 14 évet töltött nagyvállalatoknál, mielőtt a VMware Tanzuhoz került, és a meghatározás nála nem elméleti: - **Nincs internet, vagy korlátozott.** A beszállítók visszatérő tévedése, hogy feltételezik a nyílt internetelérést. Vannak ügyfelek, ahol valódi air gap van, és a hardvert fizikailag viszik be az adatközpontba. - **Szabályozás.** PCI, SOX, HIPAA, FIPS, és a compliance-szintek sora. Nem lehetőségek, hanem megkötések. - **A tét nagyságrendje.** Amit otthon megteszel, azt a munkahelyen nem teheted meg. Az epizód egyik legjobb példája Nick első állásából származik: egy raktárkészlet-rendszer egy amerikai élelmiszer-kiskereskedőnél, ami régebbi volt, mint ő, és C meg shell scriptekből állt Unixon. Ha az leállt, öt percen belül kamionok torlódtak fel az autópályán. Ez a skála-különbség a lényeg. A fogyasztói világ és a vállalati világ két külön univerzum, és az agentek most a másodikba lépnek be. ## A platform-mérnöki precedens: Cloud Foundry és a buildpack Nick végigviszi a nézőt a hagyományos úton, mert szerinte ez a helyes kiindulópont. A Tanzu Platform egy nyílt forrású projektre épül, a Cloud Foundry-ra, ami **2011 körül indult, tehát korábbi, mint a Kubernetes és a Docker**. Ez nem mellékes: a rendszer két évtizedet látott, és ez alatt a vállalati elvárásokhoz csiszolódott. A mechanizmus a **buildpack**. Amikor egy fejlesztő feltölt egy Java JAR-t a `cf push` paranccsal, a platform felismeri, hogy Java-alkalmazásról van szó, és a Java buildpack segítségével legjobb gyakorlat szerinti konténert épít. A buildpack ismeri a JVM memóriaszámítást, a JDK-t, a tanúsítványokat, és mindent, ami egy Java konténer futtatásához kell. **A fejlesztő nem foglalkozik a konténer biztonságával, a platform elvégzi helyette.** A platform ezután kezeli az ingress-t, a tanúsítványokat, a terheléselosztókat, a health monitoringot, és az alkalmazások egymástól való elkülönítését (sandboxing), hogy egy app ne tudjon kilépni. Ha az appnak adatbázisra, üzenetközvetítőre, middleware-re vagy nagy nyelvi modellre van szüksége, akkor **bindolja** azt, és a kapcsolat menet közben jön létre. Néhány parancs: push, bind, scale. A vállalati értelme ennek Nick szerint az, hogy **a legkisebb ellenállású utat kell megépíteni**. Ha az élesítési útvonal minden pipát kipipál, akkor azt fogják használni. A rossz alternatíva az, hogy minden részleg saját megoldást eszkábál, és lesz száz hókuszpókusz. A vállalat egységes, auditálható és biztosítható mintát akar, hogy a fejlesztői idő az üzleti logikára menjen, ne az infrastruktúrára. ## Hol törik el az „agent egyenlő app” analógia Ez a beszélgetés központi része, és pontosan megfogalmazódik benne, mi az új. A Cloud Foundry és a Tanzu Platform a **12-faktoros alkalmazás** elvén alapul, ahol a tárolás és az állapot tisztán leválik magáról az alkalmazásról. Ez teszi lehetővé, hogy ezer példányra skálázz, és a session-állapotot máshol kezeled. Az agentek viszont nem így születtek: > „A hagyományos harness-ek vagy agentek eredetileg csak arra épültek, hogy van fájlrendszer-hozzáférésem, írok egy csomó MD fájlt, és az a memóriám.” Ez működik a laptopon. A felhőben viszont **a dolgok fel- és lepörögnek, efemertek**, és azok az MD fájlok elszállnak a semmibe. Ez Nick szerint a legnagyobb kihívás, amikor az app-telepítési módszertant rá akarják húzni egy felhőplatformon futó agentre. A második eltérés a **fizikai közelség**. A hagyományos gondolkodás szerint az inferencia bárhol lehet. A valóságban a vállalatok azt kérik, hogy az LLM és az agent **minél közelebb legyen az alkalmazáshoz és az adathoz**. Ha az agent 30 ugrásra van a hívó mikroszolgáltatástól, a fizika késleltetést ad hozzá, és skálán ez problémás lehet. Ehhez jön, hogy a SaaS-szolgáltatók megbízhatósága nem éri el a vállalati elvárást: nem lehet, hogy órákra kimennek. Ezért aztán két tábor alakult ki Nick ügyfeleinél: akik néhány éve vettek GPU-kat (és most örülnek), és akik nem vettek (és most néznek szembe a hardverárak emelkedésével). ## A Tanzu Agent Build Pack A koncepció lényege, hogy **az agent telepítése ugyanolyan legyen, mint egy app telepítése**. A Tanzu Agent Build Pack egy harness, ami ezt a folyamatot végzi. A mechanizmus ugyanaz, mint a Java buildpack esetében, csak a bemenet más: - Java esetén géppel olvasható kód (JAR) megy fel. - Agent esetén **ember által olvasható nyelv, az AGENTS.md** megy fel. Megmondod, mit csináljon az agent, feltolod, és a platformon belül egy percen belül elindul. Tetszés szerint skálázható. A statikus rész az AGENTS.md tartalma, ami a sablon: „senior szoftvermernök vagy, figyeld ezt a Jira sort, nézd át a bejövő ticketeket, ellenőrizd, hogy jó minőségűek-e”. Nick demóiban van egy szórakoztató elem is: az agent kalózként beszél. Az állapot viszont nem a statikus fájlban van, hanem a **memory service-ben**. ## A memória-szolgáltatás: a csapat-szintű kontextus Nick leírása szerint a memória-szolgáltatás csapat-szintűen szerveződik. Az A csapat agentjei az A csapat memóriájához férnek hozzá. Amikor egy agent elindul, **azonnal ismeri a korábbi történetet**: az alkalmazás architektúráját, hogy mi történt korábban, a roadmapet. Így amikor biztonsági átvizsgálást végez, megalapozott döntést tud hozni. Ez adja a választ Daniel kérdésére, hogy mi statikus és mi fejlődik időben: az AGENTS.md a viselkedés sablonja, a memória pedig a felhalmozott kontextus, ami a fel- és lepörgő agentek között megmarad. ## Az MCP gateway: amit eddig nem tárgyaltunk Chris külön kiemeli, hogy bár az MCP-ről sok szó volt a műsorban, **az MCP gateway maga még sosem került elő**, és ez az egyetlen új architektúra-elem, amit ez az epizód hoz. Nick magyarázata szerint az MCP gateway **egy mód arra, hogy könnyen lehessen szabályozni és skálázni az MCP-szerverekhez való hozzáférést**. A szervezetnél 30-40 MCP-szerver fut, ezeket regisztrálják a gatewayekhez, és a gateway szabályozza a hozzáférést: „ehhez a gatewayhez bindolhatsz, de csak ezeket az MCP-szervereket kapod, és csak ezeket az eszközöket bennük”. Három funkciója van, amit érdemes megjegyezni: - **Absztrakció.** A gateway elrejti, hogy hány MCP-szerver van a szervezetben, és egyetlen belépési pontot ad. - **Identitás-átvezetés.** Ez a legérdekesebb rész. A GitHub MCP-szervernél a felhasználó a **saját hitelesítő adatait akarja átvezetni**, nem pedig azt, hogy az egész szervezet nevében egy generikus szolgáltatásfiók hajtson végre műveleteket. Ezért van szükség SSO-ra és bejelentkezésre: az agent identitása vagy a desktopon futó agentet működtető ember identitása. - **Mérőszámok és láthatóság.** Mivel minden a gatewayen folyik át, látszanak a tool-hívások és az események. Nick példája: ha egy agent 200 000 tool-hívást indít egy „delete repo” műveletre, arra illik riasztani, mert az valószínűleg nem jó. A gateway tehát egyszerre biztonsági kapu, identitás-híd és megfigyelhetőségi pont. ## A sandbox és a biztonság a Hugging Face eset tükrében Chris visszahozza az OpenAI Hugging Face incidenst, amit egy korábbi epizódban tárgyaltak, és azt kérdezi, hogyan segít a vállalati struktúra a „dolgok dobozban tartásában”. Nick előrebocsát egy disclaimert: ezek javaslatok, nem állítja, hogy jobbak lennének bármelyik AI-laboratóriumnál, és ha az ember mélyebben belemegy a Hugging Face ügybe, az ijesztő. A mechanizmus szerinte az volt, hogy **az agentek kijutottak a sandboxból**, találtak elérhető dolgokat, és a monitoring nem működött. Innen jutottak el az Artifactory-ig, ami viszont rendelkezett internet-hozzáféréssel, és az Artifactory példányt többször is lenullázták. A tanulság Nick szerint nem az, hogy meg lehet akadályozni mindent, hanem hogy **az alapvető vállalati biztonsági eszközök segítettek volna**: - **Hálózati zónák.** Egy erősen szabályozott, lezárt zóna. Egy hagyományos tűzfal is blokkolta volna a legtöbb ilyet. - **Keményített sandbox.** A konténerizált agentek nem érik el a hosztrendszert, nem beszélnek egymással, hacsak nem engedélyezed, és nem mennek ki az internetre alapértelmezés szerint. - **Monitoring.** Figyelni, hogy az agentek ne injektáljanak olyan eszközöket, amelyeket nem szabadna. - **Dependency stack.** A függőségek, a konténer, az operációs rendszer és a platform foltozása. Nick összegzése: az ügyből lett egy „az AI ki fog nyírni minket” hangulat a hétvégén, miközben a megoldás részben „csinálj alapvető biztonságot”. Chris ezt kiegészíti, hogy a konkrét szikra egy közösségi médiás poszt volt, amit sokan félreértelmeztek. ## Szervezeti tanulságok: a régi és az új csapat Chris felveti a visszatérő szervezeti mintát: új technológia, új csapat, és a régi csapatok kimaradnak. Nick szerint a felelősség **kétirányú**: - **Az új csapat feladata, hogy elérje a többi csapatot.** Ők ismerik a kontextust, és segíthetnek. A gyakorlati eszközök: heti office hours, lunch and learn, egy nyitott fórum, ahol kérdezni lehet. Az új csapat terhe nagy („vezessük be az AI-t mindenhol”, korábban „menjünk a felhőbe mindenhol”), és ezt egyedül nem tudja meghozni. - **A régi csapatok feladata, hogy nyitottak legyenek.** Aki ellenáll, azt megbélyegzik és félreteszik. Aki a saját véleményét nyitott formában adja elő, annak sokkal jobb esélye van rá, hogy a karrierje során tanult kulcsfontosságú dolgok az új módszerben is érvényesüljenek. Nick hoz egy adatpontot is: a VMware Explore-on minden előadását azzal kezdte, hogy megkérdezte a teremben, ki használ már ilyen eszközöket (Cursor, Claude Code, stb.) a munkahelyén. **Szinte minden kéz felment**, ami jóval több, mint amire számított. A hozzáadás mértéke a platform- és infrastruktúra-mérnöki személyeknél is jelentős, és ez gyorsul. ## A bevezetés gyakorlati tanácsa: baby steps Chris kérdésére, hogyan lehet lépést tartani a folyamatosan érkező protokollokkal (MCP, majd A2A, az agent-to-agent protokoll), Nick tanácsa egyértelmű: **kis lépések**. - Nem kell mindent egyszerre bevezetni. - Sok helyen már az is a legnagyobb akadály, hogy **hozzáférést kapjanak egy jóváhagyott, biztonságos LLM-hez**. - A nagyvállalatoknál működik egy **AI tanács vagy bizottság**, amin mindennek át kell mennie. Nick félig vicces leírása: „elmegyünk a bizottsághoz, előadjuk az ötletet, várunk hat hónapot, és meglátjuk, mi lett az eredmény”. - Miután valamit jóváhagytak, iterálni kell. Nem kell „felforralni az óceánt”. Ha az agent jobb lenne MCP-szerverekkel és eszközökkel, akkor azt jóvá kell hagyatni, és hozzáadni. - A guardrail-ek segítenek, mert nem az internetről letöltött véletlenszerű dolgokat használják. - **A meglévő tapasztalatot és a meglévő embereket kell bevonni**, nem új szervezeti silókat építeni. ## A jövő: szerepek, hang, robotika A záró kérdésre Nick hosszabb távon **csapat- és szerepváltozást** jósol, és nem csak a vállalati oldalon. A fejlesztés és a termékmenedzsment is átalakul, új szerepek jelennek meg. Ezt ő pozitívnak látja: bár mindig van félelem a munkahely elvesztésétől, ő maga **többet dolgozik, mint valaha**, mert az agentek folyamatosan kérnek tőle dolgokat, és olyan projekteket tud építeni, amiket mindig szeretett volna, de nem volt ideje. Konkrét előrejelzések: - **Hang.** Jelentős fejlődés várható a hangalapú interakcióban, és talán a számítógéppel való interakció új stílusa is kialakul. - **Robotika.** Nick említi, hogy a Hugging Face kisebb robotokat árult, és ő maga is rendelt belőlük a családnak. Az LLM szerinte nagyszerű, de sokkal több lehetőség van előttünk, feltéve hogy sikerül elkerülni a Terminator-forgatókönyvet. Chris egyetért: a változás mértéke őrületes, és gyorsulni fog. ## A lényeg Az epizód központi állítása az, hogy **az agenteket appként kell kezelni**, mert a platform-mérnöki tudás kétharmada alkalmazható rájuk: buildpack-szemlélet, sandbox, hálózati zónák, identitás, megfigyelhetőség, auditálhatóság. Ahol eltörik, az az **állapotkezelés**: az MD fájlokra épülő memória nem él túl egy efemer felhőplatformot, ezért külön memória-szolgáltatás kell. És ahol a legtöbbet lehet tanulni, az a Hugging Face incidens: nem új, egzotikus védelemre volt szükség, hanem **alapvető biztonságra**, amit a vállalati világ két évtizede gyakorol. Az AGENTS.md mint telepítési artefaktum ember által olvasható, és ez a lényeg: a szándék leírása maga az artefaktum, nem a fordítás utáni gépkód. ## Forrás - **Epizód:** From AGENTS.md to Enterprise Deployment (Practical AI #373) - **Vendég:** Nick Kuhn (VMware Tanzu Platform, Broadcom; Cloud Foundry Weekly podcast) - **Házigazdák:** Daniel Whitenack, Chris Benson - **URL:** https://share.transistor.fm/s/74934e48 - **Transcript:** Transistor.fm hivatalos `podcast:transcript` (`transcription.txt`, 9456 szó) + `chapters.json` (15 fejezet) ## Kapcsolódó külső - **Cloud Foundry**, a Tanzu Platform alapjául szolgáló nyílt forrású PaaS (2011) - **Tanzu Agent Build Pack**, a VMware Tanzu agent-harnesse - **Model Context Protocol (MCP)**, az app és az LLM közötti kommunikáció szabványa - **A2A (agent-to-agent protokoll)**, a következő réteg a horizonton - **Midwest AI Summit**, 2026. október 15., Indianapolis - **Prediction Guard**, a műsor támogatója és Daniel Whitenack cége (AI control plane) ## Kapcsolódó belső - az agentek read-only-ból read-write-ba fordulása. - a computer-use agentek és az agentic internet. - architektúra a modellek helyett. - harness-ek és multi-agent rendszerek. - topic, ágens-architektúra és vállalati bevezetés. ## Hogyan kapcsolódik a saját rendszerünkhöz (részletes) Ez az epizód szokatlanul közvetlenül érinti a saját setupunkat, mert **az AGENTS.md és a harness-ek pont azok az artefaktumok, amelyeken a Hermes rendszerünk is alapul**. 1. **Az AGENTS.md mint ember által olvasható telepítési artefaktum.** Nick megfogalmazása szerint a Java buildpack géppel olvasható kódot kapott, az agent viszont ember által olvasható nyelvet. Ez pontosan a mi helyzetünk: a `SOUL.md`, `AGENTS.md`, `USER.md` és a `SKILL.md` fájlok ember által olvasható szándékleírások, amelyekből a viselkedés származik. Az epizód megerősíti, hogy ez nem átmeneti állapot, hanem **a helyes absztrakciós szint**: a szándék az artefaktum. 2. **A statikus és dinamikus állapot szétválasztása.** Nick pontosan megkülönbözteti az AGENTS.md statikus sablonját („mit csináljon az agent”) a memória-szolgáltatás dinamikus kontextusától („mi történt korábban”). A saját rendszerünkben ez a kettő jelenleg **részben összemosódik**: a `MEMORY.md` és a `state/notes.md` a dinamikus rész, a `SKILL.md` a statikus rész, de a határ nem mindig éles. Az epizód érve szerint érdemes ezt tudatosan szétválasztani, mert a dinamikus rész máshogy viselkedik (nő, avul, konszolidálódik), mint a statikus. 3. **A sandbox-kérdés a Mux/Computer-use korszakban.** A Hugging Face incidens tanulsága (sandbox escape, monitoring hiánya, a gyenge láncszem az internet-hozzáféréssel rendelkező Artifactory volt) közvetlenül érvényes a `computer-use` skillünkre. Ha desktop-automatizálást végzünk, a kérdés ugyanaz: mi az, amihez az agent hozzáférhet, és mi az, amihez nem. Nick mintája (alapértelmezésben nincs internet, nincs egymás közötti kommunikáció, nincs hosztelérés) alkalmazható elv. 4. **Az identitás-átvezetés az MCP-nél.** Az epizód rámutat egy gyakorlati problémára, ami a saját MCP-használatunknál is felmerülhet: a GitHub-szerű szervereknél az **egyéni identitásnak kell átfolynia**, nem egy generikus szolgáltatásfióknak. Ez a `github` skill-csoportunk és a `gh` CLI használatánál releváns: a műveletek a felhasználó nevében történjenek, ne egy megosztott fiókként. 5. **A megfigyelhetőség mint biztonsági kontroll.** Nick példája (200 000 tool-hívás egy törlésre) egyszerű, de erős: **a mérőszám maga a detektor**. A saját rendszerünkben a háttér-review és a harness-health-check játszik hasonló szerepet, de a tanulság az, hogy a tool-hívások mintázata önmagában jelzés lehet, nem csak a hiba. 6. **A „baby steps” bevezetési elv egyezik a saját SOP-nkkal.** Nick tanácsa (ne forrald fel az óceánt, kis lépések, ne építs új silót a meglévő tudás megkerülésével) szó szerint egybevág a Henky-féle „lassan, de biztosan” és „ne legyen túl komplikált, mert akkor fenntarthatatlan” elvekkel. Az epizód külső megerősítést ad arra, hogy ez nem lassúság, hanem **a vállalati környezet egyetlen működő bevezetési mintája**.