Kategorie: Einblicke

Im September 2026 führte Anthropic an einem einzigen Tag mehr als 30.000 Code-Änderungen zusammen. Im Mai lag der Wert bei rund 2.500, im Januar deutlich darunter. Diese Zahl ist kein Erfolgsausweis, sondern eine Laständerung: Sie zeigt, wie stark die Infrastruktur unter dem Tempo steht.

Kein Wachstum, sondern ein Faktor zwölf in vier Monaten. Deshalb ist bei Anthropic längst nicht mehr das Schreiben von Code der Engpass, sondern die Infrastruktur darum herum: Versionskontrolle, Builds, CI. Claude schreibt Code in einem Tempo, für das diese Werkzeuge nie gebaut wurden. Das Unternehmen entwickelte ein eigenes Versionskontrollsystem, Scion, und migrierte innerhalb von fünf Monaten das komplette Monorepo von Git dorthin. Parallel entstanden eine Code-Review-Oberfläche namens Antique, eine Code-Suche, ein Rechte- und Rollensystem für die Quellcodeverwaltung und neue Verfahren, um große Mengen geprüften Code zu landen.

An dem Fall fällt eine Rückkopplung auf: Claudes Fähigkeit, Code zu schreiben, hat das Problem erzeugt — und war gleichzeitig das Werkzeug, mit dem die Lösung entstand. Ein Team von sieben Leuten baute Scion samt Code-Review-Werkzeug und einem halben Dutzend weiterer Systeme in fünf Monaten – während die täglich gemergte Codemenge um das Zehnfache wuchs. Eine frühe interne Claude-Version schrieb die Git-nach-Scion-Importpipeline neu und brauchte danach 20-mal weniger Speicher bei vierfacher Geschwindigkeit. Bevor wir uns ansehen, wie Scion arbeitet, ein Blick darauf, wo Git an seine Grenzen stößt. Denn das Problem ist nicht, dass Git schlecht wäre. Das Problem ist, dass Git für einen anderen Anwendungsfall entworfen wurde.

Man kann sich das wie eine Bibliothek vorstellen. Git gibt jedem Leser eine vollständige, in sich geschlossene Kopie des gesamten Bestands mit nach Hause; er kann darin blättern, zitieren, suchen und Querverweise auflösen, ganz ohne die Zentrale. Für fast jedes Repository ist das richtig und ein Grund, warum Git Standard wurde. Scion geht den umgekehrten Weg und baut den Auskunftsschalter: Wer eine Frage hat, ruft an, und der Schalter antwortet. Man bekommt nicht den ganzen Bestand, sondern die Seiten, die man gerade liest.

Warum Git im Monorepo an eine Wand fährt

Die Zahlen bei Anthropic sind extrem. Die History des Hauptzweigs allein umfasst fast 100 GB, eine komprimierte Arbeitskopie liegt bei über 25 GB. Für CI fallen rund 25 Millionen Code-Checkouts pro Tag an, noch ohne Entwicklerumgebungen, Agenten-Sandboxes und Research-Jobs. Würde man das naiv fetchen, käme man auf mehr als 600 Petabyte Git-Verkehr pro Tag.

Git bietet Werkzeuge für Teilmengen: Shallow Clones, Sparse Checkouts, Promisor Remotes. Anthropic hat all das genutzt und zusätzlich das übliche Arsenal großer Monorepos aufgefahren — interne Spiegel und Repository-Snapshots, sogenannte Seeds, im Blob-Speicher. Auf dem Höhepunkt liefen mehrere hundert interne Git-Spiegel. Das kaufte Zeit, wurde mit steigender Merge-Rate aber immer schwerer zu betreiben: Die Seeds fielen zwischen zwei Aktualisierungen weiter vom Tip des Hauptzweigs zurück, und Operationen, die von History abhängen, etwa Diff und Blame, brauchten auf Teilklonen immer mehr Sorgfalt.

Im Kern war das ein Kategorienfehler. Fast alle Beteiligten nutzten Git als zentrales System mit einer maßgeblichen Kopie, aber fast alle Clients waren Agenten und Jobs, die per Definition online sind. Genau die Eigenschaften, die Git für verteiltes, Offline-Arbeiten hervorragend machen, behinderten also das Wachstum. Die naheliegende Frage lautete deshalb: Wie würde Versionskontrolle aussehen, wenn man von Anfang an davon ausgeht, dass Agenten immer online sind?

Fünf Prinzipien, auf denen Scion aufbaut

Anthropic war mit diesem Problem nicht allein, und das half. Große Monorepos mit eigener Quellcodeverwaltung haben Vorläufer, etwa Googles Piper und Metas Sapling. Aus deren Erfahrungen und aus der eigenen Notlage entstanden fünf Prinzipien, die Scion von Git unterscheiden.

Erstens: Clients sind immer online. Git nimmt an, dass ein Client offline arbeiten kann, und gibt ihm deshalb ein vollständiges Repository. Scion dreht das um und geht von einem Server aus, der immer erreichbar ist; Clients holen Daten dann, wenn sie sie brauchen. Zweitens: Es gibt eine Asymmetrie zwischen Client und Server. In Git kann jeder Client selbst ein vollwertiger Server sein. In Scion beantwortet der Server Fragen zur Dateihistorie und zum Blame, erstellt Commits, führt Merges und Rebase-Operationen aus. Der Client hält nur einen begrenzten lokalen Objekt-Cache, legt die Dateien der Arbeitskopie auf die Platte, beobachtet Änderungen im Dateisystem und bietet eine bequeme Oberfläche für die Arbeit mit dem Server.

Drittens: Alles muss horizontal skalierbar sein. Die vielen Git-Spiegel waren irgendwann ein Kapazitätsproblem, weil sie an die Grenzen von Platte und Speicher stießen. In Scion sind die Daten des Repositories verteilt, jede Komponente lässt sich unabhängig skalieren, und es existiert nirgends eine vollständig materialisierte Kopie — auch nicht auf dem Server. Weil es keine Packfiles gibt, also keine komprimierten Objektbündel wie in Git, entfällt auch die Repository-Wartung.

Viertens: Commits müssen billig, inkrementell und sperrfrei sein. In Git committet man lokal und pusht dann. In Scion passiert jeder Commit, jedes Rebase und jeder Merge auf dem Server, es gibt also nichts zu pushen — aber jede dieser Operationen muss schnell sein. Die Kosten dürfen mit der Größe der Änderung skalieren, nicht mit der Größe des Repos, sonst bricht der Server ein. Fünftens: Die Arbeitskopie ist optional und von vornherein sparse. Wer nur den Diff zwischen einem Commit und seiner Merge-Basis braucht, fragt den Server; viele Schreibvorgänge laufen ebenfalls komplett über die API, ohne Checkout.

Changesets statt Commits: die Datenstruktur dahinter

Die Arbeitseinheit in Scion heißt Changeset und ist ein Eintrag in einem Write-Ahead-Log. Ein Changeset speichert vieles, was man von einem Git-Commit kennt, aber mit einem entscheidenden Unterschied: Wo ein Git-Commit auf einen Tree zeigt, hält ein Changeset eine Liste der Dateien, die sich relativ zum ersten Parent geändert haben, plus content-addressed Verweise auf die komprimierten Dateiinhalte im Blob-Speicher. Changesets entstehen serverseitig und sind sofort überall verfügbar.

Diese Form erlaubt sehr hohen Durchsatz, weil keine Packfiles angenommen werden müssen, keine Sperren und keine Absprachen zwischen Servern nötig sind und keine Refs bewegt werden. Refs unterstützt Scion zwar, aber weder das Erstellen noch das Holen von Commits braucht sie; das Verschieben eines Refs ist ein Compare-and-Swap auf einer einzelnen Spanner-Zeile, getrennt vom Anlegen von Changesets. Globaler Zustand, über den sich alle einig sein müssen, wird so weit wie möglich vermieden.

Ein Changeset allein kann allerdings nicht schnell beantworten, wer eine Zeile zuletzt geändert hat oder welche Commits eine Datei betrafen. Dafür baut Scion zusätzliche Datenstrukturen auf: eigene Strukturen für Datei-Blame und Pfadhistorie, Skip-Listen für den Commit-Graphen. Alles, was nicht direkt Teil des Changesets ist, heißt im Projekt abgeleitete Daten und wird über einen einzigen generischen Mechanismus berechnet. Jede Art abgeleiteter Daten ist rekursiv definiert, ihr Wert für ein Changeset ergibt sich also aus ihren Werten für dessen Parents.

