Ein KI-Agent, der eine Aufgabe bekommt, erschließt sich den Rest selbst: Er liest Quelltexte, sucht, probiert. Das kostet Zeit und Tokens, und er findet dabei nur, was im Code steht. Context Engineering dreht den Ansatz um — der Kontext wird vorab aus vorhandenen Datenquellen zusammengestellt, statt ihn den Agenten suchen zu lassen. Dieser Artikel erklärt das Prinzip und skizziert den Aufbau eines solchen Systems.

Grundlegendes

Die Qualität der Ausgabe eines KI-Systems, das auf Large Language Models basiert, hängt von zwei Faktoren ab:

• Güte des Modells
• Kontext der Anfrage

Als Kontext bezeichnen wir die kompletten Daten, die die Anfrage beinhaltet, also:

• Systemprompt: Verhaltensanweisung des Harness.
• Nutzerprompt: Anweisungen des Nutzers für das Modell.
• Sonstige Daten: z. B. Dateien, die die KI bearbeiten soll, oder zusätzliche Daten, die für die Verarbeitung des Nutzerprompts nötig sind.

Beim Einsatz eines Agenten hat dieser i. d. R. die Möglichkeit, sich den Kontext teilweise selbst zu erschließen oder anzureichern, z. B. durch Websuchen oder Lesen von Dateien aus dem lokalen Dateisystem. Hierzu benötigt der Agent allerdings sogenannte „Turns“. Ein Turn ist effektiv ein Request-Response-Ablauf zwischen dem Agent-Harness und dem Modellprovider:

• Das Modell stellt fest, dass es Daten aus einer Datei braucht, und erzeugt einen „Tool Call“ mit einer Leseanfrage.
• Die Anfrage landet beim Harness, das Harness führt die Leseanfrage durch, hängt das Ergebnis an die aktuelle Konversation an und schickt alles zum KI-Modell zurück.

Der letzte Punkt ist hier relevant: KI-Modelle sind inhärent zustandslos. Eine Anfrage muss immer die komplette vorangegangene Konversation beinhalten, damit das Modell eine Antwort erzeugen kann (die Konversation ist in diesem Fall der gesamte Kontext). Gleichzeitig „kosten“ Modelle pro verarbeitetem und erzeugtem Token. Somit zahlt der Nutzer für jeden „Turn“ die Tokenkosten für die ganze Konversation. Je länger die Konversation ist, desto höher sind die Kosten – i. d. R. haben die KI-Anbieter noch Cachingmechanismen, durch die dies billiger wird, dennoch werden für jeden Turn Kosten erzeugt, die mit der Länge der Konversation skalieren. Bedeutet also: Je weniger Turns wir für die Erledigung einer Aufgabe brauchen, desto besser. Wenn gleichzeitig auch noch der Kontext (respektive die Konversation) möglichst klein gehalten werden kann, ist es noch besser.

Was ist Context Engineering?

Unter Context Engineering verstehen wir den Sprung von einem chatbasierten Interface zwischen Agenten und Nutzer hin zu einem Kontext, der so erzeugt wird, dass er alle wichtigen Daten bereits enthält und die KI sich so wenig wie möglich selbst erschließen muss. Letzteres ist insbesondere dann wichtig, wenn es Datenquellen gibt, die für die KI nicht greifbar sind. Beispiel:

Wenn wir einen KI-Agenten zur Entwicklung von Software einsetzen, so bekommt er im Regelfall die konkret zu implementierende Aufgabe als Userprompt. Er wird sich dann die Quelltexte erschließen und auf dieser Basis seine Implementierung planen. Das Problem: In diesem Szenario kann der Agent nur sehen, was bereits im Code ist, nicht, was z. B. noch geplant ist, und er kann auch keine „Design Rationale“ für die vorliegende Implementierung sehen. Diese Daten muss der Nutzer liefern, und das für jedes Ticket neu.

Bei der Verwendung von Context Engineering gehen wir davon aus, dass ein großer Teil dessen, was der Agent an Eingabe erhält, automatisch aus verschiedenen Datenquellen erzeugt wird. Im Beispielfall kann das z. B. ein Gesamtkonzept sein oder verwandte Tickets, oder auch Konzepte, deren Zusammenhang mit der aktuellen Aufgabe im Code gar nicht sichtbar ist. Sauber entkoppelte Architekturen entfernen solche Bezüge oft bewusst aus dem Quelltext. Ein Agent, der nur den Code liest, findet sie deshalb nicht.

Warum ist Context Engineering wichtig und sinnvoll?

Context Engineering verringert den Aufwand, den ein Agent betreiben muss, um eine Lösung für seine Aufgabe zu ermitteln. Weiterhin erhöht es die Chance, dass der Agent bei der Lösungsfindung nichts übersieht. Allerdings ist der Kontext dadurch gleich zu Beginn deutlich größer, als wenn nur die Aufgabe und der Systemprompt übergeben würden. Da wir die Kontextgröße pro Turn bezahlen, ist das hier ein Trade-off, der vor allem dann funktioniert, wenn die resultierende Lösung deutlich besser ist und weniger Nacharbeit erfordert. Idealerweise hilft uns allerdings das – bereits genannte – Caching dabei, die Kosten nicht explodieren zu lassen, und zusätzlich wird der Agent im besten Falle weniger „Turns“ zur Lösungsfindung benötigen, wodurch der größere Startkontext zumindest teilweise ausgeglichen wird. Was wir dadurch erhalten, ist eine bessere Lösung für die gestellte Aufgabe.

Wie funktioniert ein Context-Engineering-System?

