Context Engineering: Kontext für die KI-Agenten schaffen

Kontextbaukasten: Vier zentrale Quellen

Um solchen Kontext zu bauen, gilt es zu klären: Was ist eigentlich Kontext?

Menschlicher Input

Jede Interaktion beginnt damit, dass ein User eine Frage stellt oder eine Aufgabe formuliert. Gleichzeitig entsteht Kontext aber auch durch den Entwickler: Systemarchitekten oder Prompt Engineers entwerfen initiale Prompts, die das Verhalten des Modells für den Anwendungsfall gezielt steuern.

Zudem stellt der Modellanbieter stets selbst einen umfassenden System-Prompt bereit, der grundlegende Regeln, Fähigkeiten und Einschränkungen definiert. Moderne Agentensysteme arbeiten wiederum mit dynamischen Prompt-Anteilen: Prompts werden zur Laufzeit ergänzt oder neue Informationen eingebettet.

Kognitive Steuerung

Bei der kognitiven Steuerung geht es nicht mehr primär um Fakten oder Daten, sondern um Input, der dem Modell beim Denken hilft: beim Planen, Schlussfolgern und Entscheiden. Dazu gehören beispielsweise Policen, Entscheidungsrahmen und Metadaten, die Risikoschwellen oder Prioritäten festlegen.

Auch Mechanismen wie Reflexion oder Eigenbewertung fallen in diesen Bereich: Das Modell bewertet Zwischenergebnisse oder arbeitet mit Chain-of-Thought-ähnlichen Strukturen, um Entscheidungen besser abzusichern.

Gedächtnisschichten

Provider ergänzen inzwischen teilweise serverseitige Memory-Dienste, im Kern ist jedoch jeder einzelne LLM-Aufruf zunächst stateless: Das Modell vergisst zwischen den Aufrufen, sofern Informationen nicht erneut eingebracht werden.

Das Arbeitsgedächtnis entspricht dem Session State: Was hat das Modell in dieser Sitzung bereits gesehen? Welche Zwischenergebnisse kamen aus Tool Calls? Was hat der Benutzer gefragt und was hat das Modell bisher geantwortet, geplant oder entschieden?

Das Langzeitgedächtnis umfasst episodische Erfahrungen, prozedurale Ausführungsketten oder gespeicherte Nutzerinformationen. Strukturierte Informationen – etwa Entitäten, Beziehungen und Abhängigkeiten – sind dabei zentral und lassen sich in Datenbanken, zum Beispiel in Graphdatenbanken, hinterlegen.

Daten und Werkzeuge (Tools)

Mit dem Aufstieg von agentischer KI, MCP-Servern und der wachsenden Zahl an Tools, zeigt sich auch die Werkzeugnutzung als zentraler Bestandteil des Kontexts. Bereits deren Definitionen beeinflussen das Modell: Welche Werkzeuge sind verfügbar? Welche Ergebnisstrukturen liefern sie?

Hinzu kommen die Ergebnisse der Werkzeugaufrufe, der ebenfalls verarbeitet werden müssen. Hier kommen Retrieval-Mechanismen wie API- und Datenbankzugriffe, Vector RAG oder GraphRAG ins Spiel, um relevante externe Informationen in den laufenden Aufgabenprozess einzubetten.

Im Kontextfenster konkurriert alles um Aufmerksamkeit des Modells. Angesichts der vielschichtigen Quellen erstaunt es da wenig, dass KI-Systeme mitunter falsche Prioritäten setzen und unerwartete Ergebnisse liefern.

In der Praxis zeigen sich immer wieder typische Fehlermuster: Mit wachsendem Kontextumfang verliert das Modell schrittweise den Fokus (Context Rot), frühe Annahmen ziehen den weiteren Verlauf in eine bestimmte Richtung (Context Distraction) oder ungeprüfte Informationen setzen sich als scheinbare Fakten fest (Context Poisoning).

Context Engineering: Management des Kontextfensters

Genau deshalb braucht es Context Engineering – nicht als Sammlung von Quellen, sondern als System zur aktiven Steuerung. Das Konzept des Minimal Viable Context (MVC) ist an dieser Stelle hilfreich: Für den nächsten Schritt zählt nur die Mindestmenge an Information, die die Aufgabe zuverlässig lösbar macht. Alles Irrelevante – Informationsballast, überlange Dokumente oder riesige Tool-Outputs – bleibt draußen. Ziel ist ein maximales Signal-to-Noise-Ratio im Kontextfenster.