Dieser Mechanismus hat drei Vorteile. Man kann neue Arten abgeleiteter Daten ergänzen, wenn eine zusätzliche Struktur eine Operation schneller macht. Man kann pro Typ entscheiden, ob die Berechnung sofort oder aufgeschoben erfolgt, und materialisiert damit nichts, was niemand braucht. Und weil der Client die Interna dieser Strukturen nie sieht, lassen sie sich optimieren, ohne den Client anzufassen. Das ist mehrfach passiert, etwa mit neuen Indizes für Copy-Erkennung oder für die pfadbasierte Dateisuche.

Der Auskunftsschalter: wie Scion skaliert

Eine kleine Flotte von Scion-Servern stellt die APIs bereit, die ein Client braucht: Changesets holen, Diffs berechnen, Merge-Basen finden, Blobs abrufen. Alle Daten sind content-addressed, ein einmal gespeichertes Stück ändert sich also nie, und jeder Server kann es cachen, ohne sich mit den anderen abzustimmen. Damit sind die Server horizontal skalierbar und brauchen kaum Koordination. Im Kern sind sie große Caches, die abgeleitete Daten im Vorbeigehen berechnen und das Ergebnis nach Spanner zurückschreiben. Jede Cache-Stufe hält laut Anthropic eine Trefferquote von über 99 Prozent; die Scion-Infrastruktur braucht rund 200-mal weniger CPU und Speicher als die frühere Git-Spiegelung. Checkouts laufen zwei Größenordnungen schneller – Sekunden statt Minuten –, allein in der CI wurden so 25 Prozent Rechenkapazität frei.

Für die Konsumenten hat das eine spürbare Folge: Sie müssen keine lokalen Repositories mehr pflegen. Das war vorher ein erheblicher Wartungsaufwand für CI-Jobs und Werkzeuge, die Fragen zu Commit-Abstammung oder Blame beantworten wollten. In der frühen Migrationsphase, bevor eigener Client, eigenes Repo-Format und eigene Protokolle existierten, beantwortete Scion ausschließlich solche Metadaten-Abfragen. Das Holen von Dateiinhalten und das Materialisieren von Arbeitskopien ist deutlich datenintensiver und brauchte ein eigenes Design.

Der Client heißt scn und weicht in wichtigen Punkten von Gits Fetch-Protokoll ab. Die Verhandlung teilt dem Server nicht mit, was der Client schon hat; sie arbeitet ausschließlich mit Trees und Blobs, die der Client haben will. Ausgehend von einem Wurzel-Tree prüft der Client seinen lokalen Speicher auf fehlende Trees, fordert sie rekursiv an und wiederholt das Ganze für Blobs. Jede Anfrage betrifft ein bestimmtes, unveränderliches Objekt, also kann jeder Cache sie beantworten — die Architektur ähnelt stark klassischen mehrstufigen Caches. Weil es keine einzelne, mehrere Gigabyte große Packfile-Antwort gibt, ist der Vorgang zudem effizient und wiederaufnehmbar. Sparse und virtualisierte Checkouts brauchen keine Sonderbehandlung, denn der Client fragt keine Trees an, die er nicht will. Auf dem Knoten spricht der Client über einen Socket mit einem Daemon, der Objekte für den ganzen Rechner vorhält.

Was das für Teams bedeutet, die noch mit Git arbeiten

Anthropic ist mit diesem Workload die Ausnahme, und das Unternehmen sagt selbst, dass die meisten Organisationen diese Probleme nicht sofort haben werden. Aber die Druckpunkte sind nicht exotisch. Wer KI-Werkzeuge ernsthaft einsetzt, bekommt zuerst mehr Code, dann mehr Merges, dann mehr CI-Läufe — und irgendwann wird die Versionskontrolle zum Taktgeber. Wichtiger als das fertige System ist die Denkweise dahinter: Annahmen prüfen, die man nie bewusst getroffen hat.

Die wichtigste dieser Annahmen lautet, dass ein Client offline sein können muss und deshalb eine vollständige Kopie braucht. Sobald die Clients überwiegend Agenten und Jobs sind, stimmt das nicht mehr — und es kostet Speicher, Bandbreite und Wartung. Die zweite Annahme lautet, dass jeder Beteiligte ein Repository haben muss, um Fragen zu stellen. Wenn der Server dieselben Auskünfte über eine API gibt, verschwindet ein großer Teil der Infrastruktur, die nur dazu da war, lokale Kopien zu pflegen. Anthropics automatisierte Bisect- und Revert-Pipelines wären in dieser Größe ohne diesen programmatischen Zugriff kaum praktikabel.

Der dritte Gedanke ist kleiner: Nicht alles muss gespeichert werden, manches lässt sich ableiten. Scion speichert vor allem Changesets und die Dateiinhalte im Blob-Speicher; Blame, Pfadhistorie und Graph-Abkürzungen leitet es daraus ab, wahlweise sofort oder später. Das reduziert den dauerhaft gespeicherten Zustand und macht Änderungen an den Datenstrukturen billig. Für kleinere Teams heißt das nicht, Git zu ersetzen. Es heißt, die Signale zu kennen, an denen der Druck sichtbar wird: eine wachsende Zahl interner Spiegel, steigende Checkout-Mengen, Klon-Zeiten, die die Mittagspause überdauern, und Review-Warteschlangen, die länger werden, obwohl schneller committet wird.

Die Verschiebung ist unbequem. Wenn Code zu schreiben nicht mehr der Engpass ist, wandert der Engpass dorthin, wo Menschen oder ihre Werkzeuge entscheiden müssen: prüfen, mergen, integrieren. Anthropic hat dafür nicht nur Scion gebaut, sondern in denselben fünf Monaten auch eine Code-Review-Oberfläche, Code-Suche, ein Rechtesystem und neue Verfahren, um große Mengen geprüften Code zu landen. Versionskontrolle war nur der erste Teil der Kette, der gerissen ist. Scion selbst will Anthropic nicht als Git-Ersatz anbieten – zu speziell, zu teuer im Tokenverbrauch. Stattdessen will das Unternehmen seine Erkenntnisse mit GitHub, GitLab und der Open-Source-Gemeinschaft teilen, weil es diese Klasse von Problemen in den nächsten sechs bis zwölf Monaten auf mehr Teams zukommen sieht. Wer heute mit agentischem Coding beginnt, sollte sich deshalb nicht fragen, wie das eigene Git ersetzt wird. Sondern welche Annahme in der eigenen Entwicklerinfrastruktur gerade falsch wird.

Quelle: anthropic.com

Ein Analyse-Agent bekommt eine strategische Frage und braucht 33 Werkzeugaufrufe und 213 Sekunden, um sie zu beantworten. Ein großer Teil davon geht nicht in die Antwort, sondern in die Orientierung: welche Indizes es gibt, welche Felder was bedeuten, wie Tickets und Konten zusammenhängen. Beim nächsten Aufruf beginnt dieselbe Erkundung von vorn, obwohl sich an den Daten nichts geändert hat. Diese Beobachtung beschreibt Anish Mathur von Elastic am 8. Oktober im Blog Search Labs – in eigener Sache, denn die Lösung, die er vorstellt, baut Elastic auf der eigenen Plattform.

Der Beitrag beschreibt, was passiert, wenn man zwischen Rohdaten und Agenten eine Kontextschicht legt, die das Unternehmen und seine Daten vorab versteht. Bei gleicher Frage, gleichem Modell und gleichem Datenbestand sank die Zahl der Tool Calls von 33 auf 9, die Eingabe-Tokens fielen um 71 Prozent, die Laufzeit von 213 auf 64 Sekunden. Geantwortet hat in beiden Läufen Claude Sonnet 5. Zusätzlich fand der Agent eine Beziehung zwischen Konten, die er vorher übersehen hatte. Wer selbst KI-Agenten auf Unternehmensdaten baut, sollte genauer hinsehen, wie dieses Ergebnis zustande kommt und wo seine Grenzen liegen.

Der teure Teil passiert vor der ersten inhaltlichen Aussage

