Just-in-time Retrieval

Unsere Position. Wir warten nicht auf größere Fenster: Für autonome Agenten sind Long-Context-Modelle nicht die Antwort (öffnet in einem neuen Tab). Die Codebasis ist der Zustand, das Dateisystem ist das Memory. Ein Subagent mit frischem Fenster übernimmt das schwere Lesen und gibt nur das Ergebnis zurück.

Abgewogen wird Geschwindigkeit gegen Genauigkeit. Suche zur Laufzeit kostet Roundtrips und Latenz. Hybride laden deshalb einen Teil des Kontexts vorab und lassen den Agenten den Rest erkunden. Wo Struktur zählt, ersetzt Graph-Retrieval die Ähnlichkeitssuche, etwa bei Zählabfragen oder Aufrufketten quer durch eine große Codebasis.

Soll ein Agent bei Bedarf suchen oder vorab indexieren?

Bei Coding-Agenten läuft die Retrieval-Debatte zwischen Embedding-basiertem Retrieval vor der Inferenz und agentischer Suche. Cognition hat beide Ansätze analysiert:

• Embedding-Suche (RAG) ist nach dem Indexieren schnell, aber ungenau bei Anfragen, die eine Spur quer durch eine Codebasis verfolgen. Sie kann sogar schaden, wenn der Agent irrelevante Treffer überbewertet.
• Agentische Suche mit CLI-Tools ist flexibel und genau, aber langsam. Sie verbrennt Dutzende aufeinanderfolgende Roundtrips. Der Agent muss Zehntausende irrelevante Tokens beachten, und die Qualität der Antwort sinkt.

Cognition beobachtete Agentenverläufe, die über 60 % ihres ersten Durchgangs damit verbrachten, Kontext abzurufen. Gegen diesen Zielkonflikt setzt Cognition per RL trainierte Retrieval-Subagents (SWE-grep). Sie setzen bis zu 8 parallele Tool Calls pro Durchgang ab, in höchstens 4 Durchgängen. Zurück kommen Dateien mit Zeilenbereichen statt frei formulierter Zusammenfassungen. Diese Ausgabe lässt sich prüfen, so führen die Schlüsse eines schnellen Modells den Hauptagenten nicht in die Irre (Cognition - Introducing SWE-grep and SWE-grep-mini (öffnet in einem neuen Tab)).

Anthropic ist inzwischen bei Just-in-time Retrieval als Standard für Agenten angekommen. Statt alle relevanten Daten vorab zu verarbeiten, hält der Agent leichtgewichtige Bezeichner vor: Dateipfade, Abfragen, Links. Die Daten selbst lädt er zur Laufzeit über Tools. Metadaten leisten dabei echte Arbeit: Ordnerhierarchien, Namenskonventionen und Zeitstempel zeigen Zweck und Relevanz an. Das Erkunden ermöglicht Progressive Disclosure. Der Agent baut sein Verständnis Schicht für Schicht auf und behält nur die nötige Teilmenge im Arbeitsgedächtnis.

Den Preis nennt Anthropic selbst, die Geschwindigkeit. Erkunden zur Laufzeit ist langsamer als vorberechnetes Retrieval. Hybride holen deshalb einen Teil der Daten vorab, den Rest erkundet der Agent nach eigenem Ermessen. Claude Code dient als ausgearbeitetes Beispiel: Es lädt die CLAUDE.md pauschal in den Kontext, während Glob und Grep Dateien just in time holen. So umgeht es veraltete Indizes und komplexe Syntaxbäume (Anthropic - Effective Context Engineering for AI Agents (öffnet in einem neuen Tab)).

Manus treibt die Auslagerung weiter und behandelt das Dateisystem als ultimativen Kontext. Es ist unbegrenzt, persistent und für den Agenten direkt bedienbar. Der Agent liest und schreibt Dateien als strukturiertes externes Memory. Die Kompression bei Manus lässt sich gezielt rückgängig machen. Der Inhalt einer Webseite fällt weg, die URL bleibt. Der Text eines Dokuments fällt weg, sein Pfad bleibt. So schrumpft der Kontext, ohne dass Information unwiderruflich verloren geht. Das zählt, weil niemand vorhersagen kann, welche Beobachtung zehn Schritte später entscheidend wird (Manus - Context Engineering for AI Agents: Lessons from Building Manus (öffnet in einem neuen Tab)).

