Harness Engineering (1/5): Warum gutes Context Engineering über zuverlässige Agenten entscheidet

Moderne KI Agenten arbeiten auf Basis leistungsfähiger Sprachmodelle, die enorme Informationsmengen verarbeiten können. Da liegt die Annahme nahe: Je mehr Informationen ein Agent erhält, desto besser wird das Ergebnis. Also bekommt er alle relevanten Dokumente, verfügbaren Tools und den kompletten bisherigen Verlauf. In der Praxis ist jedoch oft das Gegenteil der Fall. Mehr Kontext führt nicht automatisch zu besseren Ergebnissen und kann Agenten sogar unzuverlässig machen.

Mit diesem Beitrag starten wir unsere neue Reihe zum Harness Engineering. Der Weg von einer ersten Demo zu einem KI Agenten, der im Tagesbetrieb zuverlässig arbeitet, ist weiter, als viele erwarten. Entscheidend ist dabei oft nicht das Sprachmodell selbst, sondern die Infrastruktur, die den Agenten umgibt. Sie stellt den passenden Kontext bereit, bindet Werkzeuge an, steuert Abläufe und überprüft Ergebnisse. Dieses Zusammenspiel bezeichnet man als Harness.

Den Auftakt macht das Context Engineering. Wir zeigen, warum mehr Kontext nicht automatisch bessere Ergebnisse liefert, wie sich Kontext sinnvoll strukturieren lässt und welche Prinzipien dafür sorgen, dass KI Agenten auch bei komplexen Aufgaben zuverlässig arbeiten.

Vom Prompt zum Kontext

Lange Zeit drehte sich im Umgang mit Sprachmodellen alles um das Prompt Engineering. Entscheidend war vor allem die richtige Formulierung. Bei komplexeren Agenten reicht das jedoch nicht mehr. Ein Agent arbeitet über viele Schritte, ruft Tools auf, sammelt Zwischenergebnisse und zieht Dokumente heran. All das landet im selben begrenzten Kontext. 

Context Engineering beschreibt die Aufgabe, bei jedem einzelnen Schritt bewusst zu entscheiden, was das Modell tatsächlich sehen soll und was nicht. Nicht mehr „Welche Worte wähle ich?“, sondern „Welche Informationen braucht das Modell jetzt, um die Aufgabe gut zu lösen?“ 

Woraus Kontext eigentlich besteht 

Um nachvollziehen zu können, woraus Kontext besteht, hilft es, Kontext nicht als einen einzigen Block zu betrachten, sondern als verschiedene Bausteine mit unterschiedlicher Lebensdauer. Ordnet man sie danach, wie häufig sie sich verändern, ergibt sich ein einfaches und praxistaugliches Modell (Abbildung 1). 

Abbildung 1: Einordnung von Kontextbestandteilen nach ihrer Lebensdauer

Die stabile Schicht gilt für jeden Aufruf gleich: Rolle und Auftrag, Regeln und Leitplanken, Tool-Definitionen, Ausgabeformate, wenige gute Beispiele. Sie wird einmal sorgfältig gebaut und danach selten angefasst. 

Die Aufgaben-Schicht gilt für einen Vorgang: die konkrete Anfrage, Nutzer- und Mandantenkontext, Projektwissen, Präferenzen aus früheren Läufen. 

Die Laufzeit-Schicht ändert sich mit jedem Schritt: abgerufene Dokumente, Tool-Ergebnisse, Zwischennotizen, der bisherige Verlauf, Umgebungszustand wie Datum, Berechtigungen oder Dateibaum. 

Die Einteilung macht vor allem deutlich, wo die eigentliche Arbeit anfällt. Die stabile Schicht ist Handwerk: Einmal gut aufgebaut, hält sie lange. Die Laufzeit-Schicht ist dagegen die größte Herausforderung, weil sie unkontrolliert wächst und in langen Läufen schnell den Großteil des Kontextfensters ausmacht. Genau dort entscheidet sich, ob ein Agent zuverlässig bleibt. 

Wie sich Context Engineering je nach Aufgabe verändert

Nicht jeder Agent benötigt alle Schichten in gleichem Maße. Welche Schichten im Vordergrund stehen, hängt von der jeweiligen Aufgabe ab. Dabei lassen sich typische Muster erkennen (Abbildung 2). 

Abbildung 2: Gewichtung der Kontextschichten für unterschiedliche Agententypen

• Ein auskunftgebender Assistent beantwortet Anfragen in der Regel direkt. Entscheidend ist dabei ein präziser Informationsabruf. Wenige, gut ausgewählte Dokumente sind wertvoller als viele mittelmäßige. Verlauf und Zwischenergebnisse spielen kaum eine Rolle. 
• Ein Recherche-Agent durchsucht große Informationsmengen und soll am Ende die wichtigsten Erkenntnisse liefern. Hier lohnt sich die Aufteilung in Teilagenten: Sie übernehmen die Recherche, während an den Hauptagenten nur die verdichteten Ergebnisse zurückgegeben werden. 
• Ein Coding- oder Systemagent braucht vor allem verlässliche Struktur: klare Regeln, gute Tools und die Möglichkeit, gezielt auf Dateien zuzugreifen. Statt den gesamten Quellcode eines Repositorys, also des zentralen Speichers eines Softwareprojekts, in den Kontext zu laden, reicht es, die jeweils relevanten Dateien einzulesen. 
• Ein langlaufender Workflow-Agent stellt die größten Anforderungen an das Context Engineering. Über viele Schritte hinweg wächst der Verlauf kontinuierlich. Ohne regelmäßiges Verdichten und das Auslagern von Informationen außerhalb des Kontextfensters wird der Kontext schnell unübersichtlich und der Agent verliert an Zuverlässigkeit. 