In dem beschriebenen Beispiel bekommt der Agent eine betriebswirtschaftliche Frage: eine Zusammenfassung aller Probleme, die die größten Kunden betreffen. Ohne Unterstützung beginnt ein fähiger Agent damit, Indizes aufzulisten, um zu sehen, welche Daten überhaupt existieren. Danach liest er Mappings, um herauszufinden, welches Feld einen Kunden und welches ein Ticket beschreibt. Anschließend scannt er Verträge, um den Kontowert zu bestimmen und die größten Accounts zu identifizieren. Das ist kein Denkfehler des Modells. Es ist Arbeit, die vor dem Denken stattfindet.

Dabei gehen zwei Dinge schief, die sich mit reiner Modellqualität nicht beheben lassen. Zum einen übersieht der Agent, dass fünf Accounts unter derselben Muttergesellschaft zusammengefasst werden, und untertreibt damit eine der größten Kundenbeziehungen. Zum anderen weiß er nicht, dass das Feld account_id im Ticket-Index gelegentlich leer bleibt, sodass ein Teil seiner Abfrage stillschweigend falsche Zeilen liefert. Solche Feinheiten stehen in keiner Fehlermeldung, nur in den Daten.

Dazu kommt die Wiederholung. Die Erkundung des Schemas ist keine einmalige Investition, sondern ein Aufwand, der bei jeder Anfrage erneut anfällt, auch wenn sich am Datenbestand nichts geändert hat. Man kann sich das wie ein Archiv ohne Findbuch vorstellen: Die Regale sind vollständig und korrekt sortiert, aber jede Anfrage beginnt damit, dass jemand die Gänge abläuft. In Zahlen: Ohne Kontextschicht flossen 2.279.253 Eingabe-Tokens in die Beantwortung einer einzigen Frage, mit Kontextschicht waren es 653.511. Allein 18 Aufrufe brauchte der Agent ohne Hilfe, um Tickets mit Konten abzugleichen, weitere 13, um Verträge einzeln abzurufen.

Was eine Kontextschicht konkret speichert

Ein Context Engine, wie Elastic ihn beschreibt, sitzt zwischen den Rohdaten und den Agenten. Er liest die Quellen vorab und legt, was er versteht, als kleine strukturierte Einheiten ab, die Knowledge Indicators genannt werden. Wenn ein Auftrag eintrifft, bekommt der Agent zuerst die relevanten Einheiten, überspringt die teuren Abfragen und vollständigen Dokumentscans und prüft die Rohdaten nur noch gezielt nach. Im Beispiel las er die Kontobeziehungen einmal und brauchte danach sieben Aufrufe, um die rohen Tickets zu prüfen. Statt zu suchen, was die Daten bedeuten könnten, wird ihm gesagt, was sie bedeuten.

Eine solche Einheit kann ganz unterschiedliche Dinge festhalten: eine Entität und ihre Beziehungen, etwa dass ein bestimmter Konzern eine Tochtergesellschaft ist. Sie kann eine Datenquelle beschreiben, also wofür ein Index gut ist und wie man ihn sinnvoll abfragt. Sie kann eine Eigenheit der Daten notieren, etwa dass ein Feld nicht immer gefüllt ist und man Nullen herausfiltern muss. Und sie kann eine Tatsache, eine Anomalie oder ein Muster festhalten, das sonst einen vollständigen Scan erfordern würde.

Nicht die einzelne Einheit zählt, sondern der Kreislauf, in dem sie entsteht. Der Engine sammelt Inhalte aus den Quellen, baut daraus die Kontextbausteine, liefert sie bei Bedarf an den Agenten aus und verbessert sich anschließend anhand dessen, was tatsächlich passiert ist. Die Kontextschicht ist also kein einmal geschriebenes Handbuch, sondern ein System, das mit seiner Nutzung Schritt hält. Das ist der Unterschied zwischen einem Katalog und einem Gedächtnis.

Warum jede Stufe ein Suchproblem ist

In diesem Modell bleibt jede Stufe des Kontext Engineerings am Ende eine Suchaufgabe. In vielen Diskussionen taucht Suche erst am Ende auf, als Retrieval-Schritt. In der Praxis fängt sie schon beim Sammeln an, wo aus Gigabytes bis Petabytes diejenigen Inhalte gefunden werden müssen, die für die Agenten wirklich zählen. Das verlangt hohe Trefferquote und hohe Genauigkeit gleichzeitig: agentische Suche für die Absicht, lexikalische Suche für die Präzision, semantische Suche für die Vollständigkeit.

Beim Bauen der Kontextbausteine geht es darum, was ein Agent sonst zur Laufzeit herausarbeiten müsste, vorab zu berechnen. Die Frage, was aufbewahrt und was verworfen wird, hängt davon ab, wie die Einheit später gefunden werden soll. Deshalb braucht sie Embeddings, Metadatenfelder und kombinierte Felder, die auf die spätere Suche zugeschnitten sind. Man baut hier nicht für die Lesbarkeit, sondern für die Auffindbarkeit.

Auch die Auslieferung an das Kontextfenster ist ein Relevanzproblem. Was dort landet, muss relevant und vollständig sein, aber gleichzeitig knapp. Ist die Auswahl zu laut, ignoriert der Agent sie und geht zurück zum Erkunden der Rohdaten, womit der ganze Vorteil verpufft. Und die Rückkopplung aus den Traces ist ebenfalls eine Suchaufgabe, weil Transkripte unstrukturiert sind und wiederkehrende Fehler nur über hybride Suche sichtbar werden.

Deshalb fiel die Wahl des Teams auf Elasticsearch als Grundlage. Hybride Suche, die Abfragesprache ES|QL und Vektorsuche werden oft innerhalb derselben Anfrage gebraucht. Damit ist der Kontext-Engine-Ansatz für KI-Agenten weniger ein neues Speichersystem als eine andere Art, vorhandene Suchfähigkeiten zu orchestrieren.

Abgrenzung zu agentic RAG, statischen Katalogen und großen Kontextfenstern

Kontext-Engineering ist keine neue Erfindung, und der Beitrag ordnet es ausdrücklich gegen bestehende Ansätze ein. Statische Kontextdateien oder Kataloge, von Hand gepflegt, veralten und lernen nicht aus der Nutzung. Agentic RAG sucht Rohabschnitte und wiederholt den Vorgang, bis das Ergebnis passt; dabei wird Wissen bei jeder Aufgabe neu zusammengesetzt, und Beziehungen über Dokumentgrenzen hinweg bleiben oft unsichtbar.

Andere Wege haben eigene Kosten. Ein Coding-Agent, der sich per grep durch Dateien hangelt, ist langsam und tokenhungrig und tut sich schwer damit zu erkennen, welcher Treffer der richtige ist. Ein größeres Kontextfenster wirkt auf den ersten Blick elegant, weil man Daten einfach hineinlädt, doch mit wachsendem Kontext nehmen Aufmerksamkeitsprobleme zu und jede weitere Runde wird teurer. Alle vier Wege verschieben das Problem, statt es zu lösen.

Eine Kontextschicht tauscht stattdessen Vorarbeit gegen Laufzeiteffizienz. Diese Vorarbeit lässt sich vorab definieren und mit kleineren, günstigeren Modellen erledigen, was den Aufwand kalkulierbar macht. In dem Beispiel lief die Vorberechnung mit dem kleineren Claude Haiku 4.6 und rund 636.000 Eingabe-Tokens, während die eigentliche Beantwortung einem stärkeren Modell vorbehalten blieb.

Die fünf Bausteine und wie sie zusammenspielen

Konkret besteht der beschriebene Context Engine aus fünf Teilen. Erstens die Quellen: Kontext kann aus jedem Elasticsearch-Index oder Datenstrom stammen, zusätzlich aus externen Anwendungen über Konnektoren und aus Agent-Traces, die über OpenTelemetry eingespeist werden. Zweitens die Automationen, die Elastic Workflows mit spezialisierten Schritten sind: Sie durchsuchen Rohinhalte, verarbeiten Ergebnisse mit einem Sprachmodell, strukturieren die Ausgabe, prüfen die Herkunft, setzen Zugriffskontrollen um und schreiben die Kontextbausteine in den Index.

