AI Architecture · 8 Min.
Context Engineering für KI-Agenten: Der Unterschied zwischen smarter Antwort und echter Autonomie
Ein Agent ist nur so gut wie sein Kontext. Wer alles in einen Prompt kippt, bekommt keine Autonomie, sondern Zufall mit viel Selbstvertrauen.
SYSTEMS Grafik zu Context Engineering KI: Data -> Agent -> Outcome. Fokus: Wie baut man Kontext fuer KI-Agenten so, dass sie nicht halluzinieren oder zu viel laden?
Kurzfassung
Context Engineering entscheidet, welche Informationen ein Agent wann sehen darf. Guter Kontext ist geschichtet: Ziel, Rolle, Daten, Tools, Memory, Regeln und aktuelle Aufgabe. Die wichtigste Regel: Nicht mehr Kontext laden, sondern den richtigen Kontext im richtigen Moment.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Warum der Prompt nicht mehr reicht Viele Teams behandeln Agenten wie Chatbots mit mehr Text. Sie schreiben eine lange Rollenbeschreibung, hängen ein paar Dokumente an und hoffen, dass das Modell daraus schon den richtigen Weg findet. Das funktioniert bei einfachen Antworten. Es scheitert, sobald der Agent mehrere Schritte ausführen, Tools auswählen oder Daten bewerten soll.
Context Engineering ist die Architektur hinter dem Prompt. Es beantwortet nicht nur, was der Agent wissen soll, sondern auch, wann er es wissen soll, aus welcher Quelle es kommt, wie frisch es ist und welche Information Vorrang hat.
Stand Mai 2026: Kontext ist Betriebsdesign MCP beschreibt bewusst nur den Austausch von Kontext zwischen Host, Client und Server. Es entscheidet nicht, wie eine Anwendung diesen Kontext bewertet, priorisiert oder wieder verwirft. Genau dort beginnt Context Engineering.
OpenAI zeigt beim Prompt Caching ausserdem einen praktischen Betriebsaspekt: Statische, wiederkehrende Anweisungen gehoeren an den Anfang, variable Nutzerdaten ans Ende. Das ist nicht nur Kostenoptimierung. Es zwingt Teams dazu, Kontext in stabile und dynamische Schichten zu trennen.
Fuer Agenten bedeutet das:
Ein guter Kontext ist nicht maximal. Er ist absichtlich.
Stabile Regeln zuerst. Aktuelle Aufgabe separat. Tool-Schemas nur wenn noetig. Memory nur mit Zweck und Lebensdauer. Externe Inhalte als Daten, nicht als Befehle. Kosten, Latenz und Cache-Hit-Rate als Architekturmetriken. Die sechs Kontextschichten Ein produktiver Agent braucht klare Kontextschichten. Wenn diese Schichten vermischt werden, wird der Agent schwer steuerbar.
Die Kunst liegt darin, diese Schichten nicht pauschal in jedes Modellfenster zu werfen. Ein Sales-Agent braucht beim ersten Lead-Scan andere Informationen als beim finalen Entwurf einer E-Mail.
Mission: Was ist das Ziel des Agenten? Rolle: Welche Verantwortung hat er, und welche nicht? Arbeitsdaten: Welche aktuellen Inputs verarbeitet er gerade? Wissen: Welche Dokumente, CRM-Daten, Regeln oder Playbooks gelten? Tools: Welche Aktionen kann er ausführen? Grenzen: Wann muss er stoppen, fragen oder eskalieren? Der Kontextvertrag pro Arbeitsschritt Jeder agentische Schritt sollte einen kleinen Kontextvertrag haben. Er beantwortet:
Ohne diesen Vertrag verschwimmen Planung, Recherche, Tool-Use und Entscheidung. Dann sieht der Agent klug aus, ist aber schwer auditierbar.
Ziel: Was soll in diesem Schritt entschieden oder erzeugt werden? Eingaben: Welche Daten sind erlaubt? Quellenrang: Welche Quelle gewinnt bei Widerspruch? Tools: Welche Aktionen sind fuer diesen Schritt freigegeben? Memory: Was darf aus frueheren Laeufen genutzt werden? Output: Welches Format erwartet der naechste Schritt? Stop-Regel: Wann muss der Agent eskalieren? RAG, MCP und Memory richtig trennen RAG liefert abrufbares Wissen. MCP verbindet Tools und Datenquellen. Memory speichert wiederverwendbare Erkenntnisse aus früheren Abläufen. Diese drei Dinge sind verwandt, aber nicht austauschbar.
Ein häufiger Fehler ist, alles als Vektorsuche zu behandeln. Dann landen Prozessregeln, Kundendaten, Tool-Schemas und alte Notizen im selben Topf. Der Agent bekommt zwar viel Kontext, aber keine klare Priorität. Besser ist eine Architektur, in der jede Quelle eine Aufgabe hat.
Der Context-Router als Kernbaustein Sobald mehrere Datenquellen existieren, braucht der Agent einen Context-Router. Das kann ein eigener Service, eine Tool-Schicht oder ein Orchestrierungsmodul sein. Seine Aufgabe ist einfach: Er entscheidet, welche Information für diesen Schritt gebraucht wird.
Ohne Router wird jeder Agent mit der Zeit teurer, langsamer und ungenauer.
Bei Research: Marktquellen, CRM und Website-Daten. Bei Entscheidung: Scores, Regeln und letzte Interaktionen. Bei Aktion: Tool-Schema, Berechtigungen und Freigabegrenzen. Bei Review: Logs, Quellen und Ergebnisvergleich. Was fast alle falsch machen Der größte Fehler ist Kontextmenge mit Kontextqualität zu verwechseln. Mehr Dokumente bedeuten nicht bessere Entscheidungen. Oft steigt nur die Chance, dass der Agent irrelevante Details übergewichtet.
Der zweite Fehler ist fehlende Aktualität. Ein Agent, der mit alten Preisen, alten Zuständigkeiten oder alten CRM-Stufen arbeitet, wird überzeugende, aber falsche Vorschläge machen. Kontext braucht deshalb Lebensdauer, Eigentümer und Update-Regeln.
Der dritte Fehler ist, Conversation History, Working Context und Persistent Memory zu vermischen. Ein langes Kontextfenster ist Arbeitsgedaechtnis, kein Governance-System. Wenn ein Modell an seine Kontextgrenze kommt, wird es nicht automatisch besser. Je nach Anbieter und Modell entstehen Kosten, Latenz, Validierungsfehler oder schlechte Gewichtung.
Darum braucht jeder Agent ein Kontextbudget:
Wer diese Fragen beantwortet, baut keinen laengeren Prompt. Er baut ein steuerbares Arbeitssystem.
Welche Informationen muessen immer sichtbar sein? Welche Informationen werden nur per Tool geholt? Welche Erinnerungen duerfen persistent bleiben? Welche alten Turns werden zusammengefasst? Welche Dokumente muessen strukturiert werden, bevor sie in den Kontext kommen? Welche Modellgrenze macht den Workflow unzuverlaessig? Der SYSTEMS-Blick Context Engineering ist der Punkt, an dem aus KI-Spielerei ein Business-System wird. Wenn ein Agent genau weiß, welche Daten er wann nutzt und wo seine Grenzen liegen, kann er echte Arbeit übernehmen.
Die richtige Frage lautet nicht: Wie viel Kontext können wir laden? Die bessere Frage lautet: Welche Kontextschicht braucht dieser Agent für diese Entscheidung, und wie prüfen wir, ob sie stimmt?