Retrieval kann das Falsche liefern und dabei wie ein Erfolg aussehen. Analytische Fragen scheitern still. Ein Retriever mit festem Top-N soll sagen, wie viele Tickets offen sind. Er holt zehn, zählt darunter drei erledigte und antwortet drei, obwohl es in Wahrheit 137 sind. Vektorsuche ist nicht für Aggregation gebaut. Abhilfe schafft eine eigene Analytics-Abfrage, mehr Chunks helfen nicht (The Knowledge Gap - GraphRAG talk (öffnet in einem neuen Tab)). Ähnlichkeit ist auch keine Relevanz. “MySQL optimization” und “Postgres optimization” liegen als Embeddings nah beieinander, führen aber zur falschen Datenbank. Ein Schritt, der die Anfrage umschreibt oder aufteilt, lohnt sich deshalb (Wizard of Graph - Graph RAG talk (öffnet in einem neuen Tab)).

Chroma teilt gutes Retrieval in zwei Stufen: erst sammeln, dann aussieben. Die erste Stufe maximiert den Recall und zieht jedes möglicherweise relevante Token heran, auch auf die Gefahr von Rauschen. Die zweite maximiert die Precision und schneidet weg, was nicht dazugehört. Dieser Durchgang ist billig genug für Brute Force mit vielen kleinen, schnellen Modellen parallel (Chroma - Context Engineering for Engineers (öffnet in einem neuen Tab)). Manche Teams lagern Retrieval als gemeinsame Infrastruktur aus, statt pro Agent eine eigene Pipeline zu bauen. Sie synchronisieren die Quellen laufend, damit Embeddings nicht unbemerkt veralten (Airweave (öffnet in einem neuen Tab), Anbieter).

Im Enterprise-Maßstab wird das Argument für strukturiertes Retrieval schärfer. Auf einer Codebasis jenseits von hundert Millionen Zeilen kollidieren Embeddings, weil fast gleiche Dateien über Branches verteilt liegen. Eine Datei ist zu 99 % ähnlich, eine andere zu 98,9 %, und keine ist eindeutig die richtige. Ein Fenster mit zwei Millionen Tokens per Brute Force zu füllen kostete etwa 20 € und fünfzehn Minuten pro Prompt. Heraus kam trotzdem Code, den niemand debuggen konnte. Die Alternative parst den Code in einen Graphen. Der Agent bekommt nur die relevante Aufrufkette, vom Controller über den Endpoint bis zur Datenbank (Rethinking Software with Dev Knowledge Graphs (öffnet in einem neuen Tab)).

Graph-Retrieval beantwortet Multi-Hop- und Zählabfragen, die Embeddings nicht bedienen können, und zahlt dafür mit Latenz. Dabei steigt es eine Leiter hinauf:

1. Der Agent lädt die Nachbarn eines Knotens.
2. Das Modell wählt selbst, welchen Kanten es folgt.
3. Eine Reasoning-Schleife traversiert so lange neu, bis die Antwort die Frage erfüllt.

Der einfache Pfad braucht rund 200 Millisekunden, die Schleife Sekunden (Wizard of Graph - Graph RAG talk (öffnet in einem neuen Tab)).

Woran es immer wieder hakt, ist die Ontologie, nicht die Datenbank. Taxonomien, abteilungsübergreifend von Hand gebaut, veralten, sobald Teams sich teilen und zusammenlegen. Ein veralteter Graph liefert Müll. Deshalb setzt sich Graph-Retrieval langsamer durch, als seine Befürworter:innen erwartet hatten (Wizard of Graph - Graph RAG talk (öffnet in einem neuen Tab)). Auch das Indexieren hat eine Obergrenze. Code-Review-Plattformen berichten, dass Mapping und Indexieren irgendwo bei 600 bis 700 Repositories stark langsamer werden (Qodo - Why More Context Makes Your Agent Dumber (öffnet in einem neuen Tab)).

Ein Graph-Tool für Code geht dieses Veralten strukturell an statt durch Pflege. Es baut einen Ordner aus Markdown-Knoten, den git versioniert. Die Knoten beschreiben Subsysteme und APIs und hängen über typisierte Links zusammen (depends_on, part_of, uses). Darunter liegt ein Graph auf Symbolebene, den tree-sitter extrahiert. Embeddings und Ähnlichkeitssuche lässt das Tool bewusst weg, der Agent liest die verlinkten Dateien direkt.

Der strukturelle Durchgang braucht kein Modell und keinen API-Key. Zusammenfassungen per LLM laufen als separater, optionaler Durchgang, gecacht nach Content-Hash. Ein struktureller Refresh dauert rund 3 Millisekunden und fasst nur geänderte Dateien an. Damit lässt sich der Graph neu erzeugen wie ein Dependency-Ordner und muss nicht als Taxonomie von Hand gepflegt werden.

