Past vendor lock-inu u AI nástrojů: stavte workflow na MCP, ne na jednom dodavateli

Koncem června strávili dva naši inženýři víkend tím, že si část denní práce přestěhovali do Antigravity, kam Google přesouvá dosavadní Gemini CLI. Bylo rychlé, umělo MCP a zapadlo do toho, jak už pracujeme. Během pár dní nám přestala fungovat napojení na MCP, která jsme si nastavili. Časově to odpovídalo tomu, že Google ve stejném týdnu přesunul přístup pro uživatele tarifů Free, Pro a Ultra ze samostatného Gemini CLI do Antigravity CLI. Antigravity dnes v dokumentaci popisuje širokou podporu MCP, takže to, na co jsme narazili, vypadá spíš jako potíže při přechodu než jako odstraněná funkce. Prakticky to ale vyšlo nastejno: sestava, do které jsme investovali víkend, přestala umět přesně to jedno, kvůli čemu jsme si ji pořídili.

První reakce je odsoudit nástroj a jít hledat lepší. Jenže porucha, kterou jsme ten týden zažili, byla na nás, ne na něm. Předejít jsme jí mohli sami.

Žádný z našich nástrojů nepřestal fungovat. MCP servery, na které se napojujeme, běžely dál. Skilly, na kterých tým staví, zůstaly platné. Rozbil se předpoklad, že konkrétní runtime nám je bude vystavovat pořád stejně. Z roadmapy cizího dodavatele se nám stala nosná zeď té naší.

Ten rozdíl rozhoduje o tom, co uděláte dál. Když je problém špatný nástroj, půjdete si koupit lepší a za čtvrt roku budete stát na stejném místě. Když je problém workflow přivázané k jedinému runtimu, změníte způsob, jak ho stavíte, a příští konec podpory vás bude stát odpoledne místo týdne.

AI vývojářské nástroje procházejí nejdivočejším obdobím, jaké jsme dlouho neviděli. Nová IDE, CLI i agentní runtimy vycházejí prakticky každý týden. Každý přidá schopnost, kterou ostatní nemají, něco jiného potichu zruší nebo mezi dvěma verzemi změní, jak se na něj napojujete. Oboru to prospívá. Týmu, který takový nástroj bere jako trvalý, ne.

Vaše workflow se tak rychle nemění a nemá proč. Způsob, jak tým plánuje, reviewuje, dodává a sahá na interní systémy, je pomalu se měnící aktivum. Jakmile ho přivážete k rychle se měnícímu runtimu, jeho nestabilita se stane vaší. Funkce, na kterou jste si zvykli, může zmizet podle cizího release plánu. Migrace vás nemine, ať jste s ní počítali, nebo ne.

Ten víkend jsme nevybrali špatně. Postavili jsme se na vrstvu, kterou neřídíme, a stejnou lekci by nám dřív nebo později dal kterýkoli dodavatel.

Většina hodnoty, která v AI workflow vydrží, není v runtimu. Je o vrstvu níž.

Runtime je chatové okno, integrace v editoru, agentní smyčka. Je to část, na které dodavatelé pracují nejvíc a kterou mění nejčastěji. Pod ní leží Model Context Protocol servery, které vaše databáze, CRM, interní API a knowledge base zpřístupní modelu, jenž zrovna práci řídí. Opravdová práce je v těch napojeních. Tam je vaše business logika.

MCP je záměrně nezávislé na runtimu. Server napsaný pro jednoho klienta funguje i s dalším, protože kontraktem je protokol, ne dodavatel. Runtime proto držte tenký, aby šel vyměnit, a práci, kterou nechcete dělat dvakrát, dejte do MCP vrstvy. Když stavíte takto, přechod na jiný runtime přestane být migrací a stane se změnou konfigurace. Nástroje přesměrujete na nového klienta, protože klient je nikdy nevlastnil.

Ze stejného důvodu jsme opatrní u governance, která pokrývá jen jednoho AI klienta. Jak píšeme v poznámkách z terénu o stavbě MCP governance pro enterprise, řídicí vrstva nad jedním klientem není řídicí vrstva, ale funkce toho klienta. S přenositelností je to stejné. Workflow, které běží jen v jednom runtimu, patří tomu runtimu a vy si ho jen pronajímáte.

Trh se tímto směrem hýbe sám, což z přenositelnosti dělá opatrnou volbu, ne odvážnou.

Nejzřetelněji je to vidět na rozšířeních pro VS Code. GitHub Copilot, Cursor a Codex se sjednocují na Agent Plugins, otevřeném standardu pro balení skillů a MCP serverů. Claude Code má vlastní formát, ale i ten VS Code rozpoznává. Mezi IDE tak dnes přenesete skilly a konfigurace MCP serverů, kdežto definice agentů a hooků zůstávají u konkrétního klienta. Stejný vzorec ukazuje MCP: standardizuje se způsob, jakým nástroje sahají na externí systémy, zatímco runtimy nad ním dál soupeří a mění se. Vyplatí se proto sázet na tu spodní vrstvu, ne na runtime nad ní.