Es gibt verschiedene Strategien, um den wachsenden Kontext zu steuern. Beim Offloading zum Beispiel wandern Informationen aus dem Prompt in externe Speicher wie File-Systeme, Vektor- oder Graphdatenbanken. Im Kontext verbleiben nur Zusammenfassung, Extrakt oder Referenz, während Kontext-Tools bei Bedarf den vollständigen Inhalt wieder hervorholen. Episodische Erinnerungen (Textpassagen) passen gut in Vektordatenbanken, strukturierte oder prozedurale Informationen eher in Graphen. Offloading entlastet das Kontextfenster und trennt den relevanten Arbeitskontext von dauerhaftem Wissen.

Eine andere Strategie setzt auf Reduktion und Kompression: Rohdaten müssen vorab verdichtet werden, bevor sie Tokens, Latenz und Aufmerksamkeit binden. Zusammenfassungen sparen Platz, kosten aber Informationsgehalt, weshalb oft ein Mix aus Extraktion relevanter Daten und externer Komplettspeicherung sinnvoll ist. Besonders an Informationsgrenzen – Werkzeugaufrufen oder Multi-Agent-Handover – reichen häufig IDs oder Verweise statt ganzer Textblöcke. Gerade Aufrufergebnisse sollte man vorverarbeiten oder auslagern, um Token-Kosten und unbeabsichtigte Inhaltsänderungen zu vermeiden.

Schlussendlich lassen sich alle Informationen bei Bedarf gezielt laden – über RAG, GraphRAG, andere Datenbanken, Dateien oder andere spezialisierte Tools (Retrieval). Dafür müssen Tool-Definitionen aber klar zeigen, welche Eingaben aus welchen Ergebnissen bedient werden können, und implizite Abhängigkeiten von Werkzeugaufrufen explizit machen, damit das Modell Aufrufketten besser planen kann.

Ergänzend spielt Context Caching eine Rolle: Stabile Elemente wie System Prompt, Rollen und Policies bleiben persistent, während weiter oben in der Kontexthierarchie nur flüchtige Inhalte wie aktuelle Ergebnisse oder die letzte Nutzerinteraktion stehen. So lässt sich der Kontext dynamisch schichten und effizient nachladen.

Kontrolle im Agentenkreislauf

Für agentische KI ist die Steuerung des Kontexts (Context Engineering) daher zentral. KI-Agenten scheitern oft weniger am Modell selbst, sondern daran, dass Aufgaben, Instruktionen, notwendiger Kontext oder Rahmenbedingungen unscharf bleiben. Wie bei Menschen gilt auch hier: Nur klare Ziele, saubere Grenzen und relevante Informationen ermöglichen zuverlässiges Handeln.

Ein typischer Agentenkreislauf umfasst drei Phasen:

• Planung: Der Agent klärt Ziel und Aufgabe, zerlegt sie in Teilprobleme und entscheidet, ob eine direkte Antwort möglich ist oder weitere Informationen benötigt werden.
• Ausführung: Werkzeuge wie APIs, Datenbanken oder MCP-Server liefern gezielt Informationen oder führen Aktionen aus.
• Auswertung: Die Ergebnisse werden bewertet, relevante Signale gefiltert und neue Signale integriert. Anschließend entscheidet der Agent, ob eine Antwort generiert werden soll oder eine weitere Iteration erforderlich ist.

Im KI-Agenten-Kreislauf verlangt jede Phase andere Kontextbestandteile. Die Planung benötigt Ziele, Rollen, Arbeitsgedächtnis und Verfügbarkeit von Werkzeugen; die Ausführung präzise Parameterzuordnung und robuste Werkzeugnutzung; die Auswertung fokussiert auf die Validierung und Bewertung. Ein Agent operiert damit nicht in einem einzigen Kontext, sondern in mehreren überlagerten Kontexten pro Iteration – und jede zusätzliche Runde verstärkt die Komplexität und bringt mehr gesammelte Informationen ein.