Die eigene kontrollierte Studie des Tools umfasst 162 Läufe mit festem Modell, nur die Kontextquelle variiert. Gegenüber einem Kaltstart meldet sie 42 % weniger Input-Tokens, 46 % weniger Tool Calls, 60 % weniger Latenz und 32 % weniger Kosten. Die Korrektheit bleibt unverändert bei 93 %. Das ist ein Benchmark des Tool-Autors, kein unabhängiger (Graft (öffnet in einem neuen Tab), MIT, Stand Juli 2026).

Ein zweiter Ansatz zielt auf die Kosten des Erstellens statt auf die des Aktualisierens. Er startet bei strukturierten Daten statt bei Code:

1. Die Tabellen-Metadaten lesen, die schon im Katalog eines Lakehouse liegen.
2. Ein Modell daraus eine OWL-Ontologie entwerfen lassen.
3. Die Klassen mit R2RML zurück auf die Tabellen abbilden.
4. Die Tripel materialisieren.

So entsteht die Ontologie aus dem Warehouse, das sie beschreibt, und wird von dort neu synchronisiert, statt daneben gepflegt zu werden. Gegenüber dem SQL-Schema bringt das Semantik, die das Schema nicht tragen kann. Reasoning nach OWL 2 RL und SWRL-Regeln leiten Beziehungen ab, die nie gespeichert wurden. SHACL-Shapes prüfen die Daten gegen sie. Den entstehenden Graphen erreichen Agenten über MCP.

Das Projekt ist früh und sagt das selbst. Die Implementierung steht unter einer Anbieterlizenz ohne OSI-Anerkennung und ist als reine Exploration ohne Support-Zusage gekennzeichnet. Ihre Fähigkeiten nennt sie ohne Benchmarks (OntoBricks (öffnet in einem neuen Tab), v0.6.2, Stand Juli 2026).

Der Praxisbericht eines Context-Engine-Anbieters schärft mehrere dieser Punkte zu Designregeln. Der Anbieter ließ denselben echten Prompt (“make a Zendesk integration first-class”) zweimal laufen. Einmal bekam der Agent naiven MCP-Zugriff pro Tool, einmal lief er über die Engine. Der naive Pull Request kompilierte und bestand jeden Check. Die Person im Senior-Review urteilte trotzdem: “would have broken our entire system if we had shipped it”. Der Pull Request der Engine bekam vor dem Merge nur einen Nitpick. Das ist ein konkreter Fall von Code, der richtig aussieht und falsch ist, und mechanische Gates übersehen ihn.

Die Diagnose leiht sich einen Begriff aus der Radiologie, Satisfaction of Search. Wer in der Radiologie ein Lungenproblem entdeckt, hört auf zu suchen und übersieht das zweite. Naives Retrieval stoppt ebenso beim ersten plausiblen Treffer statt bei der eigentlichen Ursache. Retrieval muss deshalb erschöpfend sein statt Top-N.

Eine korrekte Antwort zu cachen, um Latenz zu sparen, ist ein Anti-Pattern. Schon im Moment des Schreibens kann sie veraltet sein. Spielt der Cache sie einen Tag später ab, lügt sie praktisch, sobald sich das System darunter geändert hat. Wahrheitsgehalt bleibt ein offenes Problem, das die Engine nur teilweise löst. Angenommen, der Code auf dem Main-Branch widerspricht einem Slack-Thread, in dem der:die CTO sagt, es sei falsch gebaut. Dann gewichtet die Engine die Quellen über einen sozialen Graphen: wer was geschrieben hat und mit wem die Person arbeitet. Derselbe Graph trägt auch das OAuth-Modell über MCP für Governance pro Nutzer:in. Das wird ab rund zwanzig Personen zum Thema.

Größere Fenster lösen nichts davon auf. Selbst ein hypothetisches Fenster mit hundert Millionen Tokens hilft nur bei der Suche nach der Nadel im Heuhaufen. Über solche Mengen kann ein Modell nicht schlussfolgern, solange keine Entitäten und Beziehungen sie strukturieren (Unblocked – Stop Babysitting Your Agents (öffnet in einem neuen Tab), 26. Mai 2026).