Neznamená to, že jsou dnes všechny nástroje zaměnitelné. Runtimy se pořád liší a podle některých z těch rozdílů se vyplatí vybírat. Znamená to jen, že části, na které se vyplatí vsadit na rok dopředu, jsou ty přenositelné.

Po víkendu s Antigravity jsme si stanovili jedno pravidlo: co má vydržet, patří do MCP serverů a skillů, ne do konfigurace jednoho runtimu. Nové IDE posuzujeme podle toho, co umí, ale nic kritického v něm nesmí zůstat jako jediná kopie.

Prakticky to znamená gateway. Místo abychom každého AI klienta napojovali přímo na každý nástroj, dáme mezi ně Local MCP Gateway. Klienti míří na gateway a ta drží napojení na nástroje, přihlašovací údaje i profily, které určují, které workflow uvidí které nástroje. Výměna runtimu znamená přesměrovat jeden endpoint. Nástroje, přístupová pravidla ani auditní stopa se nehnou, protože runtimu nikdy nepatřily.

Týmům, které kolem tohoto vzoru potřebují podporovanou produktovou vrstvu, ho dodáváme jako MCP Gateway Enterprise. Argument o přenositelnosti a argument o governance jsou dva pohledy na tutéž věc. Díky neutrální vrstvě před nástroji je můžete zároveň řídit a udržet nezávislé na tom, který klient je zrovna v módě. Týmy, které si ten model chtějí osahat v praxi, ho s námi obvykle procházejí na workshopu k AI security a MCP governance.

Nezávislost na runtimu je směr, ne vyřešený problém.

Ne každý nástroj je zatím přenositelný. MCP servery se hodně liší zralostí. Některé mají čistou implementaci podle aktuální specifikace, jiné jsou pre-spec, hlavně u autentizace. Než se začnou napříč klienty chovat stejně, dá to práci server po serveru. Přenositelnost je reálná, ale v detailech není zadarmo.

Funkce vázané na jeden runtime jsou skutečné pokušení. Nové IDE jsme přes víkend nasadili právě proto, že něco umělo dobře. Část nejlepších schopností v AI nástrojích je dnes vázaná na konkrétní runtime. Volba přenositelnosti tak občas znamená odepřít si funkci, která existuje jen na jednom místě, nebo přijmout, že o ni přijdete, až to místo změní směr. Ten kompromis je věc úsudku, ne pravidlo.

I tenký runtime potřebujete vyhodnotit. Brát runtime jako vyměnitelný neznamená brát ho jako nedůležitý. U každého pořád musíte posoudit, jak dobře řídí vaše modely, jak zachází s kontextem a jak čistě zvládá MCP. Vyměnitelný a zaměnitelný není totéž.

Než si na nový AI nástroj zvyknete, tři otázky vám řeknou většinu toho, co potřebujete vědět.

Zaprvé: co byste reálně ztratili, kdyby ten runtime příští měsíc zmizel? Když odpověď zní „pěkné rozhraní“, je to v pořádku. Když zní „polovinu toho, jak se napojujeme na vlastní systémy“, svázali jste to příliš těsně.

Zadruhé: je hodnota, kterou přidáváte, v runtimu, nebo pod ním? Konfigurace, napojení nástrojů a přístupová pravidla, které existují jen uvnitř jednoho klienta, jsou závazek. Tytéž věci vyjádřené jako MCP servery za neutrálním endpointem jsou aktivum.

Zatřetí: dokázali byste tento týden přejít ke konkurenčnímu runtimu? Když je přechod změna konfigurace, máte přenositelnost. Když je to projekt, máte lock-in a zaplatíte ho, jakmile přijde další konec podpory.

Víkend s Antigravity nás stál pár dní a naučil nás něco, co bychom se radši naučili levněji. AI runtimy se budou měnit dál a rychle. Ty, které dnes působí nejtrvaleji, vás nejspíš překvapí jako první. Nebráníte se výběrem dokonalého nástroje. Bráníte se tím, že z nástroje uděláte tu nejméně cennou a nejsnáz nahraditelnou část sestavy a skutečnou investici uložíte do přenositelné vrstvy pod ním.

Pokud zrovna vybíráte AI coding nástroj, máme pro vás zprávu z praxe, která porovnává Claude Code, Cursor a GitHub Copilot z produkčního provozu. Popisuje, kde každý z nich v integracích obstojí a kde ne. A jestli chcete vidět, jak neutrální vrstva nástrojů nezávislá na runtimu vypadá ve vašem vlastním workflow, ozvěte se. Pustíme gateway na vašich systémech a řekneme na rovinu, kde vás přenositelnost pořád něco stojí.