Drittens der AI Index, der als Kontextspeicher auf der Elasticsearch-Vektordatenbank arbeitet und ES|QL sowie hybride Suche mitbringt. Viertens das Agentengedächtnis: Während Nutzer Aufgaben erledigen, können Agenten Erinnerungen mit Werkzeugen zum Merken, Abrufen und Vergessen speichern; Konsolidierung und unternehmensweite Weitergabe stehen laut Roadmap noch aus. Fünftens die Rückkopplung aus Traces, die zeigt, wo der Agent Tokens verbraucht hat und wo er hängen blieb, und daraus Änderungsvorschläge für die Automationen ableitet.

Im beschriebenen Testfall speiste sich der Engine aus vier Elasticsearch-Indizes mit Kundentickets, Abonnenten, einer internen Wissensdatenbank und Suchprotokollen sowie aus einem Ordner mit rund fünfzig simulierten Verträgen. Die Automationen erzeugten daraus Indexprofile und Konto-Entitäten und landeten bei etwa achtzig Kontextbausteinen. Diese wurden über das Model Context Protocol an zwei Agent-Frameworks angebunden, an den Elastic Agent Builder und an LangChain Deep Agents. Wichtiger als die Zahl der Bausteine ist ihre Herkunft: Aus rohen Vertrags- und Tickettexten wurden Entitäten und Beziehungen extrahiert, bevor überhaupt eine Frage gestellt wurde.

Was die Zahlen wirklich aussagen

Die Zahlen sollte man so lesen, wie sie gemeint sind. Es handelt sich um ein simuliertes Szenario mit einem definierten Datensatz, einem festen Systemprompt und demselben Modell in beiden Durchläufen, ausgeführt über ein LangChain-Harness. Die Differenz zwischen 33 und 9 Tool Calls sowie die 71 Prozent weniger Eingabe-Tokens beschreiben also nicht, was in jedem produktiven System passiert. Sie beschreiben, wie viel der Aufwand für die Datenerkundung in diesem konkreten Aufbau ausgemacht hat.

Der zweite Vorbehalt betrifft die Kostenverschiebung. Eine Kontextschicht verlagert Arbeit nach vorn: Jemand muss Automationen definieren, Quellen anbinden und die Qualität der Bausteine pflegen. Ob sich das rechnet, hängt davon ab, wie oft ähnliche Fragen gestellt werden. Naheliegend ist: Bei einmaligen Ad-hoc-Abfragen dürfte der Gewinn gering sein, in einem Umfeld, in dem dieselben Fragen täglich neu anfallen, zahlt sich die Vorarbeit eher aus. Der Beitrag selbst beschreibt das als Tausch: Kosten für die Vorberechnung gegen Effizienz zur Laufzeit.

Die Lehre liegt deshalb nicht in den neun Tool Calls. Sie liegt in der Frage, die sich Teams stellen sollten, bevor sie den nächsten Agenten bauen: Wissen wir irgendwo festgehalten, was unsere Daten bedeuten und wie sie zusammenhängen? Wenn diese Antwort in den Köpfen weniger Personen und in verstreuten Notizen steckt, wird jeder neue Agent sie neu erfinden müssen, jedes Mal, tokenweise. Eine Kontextschicht macht dieses Wissen zu einem durchsuchbaren Teil der Infrastruktur.

Agent Builder ist inzwischen allgemein verfügbar, Elastic bietet dafür einen Testzugang in Elastic Cloud und eine Dokumentation an. Der Context Engine selbst ist dagegen nicht frei verfügbar; wer ihn ausprobieren will, muss den Zugang bei Elastic anfragen. Die Entscheidung, welche Datenquellen für Agenten wirklich zählen und wie oft dieselben Fragen wiederkehren, nimmt keine Plattform ab. Genau dort entscheidet sich, ob sich die Vorarbeit rechnet.

Quelle: elastic.co

Cognition hat am 5. Oktober Memory und Dreaming für seinen KI-Agenten Devin eingeführt. Die Angaben in diesem Beitrag stammen aus der Ankündigung im hauseigenen Devin-Blog, beschreiben das System also aus Sicht des Herstellers. Memory soll Devin erlauben, nützliche Erkenntnisse über deine Arbeitsweise von Session zu Session mitzunehmen: Vorlieben, Korrekturen und Lektionen zu Projekten und Abläufen. Dreaming ist ein täglicher Hintergrundprozess, der diese Erinnerungen aufräumt, Doppeltes zusammenführt und sie mit den passenden Sessions verknüpft. In Cognitions Beispiel steht etwa die Notiz „Use bun, not npm. The lockfile is bun.lock.“ im Gedächtnis, damit der Agent nach einer solchen Korrektur nicht beim nächsten Mal wieder zu npm greift.

Es geht dabei nicht um ein längeres Kontextfenster, sondern um ein dauerhaftes, persönliches Archiv von Lektionen, die während der Arbeit entstehen. Wer viel mit KI-Agenten arbeitet, kennt das Problem, dass Erkenntnisse aus einem Gespräch mit dem Ende der Session verloren gehen. Memory und Dreaming sollen das nach Cognitions Darstellung ändern. Warum Erinnerung für Agenten so schwierig ist, beschreibt auch unser Beitrag darüber, woran langlebige Agenten scheitern.

Was Devin unter einer Erinnerung versteht

Nach Angaben des Entwicklerteams entstehen die nützlichsten Kontextinformationen oft mitten in der Arbeit. Man korrigiert eine Annahme, erklärt, warum ein Ansatz im aktuellen Projekt nicht funktioniert, oder präzisiert eine Vorliebe. Andere Lektionen fallen direkt aus der Tätigkeit heraus ab: eine Eigenheit der Umgebung, für die mehrere Anläufe nötig waren, oder eine Projektentscheidung, die später wieder relevant wird. Memory gibt Devin die Möglichkeit, solche Dinge festzuhalten, ohne dass die Session angehalten werden muss, um ein Skill zu aktualisieren.

Eine Erinnerung ist keine Zusammenfassung einer Session. Sie ist eine kurze Notiz über eine Lektion, die Devin beim Arbeiten mit dir gelernt hat, versehen mit einem Verweis zurück auf die Session, in der sie entstanden ist. Jede Erinnerung lässt sich damit auf ihren Ursprung zurückführen, und genau das macht das Archiv überprüfbar. Das Gedächtnis bleibt außerdem persönlich: Innerhalb einer Organisation auf devin.ai gehört es der jeweiligen Person und wird nicht zu einer geteilten Anweisung für alle.

Der Memory Drive: ein Git-Repository voller Notizen

Am ehesten lässt sich das wie ein Laborjournal vorstellen, das nie voll wird. Die Notizen liegen im persönlichen Memory Drive, einem dauerhaften Git-Repository aus Markdown-Dateien. Sie lassen sich nach Repository, Projekt oder Thema sortieren, während eine kurze Datei namens MEMORY.md die allgemeinen Präferenzen und ein Verzeichnis über die übrigen Dateien enthält. Wer schon einmal einen Zettelkasten geführt hat, erkennt das Muster: eine Karte, die auf alle anderen zeigt.

Zu Beginn einer Session bekommt Devin diese MEMORY.md als Kontext. Von dort aus kann es relevante Notizen suchen und lesen – mit denselben Werkzeugen, die es zum Navigieren im Code verwendet. Das gesamte Archiv wird nicht in den Prompt geladen. Stattdessen wird es durchsucht wie eine Codebasis, was den Speicher skalierbar hält, ohne das Kontextfenster zu verstopfen. Man bezahlt also nicht mit Tokens für Notizen, die mit der aktuellen Aufgabe nichts zu tun haben.

Zwei Sessions, ein Memory Drive

Bei mehreren gleichzeitigen Sessions wird es komplizierter. Jede Session arbeitet mit ihrem eigenen Git-Checkout des Drives. Nach dem Bearbeiten einer Notiz committet Devin die Änderung, führt Aktualisierungen aus anderen Sessions zusammen und speichert das Ergebnis im dauerhaften Memory Drive. Das ist verteilte Versionsverwaltung, angewendet auf Notizen statt auf Quellcode.