In Multi-Agent-Architekturen verschärft sich das Ganze weiter. Kontext verteilt sich nun über mehrere Spezialisten: Welche Informationen teilen Agenten, welche bleiben lokal und wie lassen sich widersprüchliche Entscheidungen vermeiden? Divide and Conquer (Aufteilung in Teilprobleme) steigert die Effizienz, verlangt aber klare Übergabegrenzen, definierte Zuständigkeiten und Mechanismen zur Konfliktauflösung.

Gleichzeitig gewinnen Werkzeuge als Sensoren und Aktoren weiter an Bedeutung: Sie verleihen Handlungsfähigkeit durch ein Pull-Prinzip, bei dem Agenten Informationen gezielt ermitteln, statt sie vollständig in den Prompt gedrückt zu bekommen (wie beim klassischen RAG). Sauber definierte Werkzeugschnittstellen, strukturierte Outputs und Metadaten bilden damit das Navigationssystem in großen Informationsräumen.

Vom Knowledge Graph zum Context Graph

Graphtechnologie spielen im Context Engineering eine besondere Rolle, weil sie strukturierte Wissensräume bereitstellen, die sich gezielt in agentische Systeme einbinden lassen. Während LLMs vor allem Fähigkeiten für Sprache, Generierung, Extraktion, Transformation und Schlussfolgerungen liefern, ergänzen Knowledge Graphen die fehlende Struktur: Entitäten, Beziehungen, Abhängigkeiten und Entscheidungspfade. Ein Agent kann so etwa nicht nur einen Kunden betrachten, sondern auch dessen Verträge, Ansprechpartner, Ausnahmen und frühere Entscheidungen im Zusammenhang erfassen.

Der entscheidende Vorteil liegt in der Relevanzsteuerung. Knowledge Graphen erlauben es, Information nicht als isolierte Textfragmente zu betrachten, sondern über Graphtraversierung gezielt die jeweils relevanten Kontextinformationen auszuwählen – ähnlich wie eine Navigation, die nicht die ganze Karte lädt, sondern nur die nächste sinnvolle Route und die relevanten Punkte entlang dieser Route.

„Graphtechnologie spielen im Context Engineering eine besondere Rolle, weil sie strukturierte Wissensräume bereitstellen, die sich gezielt in agentische Systeme einbinden lassen. Während LLMs vor allem Fähigkeiten für Sprache, Generierung, Extraktion, Transformation und Schlussfolgerungen liefern, ergänzen Knowledge Graphen die fehlende Struktur: Entitäten, Beziehungen, Abhängigkeiten und Entscheidungspfade.“

Michael Hunger, Neo4j

Gleichzeitig verbessern Graphrepräsentationen und -ergebnisse die Rückverfolgbarkeit von Pfaden, Quellen und Bewertungen. Das macht nachvollziehbar, warum eine bestimmte Information überhaupt Teil des Kontexts ist und woher die Informationen originär stammen. Auch Governance-Aspekte wie Zugriffskontrolle, Auditierung oder Policy-Verknüpfungen lassen sich auf Graphstrukturen direkt abbilden.

Ein besonders spannender Ansatz sind Context Graphen: Sie speichern nicht nur Fakten (das Was), sondern implizites Wissen über Entscheidungen (das Warum). Ein Context Graph wird damit zum Routenplaner für Agentenentscheidungen. Als strukturierte Wissensschicht ergänzt er die probabilistische Logik von Sprachmodellen um eine explizite, deterministische Kontextgrundlage, die Entscheidungen stabil, nachvollziehbar und für KI-Agenten reproduzierbar macht.

Damit markiert Context Engineering den nächsten Entwicklungsschritt: weg vom Prompt, hin zum Kontext als kontrollierbarer Entscheidungsraum.

Über den Autor:
Michael Hunger beschäftigt sich seit mehr als 35 Jahren leidenschaftlich mit Softwareentwicklung. In den letzten 13 Jahren hat er an der Open-Source-Graphdatenbank Neo4j in verschiedenen Funktionen gearbeitet, zuletzt als Leiter der Produktinnovation und Entwicklerstrategie. Sein aktueller Fokus liegt auf generativer KI, Cloud-Integrationen und Developer Experience.

Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.