# Practical AI #358 — Rebooting Enterprise AI with MCP and Kubernetes **Dátum:** 2026. május 28. **Epizód:** #358 | **Hossz:** 48 perc **Vendég:** Craig McLuckie (CEO, Stacklok; Kubernetes társalapító) **Hostok:** Daniel Whitenack, Chris Benson **Link:** https://share.transistor.fm/s/d76e02d5 **Feldolgozás:** Whisper medium modell, teljes transzkript --- ## Összegzés Craig McLuckie a Kubernetes egyik társalapítója, aki most a Stacklok CEO-jaként azt a kérdést teszi fel: mi történik, amikor az AI-ágensek nem chatbotként, hanem munkatársként kezdenek viselkedni? A beszélgetés mélyen belemegy az MCP (Model Context Protocol) vállalati infrastruktúrájába — hogyan kell menedzselni 10, 100, 1000 ágenst, és milyen infrastruktúra-réteg kell hozzá, ami nem a fejlesztő asztali gépére támaszkodik. McLuckie párhuzamot von a Docker/Kubernetes forradalom és az MCP jelenlegi pillanata között: mindkettőnél egy egyszerű fejlesztői eszköz egyszerre oldott meg egy azonnali problémát (konténerizáció / eszköz-integráció) és mutatott túl egy orchestrációs rétegre (Kubernetes / MCP gateway + control plane). --- ## Fő Témák ### 1. McLuckie háttere és a Docker-pillanat - Infrastruktúrás ember teljes karrierje során: Microsoft → Google (Google Compute Engine), Kubernetes társalapító (Joe Bedával), Heptio (VMware felvásárolta), Tanzu - Amikor először látta a Dockert, két dolgot látott egyszerre: (1) megold egy nyilvánvaló fejlesztői problémát (alkalmazások csomagolása függőségekkel), (2) át lehet látni rajta a Kubernetes-t — egy orchestrációs rendszert, ami komplex alkalmazások futtatását teszi lehetővé - **Ugyanezt a pillanatot élte át az MCP-vel:** egyszerre írja le, hogy néz ki egy AI-natív alkalmazás (LLM mint megjelenítési réteg + view model), és mutatja meg, milyen kontroll-réteg kell az ágensek biztonságos integrálásához ### 2. Mi az MCP és miért fontos? - Az Anthropic által kifejlesztett Model Context Protocol: a külvilágot írja le egyszerű természetes nyelvi fogalmakkal, JSON schema háttérrel - **"Szelektíven áteresztő membrán"** a szervezet meglévő rendszerei körül — érték áramlik mindkét irányba, de kontrollal - Az LLM-ek jól értenek a szemantikai kinyeréshez, de nehezen boldogulnak hagyományos API-k hitelesítésével és determinisztikus eszközhasználatával - Az MCP ezt a hidat építi meg: az LLM felfedezi, milyen eszközök állnak rendelkezésre, és determinisztikusan tudja meghívni őket ### 3. Konkrét példa: a toborzó munkafolyamata - Egy toborzó naponta ugrál Gmail, LinkedIn, Google Calendar, CRM rendszerek között - MCP-vel ezek egységesen "főnevek és igék" formájában íródnak le: mi egy jelölt, mi egy naptár-meghívó, mik a műveletek (interjú ütemezése) - **Hitelesítés és jogosultság:** a toborzó Okta/Entra identitása alapján az ágens ugyanazokhoz a rendszerekhez fér hozzá — de csak kontrollált módon. Nem akarod, hogy egy AI-asszisztens korlátlan hozzáférést kapjon az emailjeidhez ### 4. A teljes stack négy komponense McLuckie szerint egy vállalati MCP platformnak négy részből kell állnia: 1. **Runtime** — biztonságos futtatókörnyezet. Jelenleg a legtöbben `npx run`-nal indítanak MCP szervert, ami "Isten őrizz, ha egy hacker feltörte" kategória. Konténerbe zárt, ellenőrzött futtatás kell 2. **Registry** — milyen szervereket használhatsz? Melyek megbízhatóak? Szervezeti szintű, előre auditált, szkennelt MCP szerverek katalógusa 3. **Gateway** — egyetlen végpont, ami az összes MCP szervert exponálja Claude, Codex, vagy bármilyen kliens felé 4. **Control plane** — amikor 1-ről 1000 szerverre és usercsoportokra lépsz, kell egy irányító réteg **A két könyvtámasz (bookends):** - **LLM gateway** — forgalomirányítás különböző modellek felé, policy érvényesítés - **MCP gateway** — valós rendszerek csatlakoztatása, auth proxy, tool management A kettő között jönnek az agentic keretrendszerek (Harness, n8n, Crew, LangGraph), memóriakezelés, session management. ### 5. Identitás és autentikáció — a háromlábú szék - Az MCP specifikáció OAuth 2-re épül: OIDC token → MCP szerver azonosítja a felhasználót - De ez nem elég. Három identitás-réteg kell: 1. **Service account identity** — az agent végpont azonosítása 2. **Role-based claims** — az agent tulajdonosa által biztosított jogosultságok 3. **On-behalf-of claims** — a felhasználótól örökölt jogosultságok, amiket az agent a felhasználó nevében használ - **Token exchange minták:** straight passthrough, federated trust, API key exchange — mind a proxynak kell kezelnie, nem a szerver fejlesztőjének - Joe Beda (Stacklok CTO, McLuckie társalapítója) írta a SPIFI paper-t ~10 éve — a zero trust identitás keretrendszert, amire most végre szükség lesz ### 6. Miért kell proxy réteg az MCP elé? - **Láthatóság és governance:** amikor egy "interjú ütemezése" három rendszert érint, és a meghívó csak az egyik naptárban jelenik meg, trace kell a debuggoláshoz - **Tool pollution kezelése:** 4 MCP szerver = 150 tool = 20-30 ezer token minden interakciónál, csak a tool leírások miatt. Egy proxy `find_tool` + `use_tool` végponttal 80-90%-kal csökkenti ezt - **Kisebb LLM-ek:** Haiku/small modellek hírhedten rosszak tool invocation-ben. Egy proxy single-endpointra szűkítve 95-97%-ra hozza fel a pontosságot - **Szemantikai egyértelműsítés:** "feature" egy GIS rendszerben = vektorok gyűjteménye, GitHub MCP szerverben = termékfunkció. A proxy átnevezheti "GIS feature"-re és "product feature"-re ### 7. ToolHive — a sárga köves út - **Nyílt forráskódú (Apache 2.0).** "Az Anthropic, OpenAI, Google leírják Smaragdvárost. Valakinek meg kell építenie a sárga köves utat." - **Alapelv:** Linux konténerbe csomagolt MCP szerverek. Az enterprise-ök már tudják scannelni, hardenelni, SDLC-n átvinni az OCI image-eket - **Registry:** előre auditált, szkennelt közösségi MCP szerverek + saját szerverek feltöltése - **vMCP gateway:** virtuális MCP szerver, ami usercsoporthoz és feladathoz igazítja a tool készletet. Pl. a toborzó csak `schedule_interview`-t lát, ami mögött több rendszer tranzakciója fut atomikusan - **Kubernetes control plane:** 50% hó/hó növekedés a Kubernetes-alapú MCP futtatásban — milliónyi tool invocation ### 8. Agentic Concurrency — a termelékenység kvantumugrása - McLuckie mérnöki csapatának áteresztőképessége **60%-kal nőtt egy hét alatt**, ahogy elkezdtek szisztematikusan párhuzamosan agenteket használni - A kulcs: **5-15 ágens egyidejű futtatása**, mind más-más szereppel és kontrollált eszközhozzáféréssel - "A fejlesztőim most teljesítmény-sportolók" — Dev Lake, hook-ok, minden ágens-használat monitorozva, korrelálva - Sok tokenbe kerül, de "több mint megtérül termelékenységben" - Ez a minta átvihető minden tudásmunkásra — de a fejlesztői asztal nem lehet az aggregációs pont, platform csapat kell mögé ### 9. A jövő: sztochasztikus reconciliation - A Kubernetes reconciliation loop-jai eddig determinisztikusak voltak. Most jön a lehetőség sztochasztikus rendszerekre, amik öngyógyító, önoptimalizáló infrastruktúrát vezérelnek - Amikor egy pod crash loop back off-ban ragad és a determinisztikus reconciler eléri a határait, egy AI ágens léphet be, hogy kitalálja mi történt és visszaterelje a rendszert - **Ágensek figyelik az ágenseket:** evaluator agentek, human-in-the-loop, mintavételezés és aggregált jelzések - "Még tanuljuk közösségként, hogy néz ki a sztochasztikus reconciliation" --- ## Kulcs Tanulságok 1. **Az MCP ugyanazt a pillanatot éli, mint a Docker 2013-ban** — egy egyszerű fejlesztői eszköz, ami egyszerre old meg azonnali problémát és írja elő a következő infrastruktúra-réteget (gateway, control plane, registry) 2. **A négy komponens (runtime, registry, gateway, control plane) elkerülhetetlen** — ahogy az MCP szerverek száma 1-ről 1000-re nő, ezek nélkül káosz lesz 3. **Az identitás háromlábú szék** — service account + role claims + on-behalf-of claims. Token exchange a proxyban, nem a szerverben 4. **A proxy nem luxus, hanem szükségszerűség** — tool pollution (80-90% token csökkenés), szemantikai egyértelműsítés, observability, policy enforcement 5. **Az agentic concurrency a termelékenység következő hulláma** — 5-15 párhuzamos ágens 60%-os heti áteresztőképesség-növekedést hozott egy valós mérnöki csapatnál 6. **A fejlesztői desktop nem skálázható** — a tudásmunkások nem fognak saját MCP szervereket buildelni és futtatni. Platform csapat kell --- ## Figyelemre Méltó Idézetek > "A történelem nem ismétli önmagát, de gyakran rímel. Amikor először láttam a Dockert, ugyanazt éreztem, mint most az MCP-vel: egy eszköz, ami egyszerre old meg egy fejlesztői problémát, és mutat túl egy orchestrációs rétegre." > "Az MCP egy szelektíven áteresztő membrán, amit egy szervezet a meglévő rendszerei köré vonhat — érték áramlik mindkét irányba, de kontrollal." > "Az Anthropic, OpenAI, Google leírják Smaragdvárost. Valakinek meg kell építenie a sárga köves utat." > "A fejlesztőim most teljesítmény-sportolók. Az áteresztőképességünk 60%-kal nőtt egy hét alatt, mert a csapat 5-15 párhuzamos ágenst kezdett használni szisztematikusan." > "A legnehezebb probléma egy autonóm ágensnél: rávenni, hogy meghívja azt a fránya tool-t, amikor kell. Kisebb LLM-eknél 20-30 tool-lal felejtsd el. Egy proxy mögé téve 95-97%-ra felmegy."