Falls eine andere Session während eines laufenden Syncs ein Update schreibt, weist eine Revisionsprüfung den veralteten Schreibvorgang zurück, sodass Devin den Vorgang gegen die neuere Version erneut versuchen kann. In Konfliktfällen werden widersprüchliche Bearbeitungen sichtbar gemacht und nicht stillschweigend überschrieben. So können parallele Sessions zu einem gemeinsamen Gedächtnis beitragen, ohne dass eine lokale Kopie als alleinige Wahrheit gilt. Wer schon einmal erlebt hat, wie eine Datei von zwei Prozessen überschrieben wurde, weiß, warum diese Vorsicht sinnvoll ist.

Dreaming: der tägliche Durchgang durch die eigenen Notizen

Erinnerungen während einer Aufgabe festzuhalten, ist nur der erste Schritt. Diese Notizen müssen auch wieder besucht werden, und zwar mit dem Blick über alle Sessions hinweg. Genau das ist Dreaming: eine tägliche Hintergrund-Session, in der Devin vergangene Gespräche zusammen mit dem bestehenden Gedächtnis durchsieht, um den Index für künftige Sessions zu verbessern. Der Name passt, denn der Vorgang erinnert an das, was Menschen im Schlaf mit den Eindrücken des Tages machen.

Ein Dreaming-Durchlauf erledigt laut Cognition mehrere Dinge. Überlappende Notizen werden zusammengeführt, flüchtige Details entfernt und Lektionen nachgetragen, die während der ursprünglichen Arbeit nicht festgehalten wurden. Außerdem entfernt Devin veraltete Einträge, die von keiner Session genutzt wurden. Als Beispiel zeigt das Team eine Woche voller kurzer Notizen, von denen einige überlappen und eine bereits überholt ist. Ziel ist ein Index, in dem relevante Kontexte leichter zu finden sind.

Dabei bleiben Quellenverweise und ausdrückliche Präferenzen erhalten, während Notizen und Verzeichnis neu geordnet werden. Man kann sich das wie das Aufräumen eines Schreibtischs vorstellen, bei dem nichts weggeworfen wird, was noch gebraucht werden könnte. Ein Eintrag wie „Dev server was on port 3001 this afternoon.“, der in Cognitions Beispiel nach einer Woche bereits überholt ist, gehört dagegen zu den flüchtigen Details, die Dreaming entfernen soll.

Memory und Skills sind nicht dasselbe

Beide Konzepte wirken auf den ersten Blick ähnlich, sind aber verschieden. Ein Skill beschreibt einen wiederholbaren Ablauf; Memory hält fest, was Devin beim Arbeiten mit dir gelernt hat. Ein Release-Skill könnte die Schritte zum Testen und Veröffentlichen einer Änderung enthalten. Memory würde dagegen deine Vorlieben für bestimmte Technologien festhalten, zusammen mit der Begründung, die du dafür genannt hast.

Die beiden arbeiten zusammen: Der Skill liefert das Verfahren, Memory liefert den Kontext, um es auf deine Situation anzuwenden. Beide können Anweisungen enthalten, unterscheiden sich aber im Lebenszyklus. Skills werden bewusst geschnürt, um wiederverwendet zu werden. Memory dagegen sammelt sich über Sessions an und wird beim Dreaming überarbeitet. Skills sind das Kochbuch, Memory ist die Erinnerung daran, dass in dieser Küche kein Koriander verwendet wird.

Offener Standard und was das konkret bedeutet

Cognition hat den Standard, auf dem das Speichersystem von Devin aufbaut, als Open Source veröffentlicht. Der Standard lässt sich in eigene Agenten integrieren, Beiträge sind unter cognition.ai/agent-memory-repo möglich. Ob andere Anbieter den Standard übernehmen, ist offen. Sollte sich der Ansatz durchsetzen, könnte er nach unserer Einschätzung verändern, wie Agenten-Memory gebaut wird: nicht als angehängte Datenbank, sondern als versioniertes, durchsuchbares und regelmäßig kuratiertes Archiv.

Für den Alltag heißt das: Eine Präferenz, die du einmal erklärt hast, oder eine Lektion, die dich mehrere Versuche gekostet hat, bleibt über eine einzelne Session hinaus nützlich. Laut Cognition musst du dieses Wissen nicht selbst pflegen, weil Dreaming den Aufräumteil übernehmen soll. Anschauen lässt sich das Ganze unter Customize → Memory, wo man nachvollziehen kann, was Devin über die eigene Arbeitsweise gelernt hat, samt der jüngsten Dreaming-Sessions.

Trotzdem bleibt ein Gedächtnis, das aus Zusammenarbeit entsteht, nur so gut wie die Arbeit, aus der es hervorgeht. Wer widersprüchliche Anweisungen gibt oder Entscheidungen häufig umwirft, bekommt ein Archiv, das genau diese Widersprüche widerspiegelt. Der Revisionscheck verhindert Datenverlust, nicht Denkfehler. Und dass jede Erinnerung an die Session gebunden bleibt, in der sie gelernt wurde, macht sie überprüfbar – eine Eigenschaft, die bei KI-Systemen oft fehlt. Wie gut das in der Praxis funktioniert, belegt die Ankündigung weder mit Zahlen noch mit Nutzerberichten; sie beschreibt das Konzept. Wer Devin nutzt, kann es am eigenen Archiv überprüfen.

Quelle: devin.ai

Terminbuchung ist gelöst, denkt man. Ein Abo bei einem bekannten Anbieter kostet wenig und läuft zuverlässig. Wer würde da selbst bauen? Der Fall, den Jason Lemkin von SaaStr beschreibt, kippt diese Annahme: Sein Team baute ein eigenes Terminbuchungstool – und der Grund dafür hatte mit Terminen fast nichts zu tun. Wer nur auf den Kalender schaut, hält die Entscheidung für unnötig. Schaut man auf das, was drumherum hängt, versteht man sie.

Am besten lässt sich das mit einem Empfang vergleichen. Ein klassisches Buchungstool ist der Türsteher mit der Uhr in der Hand: Er notiert, wer wann kommt, mehr nicht. Er weiß nicht, wer da steht, was die Person vorher gelesen hat und zu wem im Haus sie gehört. Diese drei Fragen konnte der bisherige Buchungsschritt nicht beantworten. Genau dort setzt der Eigenbau an. Lemkin schildert, wie ein KI-Agent namens 10K etwas bauen wollte – normalerweise ein Warnsignal – und warum das Team trotzdem zustimmte.

Zwei Gründe, von denen einer allein nicht gereicht hätte

Der erste Grund kam vom Agenten selbst. 10K ist bei SaaStr der „AI VP of Marketing“, also eine Art KI-Marketingchef, und übernimmt zunehmend auch die Rolle des Umsatzverantwortlichen. Er läuft auf Replit, schreibt in Salesforce, fährt Werbekampagnen, kümmert sich um Quote-to-Cash und hängt an rund dreißig weiteren Systemen. Wie SaaStr den Agenten im Inbound eingesetzt hat, beschreibt auch unser Beitrag zum Inbound-KI-Agenten von SaaStr. Als Amelia und 10K den eingehenden Sponsoren-Flow neu aufbauten, schlug der Agent vor, Calendly aufzugeben und ein eigenes Buchungstool zu bauen. Er bot an, das selbst zu übernehmen.

Für sich genommen ist das kein Argument. Ein Agent, der bauen will, ist ein schlechter Grund zu bauen, denn Agenten bauen gern. Folgt man jedem solchen Vorschlag, stehen am Ende ein Dutzend selbstgebauter Werkzeuge herum, die niemand braucht. Lemkin hält genau das für die richtige Grundhaltung und fragte den Agenten nach einer Begründung, statt einfach zuzustimmen.

Der zweite Grund war der eigentliche. Zuvor verschickten David und Amelia unterschiedliche Links: er einen Calendly-Link, sie einen Read-AI-Link. Keiner davon war mit irgendetwas verbunden, was das Team sonst betreibt. Der Terminschritt war damit der einzige Punkt im ganzen Funnel, an dem niemand sehen konnte, was ein Interessent tat. Das ist der blinde Fleck.

Der Buchungsvorgang als Empfang: Was das eigene Tool anders macht

