Začalo to obyčejnou frustrací. Přes dvacet let jsem se v technologiích pohyboval kolem financí — platebních systémů, bank, R&D týmů, které musely brát vážně, odkud data pocházejí a jak moc jim lze věřit. Když jsem pak chtěl dát jazykovému modelu do ruky česká veřejná data, narazil jsem na starý známý problém z nového úhlu: zdrojové registry vypadají uspořádaně, dokud se je nepokusíte číst strojově. Formáty se liší podle typu záznamu, důležité údaje končí v PDF, jedno pole je někdy plné a jindy prázdné bez varování. Rozhodl jsem se z toho udělat něco malého, čitelného a auditovatelného — a šest měsíců to provozovat, abych zjistil, co provoz doopravdy obnáší.

Tahle stránka je proto trvalý zápisník, ne launch. Produktová část žije jinde; sem jsem si chtěl poznamenat rozhodnutí a jejich cenu.

Proč jsem do toho šel

Pracoval jsem dost dlouho v prostředí, kde „chybějící údaj" a „nula" nejsou totéž a kde odhad na místě chybějícího faktu je provozní riziko, ne drobnost. Tenhle instinkt se špatně přenáší do světa, kde model dostane prompt a ochotně dopoví, co mu chybí. Chtěl jsem opačný default: rozhraní, které raději vrátí částečný výsledek s důvodem než hladkou větu o firmě, která možná neexistuje.

České registry jsou přitom bohatý zdroj — jen nebyly stavěné pro programatické čtení s konzistentní latencí, předvídatelnými chybami a stabilními kontrakty. Byly stavěné pro člověka s prohlížečem. Celý projekt je vlastně dlouhá odpověď na otázku: jak z dat určených lidskému oku udělat vrstvu, které může věřit stroj. Podrobně jsem to rozebral v eseji o ekonomice špinavých dat; tady stačí říct, že tohle je motiv, který drží všechno ostatní pohromadě.

Sázka na protokol

První velké rozhodnutí bylo formátové. Mohl jsem postavit obyčejné REST API a mít hotovo — ten svět umím a je předvídatelný. Místo toho jsem vsadil na Model Context Protocol, tehdy poměrně mladý otevřený standard pro připojení nástrojů a datových zdrojů k modelům. Sázka na protokol v jeho raném období má vždy dvě strany. Nevýhoda je zjevná: specifikace se hýbe, knihovny dozrávají za pochodu, dokumentace předbíhá realitu a čas od času vás dohoní změna, kterou jste nečekali.

Výhoda je jemnější, ale pro tenhle typ produktu podstatná. REST endpoint popisuje, jak data získat — cestu, parametry, tvar odpovědi. Protokol jako MCP navíc nese čím ten nástroj je: pojmenované nástroje, jejich schémata a hranice, které model umí přečíst bez toho, abych je vysvětloval v každém promptu. Pro data, kde na struktuře a jejích mezích záleží, je tenhle rozdíl mezi „stáhni JSON" a „tady je nástroj a tohle jsou jeho pravidla" překvapivě velký. A protože kolem MCP vznikal ekosystém klientů, jeden dobře popsaný server najednou fungoval na víc místech, aniž bych psal integraci pro každé zvlášť.

Zpětně to byla správná sázka, ale zaplacená v drobných. Když se pohybujete v raném protokolu, píšete kód proti pohyblivému cíli a část práce je smířit se s tím, že něco přepíšete, protože se svět kolem posunul. Za tu cenu jsem ale dostal hranici mezi agentem a systémem, kterou nemusím vysvětlovat pořád dokola.

Co ukázal provoz

Nejvíc jsem se nenaučil ze stavby, ale z běhu. Devět serverů běží v produkci půl roku a několik věcí mě upřímně překvapilo.

Kdo doopravdy volá