Als Faustregel gilt: Je länger ein Agent arbeitet, desto weniger geht es darum, möglichst viele Informationen bereitzustellen, und desto mehr darum, den Kontext gezielt zu verwalten. 

Warum „viel Kontext" nicht „guter Kontext" ist

Ein Modell verteilt seine Aufmerksamkeit nicht gleichmäßig über das gesamte Fenster. Je voller es wird, desto eher gehen entscheidende Details unter. Dieser Effekt ist inzwischen als Context Rot bekannt und zeigt sich quer über alle gängigen Modelle. Ein größeres Fenster verschiebt diese Grenze nur, es hebt sie nicht auf.

Zu viel Kontext ist dabei kein neutraler Ballast. Überflüssige oder widersprüchliche Informationen lenken das Modell aktiv ab, verleiten zu irrelevanten Tool-Aufrufen oder führen dazu, dass es an einer einmal eingeschlichenen Falschannahme festhält und sie über viele Schritte weiterträgt. Mehr Kontext kann die Qualität also nicht nur verwässern, sondern messbar verschlechtern.

Vier Strategien für besseres Context Engineering

Für den Umgang mit Kontext haben sich vier Grundmuster etabliert. Sie greifen alle am Kontextfenster an, aber zu unterschiedlichen Zeitpunkten (Abbildung 3).

Abbildung 3: Strategien zur Verwaltung des Kontexts

1. Auslagern: Informationen bewusst außerhalb des Fensters halten – in Dateien, Notizen, einem Ticket, einem Scratchpad. Der Agent schreibt Zwischenstände heraus und liest sie gezielt wieder ein. 
2. Abrufen: Nur hereinholen, was der nächste Schritt braucht: über Suchanfragen, Dateipfade, IDs. Statt fünf Dokumente vorab lieber ein Tool, mit dem sich das richtige finden lässt. 
3. Verdichten: Den laufenden Verlauf zusammenfassen, sobald er zu groß wird. Rohdaten heraus, Entscheidungen und offene Punkte hinein. 
4. Trennen: Teilaufgaben an spezialisierte Agenten mit eigenem, sauberem Fenster übergeben. Was dort an Suchrauschen anfällt, erreicht den Hauptkontext nie. 

Die wenigsten Systeme brauchen alle vier von Anfang an. Aber es hilft zu wissen, an welcher Schraube man dreht, sobald ein Agent unzuverlässig wird. 

Best Practices für den Agentenalltag

Aus Projekten heraus zeigen sich immer wieder dieselben Maßnahmen, die die Zuverlässigkeit von KI Agenten deutlich verbessern: 

• Kontextbudget festlegen: Definieren Sie, wie viel Kontext ein Agent nutzen darf. Wird das Budget überschritten, sollte der Verlauf strukturiert verdichtet werden.
• Nur relevante Informationen weitergeben: Übergeben Sie nur die Informationen, die für den nächsten Schritt benötigt werden – möglichst als Verweis statt als vollständigen Inhalt.
• Position beachte: Dauerhafte Anweisungen gehören an den Anfang des Kontexts, die aktuelle Aufgabe an das Ende. 
• Widersprüche entfernen: Veraltete Anweisungen, doppelte Dokumente und widersprüchliche Informationen sollten konsequent entfernt werden. 
• Kontextverbrauch messen: Erfassen Sie die Kontextgröße regelmäßig, um besonders speicherintensive Tools oder Dokumente zu identifizieren und gezielt zu optimieren.  

Fazit

Die entscheidende Frage lautet nicht: „Wie viel Kontext kann ich bereitstellen?“, sondern: „Welchen Kontext braucht der Agent genau jetzt?“ Gutes Context Engineering bedeutet, Informationen gezielt auszuwählen und zu steuern, statt sie ungefiltert anzuhäufen. Je komplexer KI Agenten werden, desto stärker entscheidet dieser Informationsfluss über ihre Zuverlässigkeit. ​

Bei DataSpark sehen wir aktuell viele Unternehmen genau an diesem Punkt. Erste Erfahrungen mit Prompting sind gemacht, jetzt sollen größere Use Cases folgen, die sich mit Prompts allein nicht mehr abbilden lassen. Genau dort beginnt Harness Engineering. Und Context Engineering ist der erste Schritt, um aus vielversprechenden Ideen Agenten zu machen, die im Tagesbetrieb überzeugen.

Ausblick auf Teil 2 der Beitragsserie

Kontext ist allerdings nur die eine Hälfte. Sobald ein Agent nicht mehr nur antwortet, sondern handelt, kommt es darauf an, welche Werkzeuge ihm dafür zur Verfügung stehen. Genau darum geht es im nächsten Teil: Tool Engineering. Wir schauen uns an, wie Tools gestaltet sein sollten, damit ein Agent sie zuverlässig und richtig einsetzt, und warum auch scheinbare Details wie eine gute Fehlermeldung darüber entscheiden können.