Beim Buchen passieren zwei Dinge gleichzeitig. Erstens entsteht in Echtzeit ein Prospectus: mit dem Firmennamen des Interessenten, den Wettbewerbern, die auf der SaaStr AI Annual waren, und den Paketen, die der Agent für dieses Unternehmen empfiehlt. Das ist eine tokenisierte Seite auf der eigenen Website. Der Link, den der Interessent schon hat, wächst also mit, wenn das Team mehr über ihn erfährt.

Zweitens landet der Termin beim richtigen Menschen. Der Agent verteilt nach den Sponsoren-Accounts, die jede Person schon betreut. Als Base44 anfragte, ging der Termin an Amelia statt an David, weil sie Replit und Lovable verantwortet und dieses Volumen schwerer wog als Davids Betreuung von Vercel. Der Buchungslink trägt außerdem den Firmennamen und führt zurück auf den Prospectus, den die Person gerade gelesen hat.

Bricht jemand ab, ohne zu buchen, meldet 10K das an Amelia und bietet an, die Follow-up-Mail zu entwerfen. Hier zeigt sich der Unterschied zum Türsteher-Bild: Der Empfang kennt die Gästeliste, die Lesezeichen des Besuchers und die Zuständigkeit im Haus. Calendly kann nicht wissen, wer welchen Sponsor-Account verantwortet, was im individuellen Prospectus steht oder welche Abschnitte die Heatmap als gelesen markiert hat. Diese Daten liegen bei 10K und in Salesforce. Ein externes Buchungstool hätte sie erst über Schnittstellen bekommen müssen, und die Entscheidungen darüber wären trotzdem im eigenen System gefallen.

Warum der KI-Agent zum Bauen statt zur Integration riet

Man hätte Calendly behalten und über dessen API anbinden können. 10K hielt es aber für einfacher, den ganzen Booker zu bauen, als einen Teil in Calendly zu lassen und Routing, Prospectus-Auslieferung und das Erkennen von Abbrüchen drumherum zu verdrahten. Lemkin ergänzt: Routing und Prospectus hängen an eigenen Daten, man hätte also in jedem Fall den größten Teil der Logik selbst geschrieben und zusätzlich eine Integration zu Calendly gepflegt.

Der Bau dauerte rund zwanzig Minuten. Vorher war der Kalender der eine Schritt im Funnel, bei dem unsichtbar blieb, was ein Interessent dort tat. Jetzt ist er sichtbar. Das ist der eigentliche Gewinn – nicht die Terminbuchung, die vorher auch funktionierte.

Zwanzig Minuten Bauzeit und vier Prüffragen

Amelias erste Reaktion war Skepsis: „It’s just a calendar“, es sei doch bloß ein Kalender. Lemkin gibt ihr recht, ein reiner Kalender ist es nicht wert, gebaut zu werden. Was den Ausschlag gab, war alles, was daran hängt. Weil die Schätzung bei zwanzig Minuten Agentenzeit lag, war die Hürde niedrig. Hätte der Agent zwei Wochen veranschlagt, wäre Calendly geblieben. Ein nüchternes Kriterium, kein Bekenntnis zur Eigenentwicklung.

Bevor gebaut wird, muss der Agent vier Fragen beantworten. Was kann das, was der Anbieter nicht kann? Deckt eine API-Integration das meiste davon ab? Welche Daten braucht es, die nur wir haben? Und wie lange dauert es, und was passiert, wenn es bricht? Beim Buchungstool war die dritte Frage entscheidend, und die vierte fiel leicht, weil ein Calendly-Link als Rückfallebene existierte. Bei sensiblen Abläufen lässt das Team den Agenten außerdem vorher erklären, was er vorhat.

Die kurze Bauzeit ist also kein Argument für sich. Es senkt nur die Schwelle, unter der ein Experiment sinnvoll wird. Der eigentliche Filter bleibt die Frage nach den eigenen Daten, die kein Anbieter haben kann, und eine funktionierende Rückfallebene, falls die gebaute Lösung ausfällt.

Was SaaStr trotzdem kauft – die Grenze zwischen Kaufen und Bauen

Der Standard bleibt der Kauf. Salesforce, Qualified, Clay, ZoomInfo, Artisan, Monaco, Gamma und Clarity sind alle eingekauft, und Gründer bekommen von SaaStr die Empfehlung, im Zweifel zu kaufen. Gebaut wird nur in schmalen Ausschnitten. Ein Beispiel nennt Lemkin: Zapier verlor stillschweigend rund zwanzig Prozent der Anmeldungen, bevor sie Salesforce erreichten.

Die Reaktion darauf war keine Generalabrechnung mit dem Anbieter. Zapier blieb für die authentifizierten Trigger zuständig, weil die mühsam nachzubauen sind und keine Probleme machten. Nur die Aktionsschritte wanderten in eigenen Code, weil dort die Anmeldungen verloren gingen. Man tauscht nicht das ganze Rohrsystem, sondern das eine Stück, das leckt. Die Terminbuchung selbst darf Mietware bleiben; die Entscheidung, wer einen Interessenten trifft und was er beim Buchen sieht, braucht Daten, die kein Terminanbieter besitzt.

Auch die Urteilskraft des Agenten ist kein Selbstläufer. 10K entscheidet schnell, wählte Clarity für Heatmaps ohne Vergleichsprüfung und verwarf innerhalb von zwölf Stunden einen Anbieter, den ein eigener Unteragent zuvor auf die Liste gesetzt hatte, nachdem er die Preise durchgerechnet hatte. Solche Entscheidungen sind oft gut – und werden trotzdem überprüft.

Vom Werkzeug zum Ideengeber

Auffällig ist, woher der Nutzen des Agenten inzwischen kommt. Vor einem Jahr schlug er Dinge wie ein Empfehlungsprogramm für Tickets vor. Heute sind es überwiegend Produktideen. Den tokenisierten Prospectus für eingehende Anfragen hatte er sich ausgedacht: Er sah sich an, was für Verlängerungen gebaut worden war, und wies darauf hin, dass die meisten Bausteine schon existierten. Der Booker war ebenfalls seine Idee. Aktuell schlägt er eine Version seiner selbst für David und das Vertriebsteam vor, weil David nicht über die Backend-Zugänge verfügt, die Amelia hat.

Was folgt daraus? Kaufen bleibt die Grundregel, aber der Vorschlag eines Agenten ist kein Rauschen. Frag nach dem Warum, halt dagegen, prüfe die vier Fragen. Für die meisten Teams heißt dieser Fall nicht, Calendly zu kündigen. Er heißt, den einen Schritt im eigenen Funnel zu finden, an dem eigene Daten den Ausschlag geben, und dort zu entscheiden, ob ein selbst gebautes Werkzeug mehr leistet als ein Kalender mit Uhr. Der Agent ersetzte bei SaaStr nicht reihenweise gekaufte Software. Er stellte die richtige Frage, und die Antwort war zwanzig Minuten Arbeit mit einer Rückfallebene in der Schublade. Lemkins Schlusssatz dazu: Wer vom Agenten zum Bauen gedrängt wird, soll nach dem Warum fragen und dagegenhalten, denn vielleicht hat er eine großartige Idee.

Quelle: saastr.com

Wie bringt ein kleines Modell eine große Aufgabe zu Ende? Alice Moore beschreibt im Firmenblog von Builder.io zwei Experimente, die das Team an seinem eigenen Open-Source-Framework Agent-Native gemacht hat. Der Text ist also ein Erfahrungsbericht des Herstellers über das eigene Produkt. Ein Agent Loop hält einen Coding Agent bei der Arbeit: ein Versuch nach dem anderen, so lange, bis irgendeine Instanz sagt, dass die Aufgabe erledigt ist. Die Schleife ist der einfache Teil.

Die Arbeit steckt in diesem „irgendetwas“. Gemeint ist eine Prüfung, die der Agent selbst ausführen kann und die ihm nach jedem Versuch sagt, ob er näher am Ziel ist. Wer schon einmal einen Ralph Loop oder den Befehl /goal ausprobiert hat, kennt die eine Hälfte des Prinzips: Der Agent hört einfach nicht auf. Die andere Hälfte nennt Geoffrey Huntley Back Pressure – Tests, Builds, Typprüfungen und alles andere, was einen schlechten Versuch zurückweisen kann. Beide Projekte hatten keine Testsuite. Das Team musste sich den Gegendruck selbst bauen.