Derselbe Anbieter liefert die Engine als MCP-Server aus und stellt sie gegen die statische Regeldatei. Statt eine von Hand gepflegte Instruktionsdatei zu lesen, fragt der Agent einen Dienst ab. Der liest GitHub, GitLab, Slack, Confluence, Notion, Jira, Linear und Google Docs live. Widersprüchliche Quellen führt er zu einer Antwort zusammen und setzt auf dem Server die Rechte der fragenden Person durch. Die Seite des Anbieters behauptet 60 % geringere Token-Kosten, 83 % schnellere Fertigstellung und neun von zehn Änderungen im ersten Anlauf mergebar. Alle Zahlen sind Selbstauskünfte des Anbieters ohne veröffentlichte Methode (Unblocked - Unblocked MCP (öffnet in einem neuen Tab), Stand September 2026).

Qodos Talk auf der AI Engineer Europe vergleicht die Retrieval-Strategien oben danach, was Aufbau und Betrieb kosten. Der Vergleich liest sich wie eine Anleitung zur Reihenfolge:

• Eine Context Engine braucht mittleren Aufwand fürs Indexieren, wird aber ab einigen hundert Repositories langsamer.
• Hierarchische Zusammenfassung braucht Agenten, die jede geänderte Datei neu zusammenfassen. Das ergibt eine hohe, wiederkehrende LLM-Rechnung.
• Ein Knowledge Graph verlangt den Entwickler:innen vorab am meisten ab. Er zahlt sich aus, wo sich Logik über viele Repositories erstreckt.
• Iteratives Retrieval gibt dem Agenten einen Index zum Nachschlagen statt einer Zusammenfassung. Rekursive Aufrufe machen jede Abfrage teurer, doch die nötige Investition ist am kleinsten. Damit ist es der empfohlene Startpunkt (Qodo - Why More Context Makes Your Agent Dumber (öffnet in einem neuen Tab), 8. Juni 2026).

Ein selbstkorrigierender Kritiker-Schritt prüft den abgerufenen Kontext gegen das ursprüngliche Ziel und versucht es bei Bedarf erneut. Er kostet Latenz, braucht aber kaum Einrichtung.

Zwei Open-Source-Tools stellen die Vektor-Position und die Position der einfachen Dateien nebeneinander. Claude Context von Zilliz indexiert eine Codebasis mit AST-bewusstem Chunking in eine Vektordatenbank. Gesucht wird hybrid, mit BM25 und Dense-Vector-Abfragen. Über Merkle-Bäume indexiert das Tool nur geänderte Dateien neu. Die eigene Evaluation meldet etwa 40 % weniger Tokens bei gleicher Retrieval-Qualität. Dafür braucht das Tool eine Vektordatenbank und einen API-Key für Embeddings (zilliztech - Claude Context (öffnet in einem neuen Tab), Stand Juli 2026).

Bei Dependencies geht opensrc von Vercel Labs den Just-in-time-Weg. Ein Befehl holt den Quellcode eines beliebigen Pakets von npm, PyPI oder crates.io oder eines GitHub-Repositorys und cacht ihn. Der Agent greppt dann den echten Bibliothekscode, statt die API aus seinen Trainingsdaten zu erraten (vercel-labs - opensrc (öffnet in einem neuen Tab), Stand September 2026).

Verwandte Seiten

• Persistentes Agenten-Memory: was ein Agent aufschreibt, damit Retrieval etwas zu finden hat.
• Speicher- und Retrieval-Architekturen: Vektor-, Graph- und Dateispeicher im Vergleich, im Maßstab einer Organisation.
• Effiziente Agent-Interfaces gestalten: wie ein Tool nur zurückgibt, was der Agent braucht.
• Kontext- und Output-Schnittstellen: wie ein Coding-Agent Kontext lädt und zurückgibt.
• Memory und Context Engineering: die übergreifende Disziplin, zu steuern, was Agenten sehen.

Quellen

Retrieval-Tools

• Claude Context (öffnet in einem neuen Tab) - MCP-Server unter MIT-Lizenz. Er gibt Coding-Agenten hybride BM25- und Vektorsuche über eine ganze Codebasis und indexiert inkrementell über Merkle-Bäume neu.
• Unblocked MCP (öffnet in einem neuen Tab) - Kommerzieller MCP-Server mit Gratis-Stufe. Er führt Code, Tickets, Doku und Chat für Coding-Agenten zu einer Antwort zusammen, die Berechtigungen beachtet.
• opensrc (öffnet in einem neuen Tab) - Experimentelles CLI von Vercel Labs unter Apache-2.0. Es holt den Quellcode von Dependencies aus npm, PyPI, crates.io und GitHub und cacht ihn, damit Agenten darin suchen können.