Wie sieht nun eine Implementation für ein Context-Engineering-System aus? Schematisch gesehen besteht das System aus mehreren Komponenten:

Unsere Tasks und die zugehörigen Daten (welche Form sie auch immer haben) liegen in einem oder mehreren Quellsystemen vor, die das Context-Engineering-Tool abfragen kann. Die Quellen können vielgestaltig sein, z. B. Dateisysteme, Datenbanken, Webseiten etc. Wichtig ist lediglich, dass das Context-Engineering-Tool in der Lage ist, diese Quellen zu verwenden.

Das Tool bekommt einen Task zur Bearbeitung vorgelegt. Bevor der Task an den Agenten weitergereicht wird, löst das Tool alle Datenverweise auf und erzeugt aus dem Task und den Daten den eigentlichen Prompt, der zum Agenten geht. Dieser Promptsyntheseschritt kann beliebig gestaltet werden; wenn die Daten z. B. strukturiert sind, könnten bspw. nur einzelne Felder der Daten in den Prompt übernommen werden.

Beispiel: Gegeben sei ein Ticket A mit folgendem Inhalt:

„Implementiere einen Logindialog für das System. Der Nutzer soll Nutzername und Passwort angeben; der Login-Endpoint des Backends [[Referenz: Backend Login Endpoint]] führt die Authentifizierung durch.“

Das Ticket referenziert den Backend Login Endpoint. Der Inhalt der Referenz ist wie folgt:

„Der Login-Endpoint wird über die /login-URL angeboten.

Eingabe: POST mit JSON-Body:

{
    "username": <username>,
    "password": <password>
}

Nutzername und Passwort sind Plaintext.

Ausgabe: HTTP 200, mit JSON-Body:

{
    "result": "success",
    "session_id": "session id"
}

Im Fehlerfall HTTP 400 ohne Body. Fehlerfälle sind dabei: Nutzer nicht gefunden, Passwort falsch.“

Aus diesem Beispiel ergibt sich direkt die Stärke von Context Engineering: Das Ticket selbst beinhaltet keinerlei Informationen dazu, wie genau der Login durchzuführen ist. Der Agent müsste den Quelltext des Backends analysieren, um das herauszufinden, sofern er überhaupt Zugriff auf den Quelltext hat. Ein Context-Engineering-Tool könnte aus Ticket und Referenz trivial folgenden Prompt erzeugen:

Implementierungsaufgabe

Aufgabe

„Implementiere einen Logindialog für das System. Der Nutzer soll Nutzername und Passwort angeben; der Login-Endpoint des Backends [[Referenz: Backend Login Endpoint]] führt die Authentifizierung durch.“

Relevante Daten

In diesem Abschnitt stehen referenzierte Daten. Benutze diese Informationen für deine Implementationsplanung.

Backend Login Endpoint

„Der Login-Endpoint wird über die /login-URL angeboten.

Eingabe: POST mit JSON-Body:

{
    "username": <username>,
    "password": <password>
}

Nutzername und Passwort sind Plaintext.

Ausgabe: HTTP 200, mit JSON-Body:

{
    "result": "success",
    "session_id": "session id"
}

Im Fehlerfall HTTP 400 ohne Body. Fehlerfälle sind dabei: Nutzer nicht gefunden, Passwort falsch.“

Der so erzeugte Prompt beinhaltet alle Informationen, die der Agent braucht, um den Login zu implementieren – er weiß, dass er einen POST-Request an die /login-URL absenden muss, er kennt den Inhalt, der mitgeschickt werden muss, und ihm wurde mitgeteilt, wie die Antwort im Gut- und im Schlechtfall aussieht.

Aus dem Beispiel ergibt sich auch eine natürliche Begrenzung dessen, was Context Engineering leisten kann: Damit wir einen echten Vorteil daraus ziehen können, sind die Qualität der Eingabedaten und ihre Vernetzung entscheidend. Wenn unsere Aufgaben keinerlei Daten referenzieren, dann sind sie für das CE-System effektiv Inseln, und wir haben keinen Vorteil gegenüber der reinen CLI-Verwendung des Agenten. Je dichter Tickets, Konzepte und Dokumentation untereinander verlinkt sind, desto mehr kann das System beisteuern.

Bei der Qualität sind zwei Aspekte zu unterscheiden. Aktualität und Korrektheit sind kritisch: Plant der Agent gegen veraltete oder falsche Daten, wird die Implementierung ebenfalls falsch – und zwar zuverlässig, bei jeder Aufgabe. Vollständigkeit dagegen ist weniger scharf. Eine lückenhafte Vernetzung führt zu einer schrittweisen Degradation der Ergebnisqualität; im schlimmsten Fall landen wir wieder bei dem, was die CLI-Verwendung erzeugt hätte. Dieser Vergleich fällt allerdings günstig aus: Auch ein Entwickler kennt nicht alle Tickets, die für seine Aufgabe relevant wären, und übersieht gerade die nicht offensichtlichen Zusammenhänge. Eine unvollständige automatische Auflösung ist deshalb im Regelfall immer noch besser als eine unvollständige manuelle.

Fazit

Ein KI-Agent ist nur so gut wie das, was er zu sehen bekommt. Erschließt er sich seinen Kontext selbst, findet er nur, was im Code steht — und bezahlt jeden Suchschritt mit einem weiteren Turn. Context Engineering stellt den Kontext vorab aus den Quellen zusammen, in denen das Wissen ohnehin liegt: Tickets, Konzepte, Dokumentation. Der technische Aufwand dafür ist überschaubar, entscheidend ist die Qualität und Vernetzung der Daten.