Als roter Faden hilft eine einfache Vorstellung: der Agent als Lehrling in einer Werkstatt, der ein Maßband in die Hand bekommt. Die Schleife ist die Wiederholung, das Maßband die Prüfung. Erst wenn der Lehrling selbst messen kann, darf er ohne ständige Aufsicht arbeiten.

Was ein Agent Loop leistet und wo die Arbeit steckt

Ein Agent Loop ist unspektakulär: Der Coding Agent macht eine Änderung, führt die Prüfung aus, liest deren Ausgabe und versucht es erneut. Der Wert liegt nicht in der Schleife, sondern in der Qualität des Signals, das sie abbricht. Ohne dieses Signal dreht sich der Loop entweder ewig, oder er hält nach dem ersten halbwegs plausiblen Ergebnis an.

In der Werkstatt-Analogie ist das Maßband wichtiger als die Arme, die es halten. Ein KI-Agent ohne Testsuite steht vor genau diesem Problem: Er kann beliebig oft arbeiten, aber er erfährt nie, ob seine Arbeit besser geworden ist. Ein großer Teil der Konstruktionsarbeit ist deshalb keine Modellfrage, sondern eine Messfrage.

Moore beschreibt zwei Aufgaben, die sich als Lehrstücke eignen, weil bei keiner von beiden eine fertige Testsammlung existierte. Beide enden mit derselben Erkenntnis: Die Verbesserung zwischen den Runden kam fast immer von einer besseren Prüfung, nicht von einem größeren Modell.

Der Pixel-Diff als Maßband für Figma-Importe

Die erste Aufgabe betraf die Importfunktionen von Agent-Native, dem kostenlosen Open-Source-Framework von Builder.io mit zugehörigen Apps. Nutzer wollten Figma-Dateien in Agent-Native Design und Präsentationen in Agent-Native Slides bringen. Die Ergebnisse waren zunächst schlecht: Diagramme zerfielen in lose Einzelformen, Icons verschwanden, eine Folie kam als schwarzes Rechteck heraus. Eine einzige Folie wich in 88 Prozent ihrer Pixel vom Original ab.

Die erste Schleife war die naheliegende: hinschauen, beschreiben, was falsch ist, den Agenten um eine Korrektur bitten, wieder hinschauen. Das funktioniert, aber nur so schnell, wie ein Mensch Folien anschauen kann. Der Agent wusste außerdem nur, was ihm jemand ins Chatfenster getippt hatte. Das Team war der Prüfer und tippte immer wieder Sätze wie „still wrong, the heading moved again“ in den Chat.

Der entscheidende Schritt war die Einsicht, dass jedes importierte File bereits eine richtige Antwort mitbringt: das Original. Statt visuell zu urteilen, rendert man Original und Konvertierung und vergleicht sie mit einem Pixel-Diff. Ein Pixel-Diff vergleicht zwei Bilder und markiert jedes Pixel, das sich unterscheidet. Werkzeuge wie pixelmatch oder ImageMagicks compare erledigen das ohne großen Aufwand.

Die Prüfung lieferte dem Agenten zwei Dinge: eine Zahl und ein Bild, in dem alle Abweichungen rot markiert waren. Die Zahl sagte ihm, ob eine Änderung geholfen hatte. Die rote Markierung sagte ihm, wo er als Nächstes hinschauen sollte. Über ein Wochenende brachte ein kleineres OpenAI-Modell die Abweichung der Problemfolie von 88 Prozent auf 2 Prozent.

Warum das Prüfwerkzeug selbst geprüft werden muss

Ein Agent, der gegen eine Zahl arbeitet, glaubt dieser Zahl. Das ist praktisch, solange die Zahl stimmt, und gefährlich, sobald sie es nicht tut. Genau hier lag die Fehlerquelle: Nicht geladene Schriften ließen einen Export 17 Prozent abweichen, während der tatsächliche Unterschied bei 0,19 Prozent lag. Insgesamt fand das Team vier solcher Fehler in der Prüfung selbst.

Aus diesen Läufen stammt ein Satz, der die ganze Disziplin zusammenfasst: Eine Treue-Zahl ist eine Behauptung über den Konverter, also muss das Prüfgerüst mindestens so vertrauenswürdig sein wie das, was es bewertet. Ein Maßband, das falsch geeicht ist, macht jeden Lehrling schlechter, nicht besser.

Zweitens musste definiert werden, was nicht zählt. Unterschiede in der Schriftdarstellung waren nicht lohnend, also wurden sie ausdrücklich ignoriert. Drittens brauchte die Prüfung echte Beispiele. Ein paar aufgeräumte Musterdateien hätten dem Agenten ein bequemes Durchrutschen erlaubt, deshalb sammelte das Team eine breite Auswahl an Community-Dateien: .fig-Dateien, die Figma-API, PowerPoint, PDF und Google Slides. Jede Änderung wurde gegen das gesamte Korpus bewertet.

Das zahlte sich aus: Die Notizen verzeichnen zwei Korrekturen, die laut Team „made the frame better and the corpus worse“, also eine einzelne Folie verbesserten und das Gesamtergebnis verschlechterten. Beide wurden zurückgenommen. Mit einer belastbaren Prüfung brauchte die Schleife nur noch ein Modell, das nicht aufgab. Es musste nicht das beste sein.

Verwendet wurde Luna, eines der kleineren Modelle von OpenAI, auf der höchsten Einstellung über einen ChatGPT-Pro-Plan. Die grobe Schätzung des Teams: Ergebnisse nahe am Opus-Niveau für ein Zehntel bis ein Zwanzigstel des Preises, und auf diesem Tarif läuft das Modell tagelang ohne Limit. Abweichungen von 20, 40, teils 50 Prozent sanken auf einstellige Werte, oft auf Bruchteile eines Prozents. Import- und Exportprobleme waren nach Angaben von Builder.io zuvor die häufigste Rückmeldung gewesen, mit Dutzenden Berichten pro Tag. Nach dem Loop seien sie ausgeblieben, und Randfälle, die Nutzer später fanden, ließen sich leicht beheben.

Ein zweiter Loop: statische Seite aus Screenshots nachbauen

Um den Teil vor dem Modell sichtbar zu machen, baute das Team einen zweiten Loop von Grund auf – an einer Aufgabe, die sich nachstellen lässt. Der Auftrag: den Kopfbereich eines Blogposts als statische HTML- und CSS-Seite nachbauen, ausschließlich anhand von Screenshots. Der Agent bekam Screenshots in drei Breiten, die Schriften, die Bilder und den Seitentext. Die Prüfung rendert die entstehende Seite in einem Headless-Browser und vergleicht sie mit den Screenshots.

Die Arbeit wurde bewusst geteilt: Ein starkes Modell baut die Prüfung, ein kleines läuft gegen sie. Als starkes Modell diente Claude. Der Prompt, den das Team mit Claude durchging, lautete sinngemäß, ein kleineres Modell solle an dieser Aufgabe arbeiten, bis sie fertig ist. Bevor jemand mit dem Reparieren anfängt, wird die Schleife gebaut, in der es laufen wird. „Fertig“ wird in eine Prüfung übersetzt, die eine Punktzahl oder ein Bestanden/Durchgefallen liefert. Es werden vielfältige, echte Beispiele gesammelt und einige als Holdout zurückgelegt. Die Prüfung muss wiederholbar sein und nachweislich ein bekannt gutes von einem bekannt schlechten Ergebnis unterscheiden. Außerdem werden die Unterschiede aufgelistet, die nicht zählen sollen, dazu ein Budget und Abbruchbedingungen. Das Ganze wird als Brief geschrieben, dem das kleinere Modell ohne Rückfragen folgen kann.

Claude baute daraufhin die Prüfung, einen einseitigen Brief und einen Satz von Testseiten. Die Prüfung fiel durch ihren eigenen Test – zweimal. Die erste Version zählte abweichende Pixel als Anteil des gesamten Screenshots. Da die Seite einen dunklen Hintergrund hat, stimmen die meisten Pixel überein, selbst wenn nichts auf der Seite steht; eine leere Seite kam auf 3 bis 5 Prozent. Nach der Umstellung auf den sichtbaren Inhalt sprang die leere Seite auf 57 Prozent und mehr.

