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
