Mintlify, platforma pro vývojářskou dokumentaci, zveřejnil 30. října 2026 popis architektury, na které stojí jeho agent pro průběžnou aktualizaci dokumentace. Agent sleduje kód a nástroje týmu, a když se něco změní, navrhne úpravu dokumentace jako pull request. Text se hlavně věnuje tomu, jak si agent pamatuje kontext. Místo volných poznámek v markdownu ukládá Mintlify většinu paměti do JSON souborů s pevným schématem, takže je předem dané, co si má agent zapsat třeba o týmu nebo o chystaném vydání. Podle firmy po přestavbě systému vzrostl interně měřený podíl přijatých pull requestů s dokumentací ze 70 na 90 %.
Autorem je Patrick Foster, softwarový inženýr Mintlify. Firmu založili v roce 2021 Han Wang a Hahnbee Lee. Podle TechCrunch z května 2022 začínala nástrojem, který z kódu generoval dokumentaci. Foster připomíná, že firma chtěla hned na začátku dělat dokumentaci, která se aktualizuje sama, a platformou pro psaní dokumentace se stala až potom. Popsaná architektura pohání agenta Autopilot, kterého Mintlify spustil 20. října 2026 jako betaverzi pro tarify Pro a Enterprise. Autopilot čte repozitáře a podle tarifu i Slack, Jiru, Linear, Notion nebo Zendesk. Změny ale sám nezveřejní. Otevře pull request, o kontrolu požádá člověka, kterému změněný kód patří, a dokud někdo z týmu změnu nesloučí, na web nic nejde. Každý otevřený nebo aktualizovaný pull request stojí 250 kreditů. Běh, který nic nenajde, je zdarma.
Systém tvoří dva typy agentů, které sdílejí jednu paměť a pracují v sandboxu s přístupem k repozitářům a napojeným službám. Runner agent plní konkrétní úkoly. Mintlify ukládá sadu spouštěčů, například naplánovaný cron nebo projekt, který někdo v Jiře označil jako hotový, a ke každému patří skill s instrukcemi. Když se spouštěč ozve, runner agent skill vykoná a výsledkem bývá pull request s dokumentací a upozornění pro lidi, kteří ho mají zkontrolovat. Nad ním stojí background agent, který běží jednou denně pro každý web. Jeho úkolem je dostat do dokumentace co nejvíc sloučených pull requestů a přitom udržet podíl přijatých nad 80 %. Spouštěče a skilly runner agenta může zakládat i mazat a stejně volně zachází se sdílenou pamětí. Rozhoduje se podle záznamů minulých běhů, dat z napojených nástrojů, analytiky dokumentace a toho, které pull requesty lidé přijímají. Foster popisuje případ, kdy spouštěč reagující na sloučení kódu opakovaně navrhoval úpravy dokumentace k CLI a lidé je zavírali, protože CLI vychází v průběžných vydáních. Background agent si toho všiml, CLI z tohoto skillu vyřadil a založil měsíční cron, který píše poznámky k vydání CLI.
Harness, tedy smyčku, která opakovaně volá jazykový model a obsluhuje jeho nástroje, si Mintlify napsal sám. Předtím zkoušel open-source agenty OpenCode a Pi, podle Fostera ale schovávaly příliš mnoho technických rozhodnutí a nehodily se k datovým modelům firmy. Vlastní harness stojí na knihovně AI SDK od Vercelu a má nástroje pro subagenty, zhušťování kontextu (compaction), navazování na jiné běhy, větvení relace, práci se skilly a shellové příkazy spouštěné v sandboxu. Na offline sadě testů zaměřené na dokumentaci dopadl podobně jako Pi, který ale spotřeboval o 50 % víc tokenů. Jde o vlastní měření Mintlify.
Samotnou infrastrukturu Foster bere jako samozřejmost. Skutečná práce je podle něj v návrhu paměti, vlastních nástrojů a přednastavených skillů. Agent, který reaguje na sloučení kódu, potřebuje vědět, který tým změnu vlastní, kde o ní mluví ve Slacku nebo v Notionu, kdo ji má zkontrolovat a jestli se dokumentace k ní vydává průběžně. Paměť je proto obyčejný git repozitář. Většinu v něm tvoří JSON soubory s pevným schématem. Vlastní soubor dostávají nastavení celého webu, stylová příručka, každý uživatel i každé větší chystané vydání. Integrace jsou rozdělené podle typu: správa úkolů (Linear, Jira), znalostní báze (Notion, Confluence, Drive), zákaznická podpora (Zendesk, Intercom), Slack a repozitáře kódu. Záznam o vydání obsahuje mimo jiné související pull requesty, lidi, kteří vydání řídí nebo kontrolují, odkazy na specifikace, datum, před kterým agent nemá začít psát, a kanály a vlákna, kde se o vydání diskutuje. Volné markdown soubory zůstaly jen tam, kde firma neumí určit, co přesně má agent ukládat.
Důvod Foster vysvětluje tím, že jazykové modely špatně odhadují, co si mají pro další běhy uložit. Volné poznámky podle něj zůstávají nevyužité, nebo se naopak nafouknou, časem z nich může zmizet důležitá informace a nemusí v nich být podstatné části práce týmu. S pevným schématem má agent úzce vymezený úkol, například najít všechny pull requesty s kódem, které patří k jednomu vydání. Takový úkol jde i měřit. U paměti o uživatelích může Mintlify ručně označit, jaké údaje o lidech v organizaci očekává, spočítat, kolik procent polí agent vyplní správně, a podle výsledku ho postupně ladit. Vývojářům firmy navíc pevná struktura ukazuje, s jakými informacemi agent při práci počítá.
Potíž nastala s aktualizacemi samotného agenta. Skilly, nástroje a paměťové soubory u každého zákazníka na sobě závisejí a podle Fostera může nastavení rozbít i drobná změna textu v přednastaveném skillu. Mintlify proto každému background agentovi pošle prostým textem popis nekompatibilních změn. Agent podle tohoto popisu zkontroluje své nastavení, dál hlídá, jestli se něco nezhoršilo, a převede paměť na nové schéma. Takhle firma zavedla i podporu větších vydání kódu: agenti smazali zastaralá pole a začali v kódu vyhledávat a indexovat větší funkce. Záznamy běhů leží jako JSON ve stejném repozitáři. Když agent relaci rozvětví, nová relace jen ukazuje na poslední zprávu té původní, takže relace tvoří strom zrcadlený ve vnořených složkách. Celou historii kterékoli větve pak jde složit průchodem od listu ke kořeni.
Zdroje:
- Patrick Foster, Mintlify: The Harness and Memory Architecture Behind Self-Updating Docs, 30. října 2026
- David Isquick, Mintlify: Autopilot: Always-on agent for self-updating docs, 20. října 2026
- Mintlify dokumentace: Keep documentation up-to-date with Autopilot
- TechCrunch: Mintlify taps AI to automatically generate documentation from code, 30. května 2022
- Vercel AI SDK na GitHubu
- OpenCode na GitHubu
- Pi na GitHubu