Die zweite Version war zu streng. In der schmalsten Breite ergab eine Verschiebung der ganzen Seite um ein einziges Pixel eine Abweichung von 31 Prozent. Ein solcher Versatz fällt niemandem auf, also lernte die Prüfung, ihn zu verzeihen. Danach passten die Werte zum sichtbaren Eindruck: Original zweimal gerendert ergibt 0 Prozent, alles um ein Pixel verschoben ebenfalls 0 Prozent, eine um drei Pixel versetzte Überschrift 9 Prozent, ein fehlendes Hero-Bild 13 bis 34 Prozent, eine falsche Schrift 41 bis 48 Prozent, eine leere Seite 57 bis 76 Prozent.

Die Bestehensgrenze lag bei 2 Prozent des sichtbaren Inhalts, in jeder Breite. Das entspricht ungefähr einem Button, der vier Pixel daneben sitzt. Zusätzlich behielt das Team Beispiele zurück: Luna arbeitete mit 390, 768 und 1280 Pixeln Breite, die Breiten 1024 und 1440 blieben unter Verschluss. Damit ließ sich prüfen, ob das Modell die Seite gelöst hatte oder nur die Screenshots gelernt.

Vier Runden mit einem kleinen Modell

Der Prompt für Luna war eng gefasst: dem Brief folgen, immer nur eine Änderung auf einmal, danach die Prüfung ausführen und deren Ausgabe lesen. Die Prüfung, die Beispiele und die Toleranzen durften nicht bearbeitet werden. Wer glaubt, eine davon sei falsch, soll anhalten und den Grund erklären. Weiterlaufen, bis die Prüfung in allen Beispielen besteht, das Budget aufgebraucht ist oder es nicht weitergeht. Danach den Holdout-Satz ausführen und die Ergebnisse melden. Über vier Runden hinweg hat Luna die Prüfung nie angefasst – obwohl ein Agent, der eine Zahl senken will, es oft einfacher findet, die Messung zu ändern als den Code.

In Runde eins bekam Luna auf hoher Einstellung ein Budget von 90 Minuten. Der erste Versuch lag bei 41,5 Prozent, nach 34 Minuten hing das Modell bei 16,7 Prozent fest. Die Seite sah dabei fast identisch mit dem Original aus. Der naheliegende Reflex wäre gewesen, dem Modell die Schuld zu geben und ein größeres zu nehmen; geholfen hätte das nicht. Die Prüfung war falsch: Die Toleranz verzieh nur ganze Pixel, halbe Pixel zählten voll. Nach der Korrektur fiel Lunas Seite auf etwa 2 Prozent. Bei 1024 Pixeln Breite, einer Breite, die es nie gesehen hatte, schaltete sie allerdings zu früh auf das volle Menü um und verlor den linken Rand.

In Runde zwei kam eine Zeile in den Brief: Die Seite muss in jeder Zwischenbreite halten. Luna bestand die drei geprüften Breiten in neun Minuten, und der Holdout fiel genau so durch wie zuvor. Das Modell hatte den Satz gelesen, aber keine Möglichkeit, ihn zu überprüfen – also reparierte es, was die Prüfung sehen konnte. Alles, was zählt, muss in der Prüfung stehen, nicht im Brief.

In Runde drei wanderten 1024 und 1440 in die Prüfung; drei neue Breiten wurden zurückgelegt. Luna bestand alle fünf geprüften Breiten in fünf Minuten und fiel bei allen drei neuen durch. Das war der schnellste Durchlauf und das schlechteste Ergebnis. Ein schnelles Bestehen ist ein Grund, genauer hinzuschauen. Der Grund steckte im CSS: Der Menübutton wurde nur zwischen 1024 und 1100 Pixeln angezeigt, gerade genug für die eine sichtbare Breite. Außerdem war der Buchstabenabstand eines Absatzes um 0,03 Pixel verschoben, damit der Text bei 390 richtig umbrach.

In Runde vier orientierte sich das Team an Cheng Lou, der Pretext gegen den Browser selbst prüfte, indem er Claude Code und Codex die Ground Truth des Browsers zeigt und sie bei jeder signifikanten Containerbreite dagegen messen und iterieren lässt, über Wochen. Die Prüfung bekam 28 Breiten, fünf weitere blieben zurück. Luna brauchte 59 Minuten und 55 Prüfläufe, um alle 28 zu bestehen; drei der fünf zurückgelegten Breiten bestanden ebenfalls. Das Ergebnis ist eine Seite, die fast überall richtig aussieht. Das Stylesheet ist eine andere Geschichte: 21 Media Queries, viele davon decken nur 25 bis 50 Pixel ab. Ein Mensch würde ein paar fluide Regeln schreiben. Die Prüfung maß Pixel, und Pixel hat Luna geliefert. Wäre die Qualität des Codes wichtig, und bei echter Arbeit wäre sie das, bräuchte sie laut Moore eine eigene Prüfung.

Runde	Was geändert wurde	Lunas Zeit	Prüfläufe	Geprüfte Breiten	Zurückgelegte Breiten
1	Erster Lauf	34 min	63	bei 16,7 % hängengeblieben	0 von 2 bestanden
2	Halbe-Pixel-Toleranz korrigiert	9 min	15	3 von 3 bestanden	0 von 2 bestanden
3	5 Breiten geprüft, 3 neue zurückgelegt	5 min	6	5 von 5 bestanden	0 von 3 bestanden
4	28 Breiten geprüft, 5 neue zurückgelegt	59 min	55	28 von 28 bestanden	3 von 5 bestanden

Was das für eigene Agent-Loop-Projekte bedeutet

Beide Läufe führen zu denselben praktischen Hinweisen. Suche zuerst die richtige Antwort, die bereits existiert: die Ausgabe einer alten Implementierung, das Verhalten des Browsers selbst, Beispiele aus einer Spezifikation, aufgezeichneter Produktionsverkehr oder ein Benchmark, den man schlagen will. Ohne eine solche Referenz bleibt jede Prüfung Geschmackssache, und Geschmackssache kann kein Agent selbst messen.

Über alle vier Runden verbrachte Luna weniger als zwei Stunden mit der eigentlichen Kleinarbeit. Jeder Sprung zwischen den Runden kam laut Moore von einer Änderung an der Prüfung, nicht vom Modell. Daraus leitet sie weitere Regeln ab. Teste die Prüfung, bevor du ihr traust: Dasselbe zweimal gerendert muss null ergeben, bekannt schlechte Ergebnisse müssen schlecht abschneiden, akzeptable gut. Schreib auf, was nicht zählt, sonst verbringt der Agent Stunden mit Rauschen. Nutze echte Beispiele, bewerte jede Änderung gegen den ganzen Satz und halte einige zurück, um zu sehen, ob der Agent das Problem gelöst oder nur die Beispiele gelernt hat.

Alles, was zählt, gehört in die Prüfung, denn der Agent tut, was die Zahl belohnt. Die Prüfung selbst bleibt außer Reichweite: Der Agent soll wissen, dass sie feststeht, und anhalten und erklären, wenn er sie für falsch hält. Das Bauen übernimmt ein starkes Modell, die Kleinarbeit ein kleines. Vor der Punktzahl kommt der Blick auf das Ergebnis, denn ein Stillstand kann an der Prüfung liegen und ein schnelles Bestehen an einer Abkürzung. Und schließlich sollte die Prüfung bleiben: Die finalen Werte werden als Obergrenzen in einen Test übernommen, damit eine spätere Verschlechterung auffällt.

Visuell muss die Prüfung nicht sein. P90-Antwortzeiten, Fehlerraten, überprüfbares Nutzerverhalten, automatisierbare Browser-Abläufe oder schlichte Unit-Tests liefern einem Agenten ebenfalls eine Zahl oder ein Bestanden/Durchgefallen, gegen das er arbeiten kann, ohne nachzufragen. Moore schließt mit der Frage, welche Sache man bisher von Hand prüft und was nötig wäre, um sie zu messen. Der Beitrag endet mit einem Hinweis auf die eigenen Produkte: Wer sehen will, wo der Loop gelandet ist, kann eine Figma-Datei in Agent-Native Design oder eine Präsentation in Agent-Native Slides importieren. Unabhängig geprüft sind die genannten Ergebnisse nicht; es handelt sich um Angaben des Herstellers.

Quelle: builder.io