Bitten Sie einen KI-Agenten um echte Arbeit, und etwas Vorhersehbares passiert. Der erste Entwurf kommt falsch zurück, nicht weil das Modell schwach ist, sondern weil es den einen Richtlinienabsatz, das aktuelle Preisblatt oder das Tonbeispiel nie gesehen hat, die die Antwort offensichtlich gemacht hätten. Die Lösung ist selten ein clevererer Prompt. Die Lösung ist besseres Context Engineering.
Context Engineering ist die Disziplin, die in ernsthaften Agententeams den Prompt-Kult abgelöst hat. Die Idee, 2025 popularisiert und 2026 Standardvokabular, ist einfach: Die Modellqualität ist für alle ungefähr gleich, also geht der Vorteil an den, der die beste Information rund um das Modell zusammenstellt. Anthropic beschreibt es als die Kuratierung des optimalen Satzes von Tokens während der Inferenz, einschließlich allem, was außerhalb des Prompts selbst im Fenster landet.
Dieser Beitrag erklärt, was Context Engineering ist, warum es zum lautesten Agententhema des Jahres wurde, wie es in der Praxis funktioniert, worin es sich von Prompt Engineering und vom Agentengedächtnis unterscheidet, und wie ein Team von Rollenagenten es ohne Forschungslabor einsetzt. Wenn Agenten, die auf Tools zugreifen, neu für Sie sind, lesen Sie parallel Was ist MCP für KI-Agenten?.
Context Engineering in einfacher Sprache
Context Engineering ist die Praxis, bewusst zu gestalten, was ein KI-Modell bei jedem Aufruf sieht, den es während der Arbeit für Sie ausführt.
Bei jeder Ausführung sieht das Modell ein Paket: die Systemanweisungen, die Anfrage des Nutzers, abgerufene Dokumente, Tool-Definitionen, den jüngsten Gesprächsverlauf und die Ergebnisse früherer Tool-Aufrufe. Dieses Paket ist der Kontext. Es zu gestalten bedeutet, bewusst zu entscheiden:
- Welche Anweisungen und Regeln immer präsent sind und welche nur bei bestimmten Aufgaben erscheinen
- Welche Fakten aus Ihrer Wissensbasis abgerufen werden, in welcher Reihenfolge, mit welchen Aktualitätsprüfungen
- Welche Tools der Agent in diesem Schritt sieht und wie ihre Beschreibungen formuliert sind
- Was mit langen Verläufen geschieht: was zusammengefasst wird, was wörtlich bleibt, was entfällt
- Wie die Ausgabe aussehen muss, damit der nächste Schritt oder der nächste Agent sie verwenden kann
Der mentale Wechsel führt vom Schreiben einer Anfrage zum Bau einer Pipeline. Ein Prompt ist ein Satz. Kontext ist die ganze Fabrik, die diesen Satz und alles darum herum produziert, bei jedem Aufruf, in einer Schleife, die fünfzig Schritte laufen kann, bevor ein Mensch etwas sieht.
Ein Support-Agent, der eine Abrechnungsfrage beantworten soll, zeigt den Unterschied. Ein naiver Aufbau gibt dem Modell die Frage plus einen riesigen Dokumentenberg. Ein kontextgestalteter Aufbau gibt ihm die Frage, den aktuellen Tarifdatensatz des Kunden, die zwei zutreffenden Abschnitte der Erstattungsrichtlinie, einen kurzen Stilleitfaden, drei relevante frühere Tickets und genau vier Tools: nachschlagen, entwerfen, eskalieren, protokollieren. Der zweite Agent ist nicht klüger. Er wird besser gefüttert.
Warum Context Engineering 2026 so laut ist
Mehrere Kräfte kamen zusammen, um den Kontext zum Thema zu machen, über das alle von Salesforce bis Sourcegraph bis Neo4j dieses Jahr Leitfäden schreiben.
1. Modelle haben den schweren Teil zur Ware gemacht. Frontier-Modelle sind alle gut genug, sodass Formulierungstricks Teams nicht mehr unterscheiden. Was sie unterscheidet, ist die Informationsarchitektur rund um das Modell: welche Quellen aktuell sind, was wann abgerufen wird, wie viel in einen Durchgang passt. Branchentrendberichte für 2026 listen Context Engineering als direkten Nachfolger des Prompt Engineering, und die Berufsbezeichnung „Context Engineer" taucht in Plattformteams auf.
2. Agenten laufen in langen Schleifen. Ein Chatbot antwortet in einem Durchgang. Ein Agent arbeitet in einer Schleife, ruft Tools auf, sammelt Zustand und trifft seine Entscheidung in Schritt 47, während die Reste der Schritte 1 bis 46 noch im Fenster sind. Das Token-Budget ist endlich, und die Aufmerksamkeit lässt nach, wenn das Fenster vollgestopft ist. Die meisten Produktionsfehler lassen sich darauf zurückführen, wie dieses Budget ausgegeben wurde, nicht auf einen schlechten Einstiegsprompt.
3. Größere Fenster haben das Problem nicht beendet. Fenster mit einer Million Tokens haben die Architektur verändert, aber nicht die Physik. Alles hineinzukippen verwässert weiterhin das Signal, erhöht die Kosten pro Aufruf und verlangsamt jeden Schritt. Teams haben gelernt, dass Abrufqualität die Fenstergröße schlägt, dieselbe Lektion, die Suchmaschinen eine Generation zuvor erteilt haben.
4. Multi-Agenten-Systeme haben es strukturell gemacht. Wenn ein Orchestrator Arbeit an spezialisierte Sub-Agenten übergibt, ist jede Übergabe eine Kontextentscheidung: was der Sub-Agent wissen muss und was seinen Fokus nur vergiften würde. Multi-Agenten-Systeme sind Context Engineering mit Organigramm.
Nichts davon ist abstrakt. Die Symptome sind alltäglich: Agenten, die die Preise vom letzten Quartal zitieren, Entwürfe in der falschen Markenstimme, Support-Bots, die gelöste Tickets wieder aufrollen, Coding-Agenten, die viertausend Treffer lesen und den eigentlichen Bug übersehen.
Wie Context Engineering in der Praxis funktioniert
Ein funktionierender Aufbau hat fünf bewegliche Teile. Sie lassen sich in jedem Stack umsetzen.
1. Geschichtete Anweisungen
Stabile Regeln leben oben: Rolle, Zielgruppe, Ton, harte Einschränkungen. Aufgabenspezifische Regeln laden nur, wenn sie relevant sind. Ein Content-Writer-Agent hält Stimm- und Formatregeln permanent, lädt die SEO-Checkliste aber nur für Blogartikel. So bleibt die immer aktive Schicht klein und scharf statt einer Textwand, die das Modell nur überfliegt.
2. Abruf mit Absicht
Abruf ist nicht „das Wiki anhängen". Es ist eine pro Schritt entworfene Abfrage: der aktuelle Datensatz des Kunden, die zwei zutreffenden Richtlinienabschnitte, die frischeste Preisliste. Gute Pipelines filtern nach Datum, deduplizieren und ranken nach Relevanz für die tatsächliche Frage. Das Ziel ist der kleinste Satz hochrelevanter Fakten, nicht das vollständigste Archiv.
3. Tool-Kuratierung und -Beschreibung
Jede Tool-Definition verbraucht Fenster und Aufmerksamkeit. Bieten Sie fünf relevante Tools an, nicht fünfzig. Schreiben Sie Tool-Beschreibungen als Gebrauchsanweisungen: wann aufrufen, was es kostet, was es zurückgibt, was es niemals tun darf. Das überschneidet sich mit MCP-Denken: Das Protokoll standardisiert die Verbindung, aber Context Engineering entscheidet, was jeder Agent tatsächlich sieht.
4. Verlaufsmanagement
Lange Sitzungen brauchen Verdichtung: ältere Schritte zusammengefasst, jüngste Schritte wörtlich, Entscheidungen als strukturierte Notizen extrahiert. Wenn ein Gespräch eine Phasengrenze überschreitet, etwa von Recherche zu Entwurf, sollte der Kontext neu gepackt werden, nicht nur verlängert. Hier dockt das Agentengedächtnis an: Das Gedächtnis speichert, der Kontext wählt aus.
5. Ausgabeverträge
Die Ausgabe jedes Schritts sollte für ihren Empfänger geformt sein: strukturierte Felder für das nächste Tool, ein sauberes Briefing für den nächsten Agenten, ein prüfbares Paket für den Menschen. Ausgabeverträge sind Context Engineering für die Zukunft, denn jede Ausgabe wird zur Eingabe von jemand anderem.
Context Engineering vs. Prompt Engineering vs. Agentengedächtnis
Diese drei werden ständig vermischt. Es sind verschiedene Schichten desselben Systems.
| Dimension | Prompt Engineering | Context Engineering | Agentengedächtnis |
|---|---|---|---|
| Kernfrage | Wie formuliere ich diese Anfrage? | Was soll das Modell in jedem Schritt sehen? | Was soll zwischen Sitzungen bestehen bleiben? |
| Umfang | Ein Aufruf | Die ganze Schleife, jeder Aufruf | Über Aufrufe und Sitzungen hinweg |
| Typische Arbeit | Formulierung, Beispiele, Formathinweise | Abruf, Tool-Kuratierung, Verdichtung, Reihenfolge | Speicherung, Erinnerung, Vergessen, Teamwissen |
| Fehlermodus | Vage oder widersprüchliche Formulierung | Rauschen, fehlende Fakten, aufgeblähte Fenster | Veraltete Fakten, Datenschutzlecks, keine Persistenz |
| Verantwortlich | Wer die Anfrage schreibt | Agentenbauer oder Plattformteam | Plattform plus Governance |
Das deutlichste Zeichen: Wenn Ihre Verbesserungen aus Umformulieren kommen, betreiben Sie Prompt Engineering. Kommen sie aus der Neuverdrahtung dessen, was in welcher Reihenfolge einfließt und was entfernt wird, betreiben Sie Context Engineering. Kommen sie aus der Entscheidung, was morgen überlebt, arbeiten Sie am Gedächtnis. Produktionsteams machen alle drei, aber Context Engineering bietet derzeit die meiste Hebelwirkung.
Wann Context Engineering hilft und wann es übertrieben ist
Den Aufwand wert:
- Agenten in mehrstufigen Schleifen mit Tool-Aufrufen, bei denen sich Rauschen über Schritte summiert
- Teams, die Agenten teilen, bei denen der abgestimmte Kontext einer Person allen zugutekommt
- Regulierte oder markensensible Ausgaben, bei denen der richtige Richtlinienabsatz präsent sein muss
- Kostenempfindliche Workloads, bei denen das Beschneiden des Fensters die Rechnung bei jedem Aufruf senkt (siehe wie Sie weniger für KI-Agenten zahlen)
- Jeder Agent, dessen Fehler wie „es wusste es nicht" aussehen statt wie „es konnte nicht denken"
Wahrscheinlich übertrieben:
- Einmalige Fragen an einen Chatbot, bei denen ein klarer Satz genügt
- Prototyp-Spikes, um zu testen, ob ein Workflow die Automatisierung überhaupt lohnt
- Aufgaben mit kleinen, stabilen Eingaben, etwa das Umformatieren eines festen Dokumenttyps
Eine nützliche Faustregel: Je länger die Schleife und je mehr Menschen vom Ergebnis abhängen, desto mehr zahlt sich Context Engineering aus. Je kürzer die Aufgabe und je wegwerfbarer das Ergebnis, desto mehr ist es Zeremonie.
Menschliche Freigabe und Wirkungsradius
Kontextgestaltung ist auch eine Sicherheitsfläche. Was der Agent sieht, formt, was er tut, und was er tut, reicht von harmlosen Entwürfen bis zu unumkehrbaren Zahlungen.
Gestalten Sie Kontext nach Risikostufe, nicht nach Bequemlichkeit. Schritte mit niedrigem Risiko wie Entwerfen und Zusammenfassen können auf reichem, breitem Kontext laufen. Schritte mit großer Wirkung wie Erstattungen, Löschungen und externe Sendungen verdienen minimalen, verifizierten Kontext plus einen menschlichen Kontrollpunkt. Das Paket, das der Mensch prüft, ist selbst ein Context-Engineering-Artefakt: klein, aktuell und vollständig genug, um zu entscheiden.
Das ist der praktische Kern von Human-in-the-Loop-KI-Agenten: Der Mensch liest nicht die ganze Welt nach, weil die Pipeline bereits die drei relevanten Fakten kuratiert hat. Kombinieren Sie risikogestuften Kontext mit begrenzten Tool-Berechtigungen, und Agentensicherheit hört auf, ein separates Audit zu sein, und wird Teil desselben Design-Durchgangs.
Team-Muster: Wem gehört der Kontext
In gesunden Teams wird Kontext wie Code verwaltet, nicht wie Folklore. Vier Muster kehren wieder.
Rollenagenten mit abgegrenztem Kontext. Jede Rolle erhält ihre eigene Anweisungsschicht und ihren eigenen Tool-Satz. Ein Support-Lead-Agent sieht Textbausteine, Richtlinien und Ticketverlauf. Ein Sales-Lead-Agent sieht aktuelle Preise, Battlecards und CRM-Datensätze. Niemand pflegt einen Mega-Prompt, der beides sein will, was direkt damit zusammenhängt, warum vertikale KI-Agenten Generalisten schlagen: Enge Rollen ermöglichen engen, hochrelevanten Kontext.
Eine gemeinsame Wissensschicht. Produktfakten, Richtlinien und Stilleitfäden leben an einem gepflegten Ort, versioniert und datiert, sodass jeder Agent dieselbe aktuelle Wahrheit abruft. Wenn sich die Preisseite ändert, pflanzt sich eine Aktualisierung zu allen Rollen fort.
Kontext-Reviews im Release-Zyklus. Wenn ein Agent danebenliegt, lautet die erste Frage „was hat er gesehen?" und nicht „welches Modell war das?". Teams prüfen Traces wie Code-Diffs, eine Gewohnheit, die natürlich zu Agenten-Observability passt.
Vorlagen für Neueinstellungen, menschlich und KI. Ein neuer Senior-Developer-Agent erbt die Repo-Karte, Coding-Standards und Review-Checkliste als Kontext, so wie eine menschliche Neueinstellung Onboarding-Dokumente erbt. Ein Agenten-Onboarding ist Context Engineering mit Deadline.
Ein Plan für diese Woche
Sie brauchen kein Plattformteam, um anzufangen. Fünf Schritte, der Reihe nach:
- Wählen Sie einen nervigen Workflow. Den, bei dem der Agent „fast" funktioniert: ein Wochenbericht, ein Ticket-Triage, ein erstes Briefing. Kleiner Wirkungsradius, hohe Wiederholung.
- Schreiben Sie auf, was das Modell sehen sollte. Listen Sie für einen echten Lauf die fünf bis zehn Fakten oder Dokumente, die die Ausgabe richtig gemacht hätten. Diese Liste ist Ihre Kontextspezifikation, und sie ist meist kürzer als befürchtet.
- Kürzen Sie die Tool-Liste. Entfernen Sie jedes Tool, das der Agent in den letzten zehn Läufen nicht benutzt hat. Schreiben Sie die Beschreibungen der Überlebenden als Gebrauchsanweisungen neu, nicht als API-Etiketten.
- Fügen Sie eine Aktualitätsregel hinzu. Daten auf abgerufenen Dokumenten oder ein Feld „Stand:" im Datensatz. Veralteter Kontext richtet mehr Schaden an als fehlender Kontext, weil er selbstsicher wirkt.
- Fügen Sie einen Kontrollpunkt hinzu. Verlangen Sie für den unumkehrbarsten Schritt eine menschliche Freigabe mit einem kuratierten Prüfpaket. Messen Sie nichts Kompliziertes: Zählen Sie, wie oft der Kontrollpunkt ein echtes Problem abgefangen hat.
Lassen Sie den Workflow eine Woche laufen und überarbeiten Sie dann die Kontextspezifikation. Die zweite Iteration ist der Punkt, an dem sich die Gewinne verzinsen, weil Sie jetzt wissen, welche abgerufenen Fakten tatsächlich genutzt wurden.
Wo Upchat ins Spiel kommt
Context Engineering belohnt genau das, wofür Upchat gebaut ist: spezialisierte Rollen, abgegrenzte Tools und gemeinsamen Team-Besitz.
Auf Upchat erstellen Sie Rollenagenten mit eigenen Anweisungen und eigenem Wissen, verbinden nur die Tools, die jede Rolle braucht, und halten menschliche Freigaben bei den Schritten fest, bei denen ein Fehler wehtun würde. Weil Agenten in der Cloud als geteilte Team-Assets leben, profitiert am Dienstag jeder Teamkollege von der Kontextgestaltung, die Sie am Montag abgestimmt haben, statt dass sie im privaten Chatverlauf einer einzelnen Person gefangen bleibt. Und weil Rollen eng bleiben, bleibt der Kontext jedes Agenten klein, aktuell und hochrelevant, und genau darum geht es.
Wenn Sie den obigen Plan ausprobieren möchten, ohne zuerst Infrastruktur zusammenzubauen, melden Sie sich bei Upchat an und bauen Sie Ihren ersten Rollenagenten um einen einzigen Workflow: abgegrenzte Anweisungen, eine Handvoll Tools, ein Freigabepunkt. Das ist Context Engineering, das Sie diese Woche ausliefern können.
Das Fazit
Context Engineering ist die Erkenntnis, dass Agenten an Eingaben scheitern, nicht an Intelligenz. Das Modell ist geteilte Infrastruktur; der Kontext ist Ihr privater Vorteil. Teams, die Anweisungen, Abruf, Tools, Verlauf und Ausgaben als ein gestaltetes System behandeln, bekommen Agenten, die aktuelle Fakten zitieren, im Ton bleiben und das Vertrauen von Prüfern gewinnen. Teams, die weiter längere Prompts schreiben, ernten längere Enttäuschungen.
Fangen Sie klein an: ein Workflow, eine Kontextspezifikation, ein Kontrollpunkt. Wachsen Sie dann von einem einzigen abgestimmten Agenten zu einer koordinierten Bank von Rollenagenten, aufbauend auf dem, was ein Multi-Agenten-System hinzufügt, mit dem Agentengedächtnis, das Wissen über Sitzungen trägt, und der Human-in-the-Loop-Freigabe, die die wichtigen Schritte bewacht. Die Prompt-Ära fragte: „Wie formuliere ich das?" Die Kontext-Ära stellt eine bessere Frage: „Was soll das Modell sehen?"