Naivně jsem čekal, že na druhém konci sedí většinou lidé nebo jejich agenti. Realita byla pestřejší. Velkou část provozu tvoří katalogové crawlery, které indexují dostupné MCP servery, a monitory, které si periodicky ověřují, že služba žije. Pak jsou tu agenti, kteří skutečně něco počítají — a teprve za nimi příležitostný člověk. Nejdůležitější lekce z toho je banální a přesto snadno přehlédnutelná: request není totéž jako použití. Server může mít tisíce příchozích spojení denně a jen hrstka z nich znamená reálný dotaz. Když jsem se poprvé díval na hrubé počty požadavků, málem jsem si přečetl úplně jiný příběh, než jaký se skutečně děl. Užitečné metriky začaly až ve chvíli, kdy jsem oddělil handshake a healthcheck od skutečných volání nástrojů.

Rate-limity jsou protokolová otázka, ne jen ochrana

Omezování frekvence jsem zpočátku bral jako obranu proti přetížení. Provoz mě přesvědčil, že je to spíš součást kontraktu. Agent se totiž chová jinak než člověk: při jedné úloze umí složit desítky dotazů během vteřin, protože ho to nic nestojí. Limit tedy není zeď proti útočníkovi, ale způsob, jak modelu srozumitelně sdělit, že za daty je konečný zdroj. Klíčové bylo, aby odmítnutí bylo čitelné — aby z odpovědi šlo poznat, že jde o dočasný strop, ne o chybu dat. Model, který dostane jasný signál „teď ne, zkus později", se zachová rozumně. Model, který dostane prázdno, si domyslí.

Open-core jako architektonická hranice

Nejdřív jsem předpokládal, že otevřené servery budou stačit — a technicky stačí. Časem jsem ale narazil na hranici, která nevede mezi „zadarmo" a „za peníze", ale mezi dvěma druhy hodnoty. Kód, který si člověk může přečíst, spustit a upravit, je jedna věc. Provozní odpovědnost — že podkladové datasety jsou aktuální, že se parser nerozbil na nové kombinaci dokumentů a že někdo řeší incident, když se veřejný zdroj zachová jinak — je věc druhá. Tu hranici jsem chtěl mít v architektuře, ne jen v ceníku. Otevřená část proto žije jako samostatné balíčky bez skrytých runtime závislostí; nadstavba je oddělená schválně, aby self-hosted varianta nikdy nezávisela na něčem, co není vidět. To rozhodnutí bylo primárně technické; obchodní důsledky z něj vyplynuly, ne naopak.

Co jsem si odnesl

Po půl roce se hlavní lekce dá shrnout do jedné věty: protokol je snadná část, data jsou ta těžká. MCP mi dalo čistou hranici mezi modelem a systémem, ale drtivá většina práce dál sedí v pochopení zdrojů — jejich rate-limitů, výpadkového chování, významu polí a míst, kde se sluší říct „nevím". Druhá lekce je o měření: bez oddělení šumu od signálu vám telemetrie poví příběh, který se nestal. A třetí je o pokoře k mladým standardům — sázka na protokol v raném období se vyplatí, když jste ochotní platit průběžně v malých přepisech místo jednorázově velkým selháním.

Je tu i lekce, kterou jsem nečekal: zachovat si k projektu osobní vztah se vyplácí. Půl roku provozu není příběh o velké architektuře, ale o desítkách drobných rozhodnutí, kde jsem musel volit mezi „elegantní" a „nudné, ale čitelné" — a skoro pokaždé vyhrálo nudné. Server, který vrací malé, jednoznačné objekty s verzí zdroje a explicitním stavem, se ladí i po měsících snadno. Server, který je chytrý, si po čase přečte i sám autor jako hádanku. Tahle stránka je záměrně napsaná z pozice člověka, který to provozuje, ne prodává — protože právě ten pohled se v produktových popisech obvykle ztratí jako první.

Co dál: držet servery nudné a předvídatelné, zlepšovat čitelnost odmítnutí a částečných výsledků a pomalu rozšiřovat pokrytí tam, kde to dává smysl datově, ne marketingově. Kód je otevřený na GitHubu a rád si nechám ukázat, kde se mýlím.

Hlubší ponory

Tahle stránka je rozcestník. Každé z rozhodnutí výše má vlastní esej, kde jdu do hloubky: