Mintlify erklärt Agenten- und Speicherdesign hinter selbstaktualisierender Dokumentation

Ein Hintergrundagent steuert die Runner-Agenten

Laut Mintlify besteht das System aus einem Hintergrundagenten und einem Runner-Agenten. Beide laufen als Agent-Loop mit Zugriff auf eine Sandbox, mit der Möglichkeit, Repos zu klonen, mit Lesezugriff auf Integrationen von Drittanbietern und mit einem gemeinsamen Speicher.

Die Arbeit wird durch Trigger ausgelöst. Das können Cron-Zeitpläne sein, Merges in einem Repo oder Ereignisse in Drittanbieter-Tools, etwa wenn ein Projekt in Jira als erledigt markiert wird. Jeder Trigger ist mit einem Skill verknüpft. Wird einer ausgelöst, landet ein Job in der Warteschlange eines Runner-Agenten. Dessen Ergebnis ist meist ein Dokumentations-PR, gefolgt von einer Benachrichtigung, die die richtigen Personen um ein Review bittet.

Der Hintergrundagent läuft täglich für jede Site. Sein System-Prompt weist ihn an, die Verantwortung für den Erfolg der Dokumentation zu übernehmen. Seine Optimierungsfunktion lautet, die Zahl der gemergten Docs-PRs zu maximieren und dabei die Annahmequote über 80 % zu halten. Er kann die Trigger des Runners, deren Skills und den gemeinsamen Speicher anlegen, lesen, aktualisieren und löschen. Dafür nutzt er frühere Run-Logs, angebundene Integrationen, Docs-Analytics und Daten zur PR-Annahme.

Mintlify nennt ein Beispiel: Ein Trigger, der auf PR-Merges in einem Code-Repo reagierte, erzeugte immer wieder CLI-Docs-PRs, die geschlossen wurden, weil die CLI in einem rollierenden Release-Zyklus erscheint. Der Hintergrundagent entfernte CLI-Änderungen aus diesem Skill und legte stattdessen einen monatlichen Cron-Trigger an, der CLI-Release-Notes schreibt.

Eigenes Harness und Speicher mit festem Schema

Mintlify hat ein eigenes Harness entwickelt. Das Unternehmen gibt an, OpenCode und Pi ausprobiert zu haben, beide hätten jedoch zu viele Engineering-Entscheidungen wegabstrahiert, um in der eigenen Umgebung gut zu funktionieren und zu den eigenen Datenmodellen zu passen. Das Harness nutzt das AI SDK von Vercel, um LLM-Aufrufe zu loopen und Tools bereitzustellen. Hinzu kommen eigene Tools für Subagenten, Compaction, das Anknüpfen an andere Runs, das Forken der aktuellen Session, die Nutzung von Skills und das Ausführen von Shell-Befehlen, die an eine Sandbox weitergeleitet werden. In einer Offline-Eval-Suite für Docs schnitt das Harness laut Mintlify ähnlich ab wie Pi, doch Pi verbrauchte 50 % mehr Tokens.

Die Infrastruktur sei Grundvoraussetzung, so das Unternehmen, der schwierigere Teil sei das Speicherdesign. Der Agent muss wissen, welches Team für eine Änderung zuständig ist, wo darüber gesprochen wird, ob die Docs mit einem rollierenden Release mitwachsen sollen und wer das Review wie übernehmen soll. Mintlify legt das in JSON-Speicherdateien mit festem Schema ab. Ein vereinfachter Release-Typ umfasst Code-PRs, Stakeholder, Planungsdokumente, die Angabe, ob direkt committet oder weitere PRs geöffnet werden, ein Datum, vor dem das Entwerfen nicht beginnen soll, sowie Kommunikationsdetails wie Kanäle und Threads.

Dieselbe Granularität gilt für Nutzer, Styleguides, Site-weite Einstellungen und jede einzelne Integration, mit Dateien für Issue-Management, Wissensmanagement, Support-Plattformen, Kommunikation und Code-Repos. Für schwer zu zerlegende Bereiche bleiben einige frei formulierte Markdown-Dateien bestehen.

Mintlify argumentiert, dass die Entscheidung, was gemerkt werden soll, für LLMs schwierig ist und dass frei formulierte Dateien möglicherweise zu wenig genutzt werden, ausufern oder wichtige Informationen verlieren. Ein strukturiertes Schema macht die Pflege des Speichers zu einer klar abgegrenzten Aufgabe und ermöglicht Offline-Evals, etwa indem Nutzer in einer Organisation gelabelt werden und gemessen wird, welcher Anteil der Felder vom Agenten korrekt befüllt wird.

Over-the-air-Updates und Run-Logs

Weil das Setup jedes Agenten ein Geflecht aus Skills, Tools und Speicherdateien ist, könnte schon eine kleine Änderung an einem voreingestellten Skill das Setup eines Kunden beschädigen. Mintlify begegnet dem, indem jeder Hintergrundagent eine Klartextbeschreibung der Breaking Changes erhält. Der Agent prüft sein Setup auf Regressionen, überwacht es künftig und passt seine Speicherdateien an neue Schemata an.

Auf diesem Weg habe das Unternehmen die Unterstützung für größere Code-Releases ausgerollt. Agenten mit angebundenen Repos löschten veraltete Felder, durchsuchten Codebasen, um größere Features zu indexieren, speicherten Memory-Artefakte und starteten Runner-Agenten, um diese umzusetzen. Mintlify regt zudem an, über denselben Kanal neue Produkte einzuführen, etwa automatisierte Produkt-Screenshots. Dazu würde jedem Hintergrundagenten ein Dokument zugeschickt, anhand dessen er beurteilen könnte, ob ein Kunde das Feature wahrscheinlich aktivieren würde und wen er informieren sollte.

Run-Logs werden als JSON im Speicher-Repo abgelegt. Jede Session ist ein Array aus Nachrichten und Ausgaben. Beim Forken entsteht eine neue Session, die auf die letzte Nachricht der aktuellen verweist. So bilden die Sessions einen Baum, der als verschachtelte Ordner abgebildet wird. Der vollständige Verlauf einer Blatt-Session lässt sich rekonstruieren, indem man bis zur Wurzel aufsteigt.

Was das bedeutet

Laut Mintlify treibt diese Architektur nun Autopilot an, das gerade gestartet wurde. Für Teams, die Dokumentation pflegen, zeigt der Bericht ein Design, in dem Agenten ihre eigenen Trigger und Skills anhand von Merge-Ergebnissen optimieren, während strukturierter Speicher sie über Zuständige, Reviewer und Release-Zeitpunkte auf dem Laufenden hält. Die Annahmequote von 70 auf 90 % ist eine interne Zahl, die das Unternehmen selbst angibt.