Context Engineering: Leitfaden für die tägliche Arbeit mit KI-Modellen

In Teil 1 haben wir das Konzept hinter Context Engineering kennengelernt: warum es wichtig ist, wie KI-Modelle Kontext verarbeiten und wo die technischen Grenzen liegen. In Teil 2 zeigen wir, wie sich Context-Engineering im Alltag umsetzen lässt, zunächst im klassischen Chat, dann in agentischen Coding-Werkzeugen. Dabei zieht sich die bereits in Teil 1 eingeführte Grundunterscheidung durch alle Tipps: Das Briefing (stabile Hintergrundinformationen wie Unternehmensprofil, Tonalität, Formatvorgaben) bleibt über viele Chats hinweg gleich. Die Arbeitsunterlagen (das Material für den aktuellen Schritt, etwa eine Ausschreibung oder Gesprächsnotizen) wechseln von Aufgabe zu Aufgabe. Die Aufgabe selbst formulierst du jedes Mal neu. Wer diese drei Ebenen des Prompts bewusst trennt, vermeidet das zentrale Problem wachsender Kontextfenster: Wichtiges wird von Unwichtigem überlagert, das Modell verliert Orientierung und die Qualität sinkt. Die Lösung besteht darin, das Briefing bewusst zu pflegen und Arbeitsunterlagen nur dann einzuspeisen, wenn sie für den aktuellen Schritt wirklich nötig sind. Je nach verwendetem Werkzeug kann das manuell oder automatisiert passieren: Wer lediglich iterativ chattet, übernimmt das meiste selbst, wer agentische Werkzeuge oder Funktionen wie CustomGPTs nutzt, kann einige Schritte vereinfachen. Wie das konkret aussieht, zeigen die folgenden Praxistipps. Ergebnisse prüfen: Testen und Evaluieren Wie bei allen Ansätzen, zeigt sich auch die Qualität einer Context-Engineering-Strategie erst in den Ergebnissen. Es lohnt sich deshalb, die eigene Arbeitsweise regelmäßig zu hinterfragen: Führt ein schlankerer Kontext zu besseren Antworten? Hilft die Trennung in Arbeitsschritte tatsächlich? Ein einfacher Ansatz: Führe dieselbe Aufgabe einmal mit deiner üblichen Methode und einmal mit einer veränderten Kontextkonfiguration durch – etwa weniger Material im ersten Schritt oder ein stärker verdichtetes Briefing. Vergleiche die Ergebnisse nach Relevanz, Genauigkeit und Tonalität. Über mehrere solcher Vergleiche entwickelst du ein Gespür dafür, wie viel Kontext für deinen Anwendungsfall optimal ist. Für agentische Werkzeuge gilt das analog: Teste, ob eine kleinere Briefing-Datei, andere Regelaufteilungen oder engere Agenten-Loops zu besseren Ergebnissen führen. Systematisches Ausprobieren ersetzt hier das Bauchgefühl. Praxistipps für Wissensarbeiter im klassischen Chat Dieser Abschnitt richtet sich an alle, die mit Chat-Interfaces wie ChatGPT, Claude oder vergleichbaren Produkten arbeiten. Das Briefing als stabilen Startpunkt nutzen Statt mit jeder Nachricht komplett von vorn zu beginnen, ist es sinnvoll, einen stabilen Briefing-Block am Anfang einer Arbeitssession zu erstellen und das Modell damit zu prompten. Dieser Block enthält die unveränderlichen Eckpunkte: Unternehmensprofil, Tonalität, Formatvorgaben, Einschränkungen. Die Aufgabe, etwa eine PR-Mitteilung oder ein Kundenangebot zu schreiben, ist davon losgelöst. Beide sind aber Teil des finalen Prompts – ebenso wie die weiteren Arbeitsunterlagen. Alles fließt am Ende zusammen in den Kontext des Modells. In unserem Beispiel aus Teil 1, bei dem ein Team regelmäßig Kundenangebote schreibt, sah das Briefing so aus: Unternehmen: [Name, Kurzprofil] Leistungsportfolio: Cloud-Migration, Managed Services, Security Audits Preisstruktur: Tagessätze nach Seniorität, Paketpreise ab Projektvolumen 20.000 € Tonalität: Verbindlich, lösungsorientiert, kein Fachjargon ohne Erklärung Formatvorgaben: Maximal 8 Seiten, Executive Summary auf Seite 1, Preistabelle als letzter Abschnitt Einschränkungen: Keine Rabatte ohne Rücksprache. Keine Zusagen zu Timelines unter 4 Wochen. Viele Plattformen bieten inzwischen persistente Kontextbereiche an, die sich jedoch in Funktion und Einsatzzweck deutlich unterscheiden: Custom Instructions eignen sich dafür, grundlegende Briefing-Informationen – etwa Rolle, Tonalität oder wiederkehrende Regeln – dauerhaft zu hinterlegen, statt sie manuell in jeden neuen Chat kopieren zu müssen. Projekte setzen eine Ebene höher an: Sie bündeln auch Arbeitsmaterialien wie Dokumente, Daten oder Referenztexte in einem gemeinsamen Kontext. Das ist sinnvoll, wenn über längere Zeit mit denselben Quellen gearbeitet wird und sich nur die Aufgaben ändern. CustomGPTs kombinieren Briefing und Arbeitsunterlagen in einer eigenständigen, konfigurierbaren Einheit – und können über ihre Instruktionen sogar die Aufgaben-Ebene vorstrukturieren, etwa durch vordefinierte Abläufe oder Rückfragen. Ihr entscheidender Zusatznutzen liegt in der Teilbarkeit: Ein einmal sorgfältig konstruierter Kontext lässt sich an andere Personen weitergeben, ohne dass diese das zugrundeliegende Context Engineering selbst nachbauen müssen. Wie oft du das Briefing aktualisierst, hängt vom Anwendungsfall ab. Bei Kundenangeboten reicht vielleicht eine quartalsweise Aktualisierung, während in Multi-Agenten-Systemen das Briefing auch nach jedem Arbeitsschritt automatisch aktualisiert wird. Während das Briefing also mehr oder weniger stabil bleibt, wechseln die Arbeitsunterlagen bei jeder Aufgabe. Arbeitsunterlagen kontrolliert einspeisen Ein häufiger Fehler ist, "zur Sicherheit" alles Verfügbare in den Kontext zu kippen. Zu viel Material auf einmal führt dazu, dass Wichtiges in der Masse untergeht und Kontextverfall zum Problem wird. Das Grundprinzip lautet: So wenig wie möglich, so viel wie nötig. Neben der Qualität spielt auch die Wirtschaftlichkeit eine Rolle: Mehr Kontext bedeutet mehr Token, und mehr Token bedeuten höhere Kosten und langsamere Antworten. Gerade im professionellen Einsatz summiert sich das. Die Technik dafür heißt Progressive Disclosure. Der Begriff stammt aus dem Interface-Design und lässt sich auf die Arbeit mit KI übertragen. Pro Arbeitsschritt gibst du nur das, was für den nächsten Schritt wirklich relevant ist. Im Beispiel mit den Kundenangeboten bedeutet das: Ein typisches Angebotspaket besteht aus der Ausschreibung (20–40 Seiten), den Gesprächsnotizen aus zwei Vorgesprächen, einer internen Preistabelle und dem bestehenden Briefing-Block. Wer das alles auf einmal in den Kontext lädt, riskiert, dass das Modell die falschen Schwerpunkte setzt, etwa die Preistabelle zu früh optimiert, bevor überhaupt klar ist, welche Leistungen der Kunde wirklich benötigt. Stattdessen arbeitest du in Stufen: Stufe 1, Kernanforderungen: Du startest mit dem Briefing-Block und den zwei, drei Seiten der Ausschreibung, die die Kernanforderungen beschreiben. Prompt: Hier ist unser Briefing [eingefügt] und der Anforderungsteil der Ausschreibung von Kunde X [eingefügt]. Erstelle eine Angebotsgliederung, die alle genannten Anforderungen adressiert. Noch kein Fließtext. Stufe 2, Kundenperspektive: Das Modell hat eine Gliederung erstellt. Erst jetzt reichst du die Gesprächsnotizen nach. So kann das Modell konkrete Kundenzitate und implizite Erwartungen gezielt einbauen, ohne davon zu Beginn abgelenkt zu werden. Prompt: Hier sind die Gesprächsnotizen aus zwei Vorgesprächen [eingefügt]. Ergänze die Gliederung um Punkte, die der Kunde mündlich betont hat, aber die nicht in der Ausschreibung stehen. Stufe 3, Preisgestaltung: Die Preistabelle kommt zuletzt, wenn klar ist, welche Leistungsmodule tatsächlich relevant sind. Prompt: Hier ist unsere interne Preistabelle [eingefügt]. Erstelle auf Basis der finalen Gliederung den Preisabschnitt. Beachte: Keine Rabatte ohne Rücksprache, keine Timelines unter 4 Wochen. So bleibt das Kontextfenster in jeder Phase auf das Wesentliche fokussiert. Das Modell trifft keine Annahmen, die es ohne ausreichenden Kontext noch gar nicht treffen sollte. Große Dokumente wie lange Verträge oder umfangreiche Anforderungskataloge solltest du auf die wirklich relevanten Abschnitte kürzen oder separat in einem eigenen Chat verarbeiten. Das gilt auch für multimodale Inhalte: Wenn du mit Bildern, PDFs oder Audiotranskripten arbeitest, lade sie nur in den Chat, in dem sie tatsächlich gebraucht werden, und nicht pauschal "auf Vorrat". Für API-Nutzer relevant: Ein Screenshot verbraucht oft ein Vielfaches der Token im Vergleich zum extrahierten Text. Je nach Bildgröße und Modell kann der Verbrauch das Fünf- bis Fünfzehnfache betragen (OpenAI-Dokumentation: Calculating image token costs). Bilder sind also deutlich teurer. Arbeit in Phasen: Recherche, Planung und Ausführung Ein Arbeitsmuster, das für jede Wissensarbeit funktionieren kann: Recherchieren, planen, implementieren. Die Phasen helfen, Briefing und Arbeitsunterlagen sauber getrennt zu halten, und verhindern, dass das Modell falsch "abbiegt", sobald der Kontext wächst. In der Recherchephase klärst du die Grundlagen. Du lässt das Modell Rückfragen stellen, Annahmen explizit machen und fehlende Informationen benennen. Prompt: Hier ist die Ausschreibung von Kunde X [eingefügt]. Bevor du etwas schreibst: Welche Informationen fehlen dir, um ein belastbares Angebot zu erstellen? Was ist die Kernherausforderung des Kunden? Welche Anforderungen sind unklar? Liste alles als Fragen auf. Hier stabilisierst du das Briefing, indem du fehlende Informationen identifizierst und Annahmen klärst. In der Planungsphase lässt du dir eine Struktur vorschlagen, bevor Output entsteht, also etwa die Gliederung des Angebots, eine Liste der zu adressierenden Kundenanforderungen oder eine Übersicht der relevanten Leistungsmodule. Prompt: Erstelle auf Basis der geklärten Anforderungen eine Gliederung für das Angebot. Markiere bei jedem Punkt, welche Anforderung aus der Ausschreibung er adressiert. Noch kein Fließtext. Der Plan macht sichtbar, wie das Modell die Aufgabe versteht, und gibt dir die Möglichkeit zur Korrektur, bevor Arbeit entsteht. In der Ausführungsphase wird der Plan abgearbeitet. Nach jedem größeren Abschnitt baust du einen kurzen Check ein: Prompt: Prüfe den bisherigen Entwurf gegen die Ausschreibung: Welche Anforderungen sind noch nicht adressiert? Stimmen Tonalität und Formatvorgaben aus dem Briefing? Welche Annahmen hast du getroffen, etwa zu Timelines oder Preisen? Das Briefing aktuell halten: Snapshots und Verdichtung Je länger eine Arbeitssession dauert, desto mehr füllt sich das Kontextfenster mit Historie, Fehlversuchen, Zwischenständen und Korrekturen. Ab einer gewissen Kontextgröße sinkt die Zuverlässigkeit, weil das Modell zu viele Informationen gleichzeitig beachten muss. Die Lösung ist gezielte Verdichtung: Du lässt dir regelmäßig einen kompakten Arbeitsstand erzeugen und startest damit in einem neuen Chat. Praktisch heißt das: Prompt: Fasse unseren bisherigen Stand in maximal 300 Wörtern zusammen. Nenne Ziel, gesicherte Fakten, getroffene Entscheidungen, offene Fragen und den nächsten Schritt. Lass alles weg, was nur Diskussion oder Fehlversuche war. Dieser Snapshot wird dein neues Briefing. Lies ihn aber durch, bevor du weitermachst. Die leistungsfähigsten Modelle verdichten meist zuverlässig, können jedoch Prioritäten falsch gewichten, eine Entscheidung als offen markieren, die längst getroffen ist, oder eine Nuance weglassen, die dir wichtig ist. Je komplexer das Projekt, desto mehr gesicherte Fakten, Entscheidungen und Abhängigkeiten müssen darin stehen. In der Praxis ist er daher oft umfangreicher als das folgende Minimalbeispiel. Das Beispiel zeigt die Struktur: Ziel: Angebot für Kunde XY, Cloud-Migration, max. 8 Seiten, verbindlich-lösungsorientiert. Gesichert: Projektvolumen ca. 80.000 €, Laufzeit 6 Monate, Ansprechpartner IT-Leiter, Entscheidung bis 15.04. Entschieden: Aufhänger ist Betriebskostensenkung, kein Vergleich mit Mitbewerbern, Executive Summary auf Seite 1. Offen: Genaue Anzahl der zu migrierenden Server (wartet auf Rückmeldung vom Kunden). Nächster Schritt: Entwurf der Executive Summary mit Aufhänger Betriebskostensenkung. Wichtig: Die Rohdaten, also den bisherigen Chatverlauf, frühere Entwürfe und verworfene Ansätze, behältst du extern griffbereit, falls du später darauf zurückgreifen musst. Notizprogramme wie Obsidian, Apple Notes oder Word eignen sich dafür gut. Bei jeder Komprimierung gehen Informationen verloren, die später vielleicht noch einmal relevant sind. Im aktiven Arbeitskontext stehen nur noch der verdichtete Snapshot plus das Material für den nächsten Schritt. Während der laufenden Arbeit helfen explizite Markierungen im Chat: Wenn du Korrekturen machst, sag "Diese Annahme gilt nicht mehr, weil…" oder "Ersetzt durch…". Das verhindert, dass das Modell auf veraltete Aussagen im bisherigen Verlauf zurückgreift. Für Projekte, die sich über Tage oder Wochen erstrecken, etwa ein komplexes Angebot, das mehrere Abstimmungsrunden durchläuft, funktioniert rollierende Verdichtung: Aktuelle Informationen bleiben detailliert, ältere werden zunehmend verdichtet. Du pflegst ein kurzes "Lebendes Briefing", das du nach jeder wesentlichen Kundenrückmeldung oder Angebotsaktualisierung neu abgleichst. Exkurs: RAG und MCP – wenn das System den Kontext auswählt Retrieval-Augmented Generation (RAG, abrufgestützte Textgenerierung) ist die derzeit verbreitetste Technik, um KI-Modellen automatisch relevanten Kontext bereitzustellen. Bevor das Modell antwortet, durchsucht ein vorgeschaltetes System eine Dokumentensammlung und fügt die relevantesten Passagen in den Kontext ein. In der Praxis begegnet RAG vielen bereits: Microsoft Copilot durchsucht SharePoint-Dokumente. Custom-GPTs greifen auf hochgeladene Dateien zurück. Unternehmensinterne Chatbots durchsuchen Wissensdatenbanken. Aus Context-Engineering-Sicht verschiebt RAG eine Aufgabe: Statt selbst Arbeitsunterlagen auszuwählen, übernimmt ein Retrieval-System die Auswahl. Das spart Aufwand, erzeugt aber neue Risiken. Wenn das Retrieval-System die falschen Passagen auswählt, arbeitet das Modell mit irrelevantem oder widersprüchlichem Kontext. Die Qualität hängt dann weniger am Prompt als an der Dokumentensammlung und der Suchlogik. Für den Arbeitsalltag heißt das: Die Dokumentenbasis muss gepflegt werden mit regelmäßiger Prüfung auf Aktualität, Widerspruchsfreiheit und Redundanz. Veraltete, widersprüchliche oder redundante Dokumente in der Wissensdatenbank führen zu denselben Problemen wie ein überladenes Kontextfenster. Große Datenbanken sollten zudem vorgefiltert werden, um die Chancen auf ein besseres RAG-Ergebnis zu verbessern. In der Praxis könnten das etwa Filter nach Zeitraum oder Kunden sein. In eine ähnliche Richtung geht das Model Context Protocol (MCP), ein offener Standard, der es KI-Modellen ermöglicht, strukturiert auf externe Datenquellen und Werkzeuge zuzugreifen. Während RAG typischerweise Textpassagen aus Dokumenten bereitstellt, kann MCP auch Live-Daten, APIs oder Datenbankabfragen als Kontext einbinden. Die Context-Engineering-Prinzipien bleiben dieselben: Auch bei MCP entscheidet die Qualität und Relevanz des bereitgestellten Kontexts über die Qualität der Ergebnisse. Fehler und Korrekturen Ein unterschätztes Problem ist die Behandlung von Fehlern und Korrekturen. Der natürliche Reflex ist, bei Problemen "alles nochmal plus extra Details" zu schicken. Fehlerhistorie im Kontext kann das Modell jedoch in schlechte Muster "locken" und die Richtung, die das Gespräch einschlägt, negativ prägen. Oft ist der wirksamste Schritt in solchen Fällen, einen neuen Chat zu starten und mit einem frischen Snapshot plus korrigiertem Material weiterzuarbeiten. Wenn du im selben Chat bleiben willst, hilft eine Richtungskorrektur: Du korrigierst neutral, präzise und mit Ersatzvorgabe. Statt vager Kritik formulierst du eine klare Korrektur: Statt: Das ist falsch, mach nochmal. Besser: Diese Annahme war falsch: [X]. Die korrekte Information ist: [Y]. Ignoriere ab jetzt [Z]. Liefere den Abschnitt neu im Format [Format]. Damit gibst du dem Modell eine saubere Basis für den nächsten Versuch, statt die Fehlerkette fortzuschreiben. Nach behobenen Fehlern kannst du zusätzlich versuchen, die korrekte Ausgabe für das Modell stärker zu markieren, etwa indem du explizit sagst: Der vorherige Fehler ist erledigt. Aktueller Stand ist: [Stand]. Nächster Schritt: [Schritt]. Das kann verhindern, dass das Modell weiter auf ein Problem reagiert, das nicht mehr existiert. Wir empfehlen jedoch grundsätzlich, bei Fehlern neu zu starten. Prompt-Hygiene: Wenige, klare Regeln Eine aktuelle Studie (Jaroslawicz et al., "How Many Instructions Can LLMs Follow at Once?", 2025) zeigt, dass selbst die besten Frontier-Modelle bei 500 gleichzeitigen Regeln im Prompt nur noch 68 Prozent Genauigkeit erreichen. Bereits im Bereich von 150 bis 200 Regeln zeigen sich laut den Detailergebnissen der Studie deutliche Leistungseinbrüche, wobei Modelle dazu tendieren, früheren Regeln zu folgen und spätere zunehmend zu ignorieren. Die praktische Konsequenz: Formuliere lieber fünf wirklich zentrale Regeln statt fünfzig "Always/Never"-Sätze. Vermeide es auch, Regeln in Großbuchstaben zu schreiben, um Wichtigkeit zu signalisieren. Wenn alles "wichtig" markiert ist, sticht nichts mehr heraus und das Modell kann keine Prioritäten setzen. Neben der Anzahl der Regeln spielt auch deren Struktur eine Rolle. Klare Trennungen innerhalb des Kontexts helfen dem Modell, verschiedene Informationsblöcke auseinanderzuhalten. In der Praxis bewährt sich, Briefing, Arbeitsunterlagen und Aufgabe durch Überschriften, Trennlinien oder explizite Markierungen (etwa XML-Tags wie , , oder Markdown-Überschriften) voneinander abzugrenzen. So erkennt das Modell sofort, welcher Teil des Kontexts welche Funktion hat. Wenn du merkst, dass du ständig neue Regeln hinzufügst, benötigst du wahrscheinlich ein besseres Arbeitsformat: Phasen, Checklisten, strukturierte Inputs. Praxistipps für agentische KI-Werkzeuge Laut Microsoft "verstärkt sich in Multi-Agenten-Systemen jede Verbesserung der Kontextqualität: Selbst kleine Gewinne eines einzelnen Agenten wirken sich erheblich aus, wenn die Zahl der Agenten steigt". Dieser Abschnitt richtet sich an Nutzer agentischer Coding-Werkzeuge, also Tools, bei denen die KI eigenständig Dateien liest, Befehle ausführt und in Schleifen arbeitet (Claude Code, OpenAIs Codex, Cursor, GitHub Copilot, Gemini CLI u. a.). Die Grundkonzepte sind in allen Tools gleich: eine zentrale Konfigurationsdatei für das Projekt (Briefing), Anweisungen, die je nach Aufgabe automatisch geladen werden (Arbeitsunterlagen), und automatische Prüfungen, die Fehler abfangen. Die folgenden Beispiele zeigen die Prinzipien am Beispiel von Claude Code, weil es ausführlich dokumentiert ist. Wo relevant, verweisen wir auf die Entsprechungen in anderen Tools. Der zentrale Unterschied zum klassischen Chat: Der Kontext besteht nicht nur aus deinem Text, sondern auch aus Daten, die im Arbeitsverlauf entstehen (z. B. die Ergebnisse eines Werkzeugs oder Fehlermeldungen von Tests). Damit wächst das Potenzial für Kontextprobleme, aber auch der Hebel für systematisches Context-Engineering. Das Problem verstehen: Automatische Kontextzufuhr Agentische Coding-Tools ziehen automatisch Kontext in ihre Prompts: Das Modell liest Dateien, führt Befehle aus, sammelt Ergebnisse und baut daraus seinen Arbeitskontext. Das passiert weitgehend automatisch und verbraucht Zeit und Tokens. Die Konsequenz: Wenn ein solches Tool ungewollte Änderungen macht, liegt es häufig nicht an einem falschen Prompt, sondern daran, dass das umgebende technische Gerüst, der sogenannte Agent Harness, dem Modell zu viel, zu wenig oder falsches Material zeigt. Der Begriff beschreibt die Infrastruktur, die den KI-Agenten umgibt und steuert. Es bestimmt, welche Dateien gelesen, welche Befehle ausgeführt und welche Ergebnisse zurückgefüttert werden. Context Engineering bedeutet hier deshalb vor allem, den Kontextfluss über Aktionen hinweg gezielt zu steuern. Die Hebel dafür sind: Umfang verengen: "Arbeite nur in diesen zwei Dateien oder Ordnern." Relevante Stellen identifizieren: "Nutze diese Funktion oder Zeile als Einstiegspunkt." Output der Tools kuratieren: Statt komplette Logs einzuspeisen, gibst du nur die relevante Fehlermeldung plus zwanzig Zeilen Kontext weiter. Die Briefing-Datei: Das permanente Projektgedächtnis Agentische Tools verwenden spezielle Dokumente, die der Agent automatisch liest, um Kontext über dein Projekt zu bekommen. Je nach Tool heißen diese Dateien unterschiedlich (CLAUDE.md, AGENTS.md, …), aber das Prinzip ist identisch: Sie sind das wichtigste Werkzeug, um das Briefing zu etablieren. Diese Briefing-Datei enthält typischerweise Befehle, Stilregeln und Arbeitsweisen. Sie gibt dem Agenten Kontext, den er nicht allein aus dem Code erschließen kann. Hier gehört das Briefing hin: Projektziel, Architekturüberblick, zentrale Befehle, harte Stilregeln, No-Gos. Für größere Projekte kannst du Regeln in mehrere Regel-Dateien aufteilen. Das ermöglicht fokussierte, gut organisierte Regeldateien statt einer einzigen überladenen Briefing-Datei. Briefing schlank halten Halte die Briefing-Datei knapp. Frage dich bei jeder Regel, ob der Agent dadurch weniger Fehler macht. Aufgeblähte Briefings führen dazu, dass der Agent deine Regeln ignoriert. Es gilt dasselbe Prinzip wie "Prompt-Hygiene" bei klassischen Chatbots, nur mit höherem Risiko, weil der Agent eigenständig handelt. Der Claude-Code-Harness enthält laut einer Analyse von HumanLayer bereits etwa 50 individuelle Regeln im System-Prompt. Je nach Modell ist das bereits ein Drittel der Regeln, die der Agent zuverlässig befolgen kann, bevor Rules, Plugins, Skills oder User-Messages hinzukommen. Deine Briefing-Datei sollte so wenige Regeln wie möglich enthalten, idealerweise nur solche, die universell für deine Aufgabe gelten. Material referenzieren statt kopieren Bevorzuge Verweise statt Kopien. Statt alle Anweisungen in die Briefing-Datei zu packen, halte aufgabenspezifische Regeln in separaten Markdown-Dateien fest. Die Briefing-Datei enthält dann eine kurze Beschreibung der verfügbaren Dokumentationsdateien und weist den Agenten an, bei Bedarf die relevanten zu lesen. So bleibt der Basiskontext schlank, und detailliertes Material wird nur dann geladen, wenn es wirklich gebraucht wird. Situatives Material: Skills und Commands Manche Tools erlauben es, Domänenwissen und wiederverwendbare Workflows in separaten Dateien zu hinterlegen, die der Agent nur bei Bedarf lädt. In Claude Code heißen diese Dateien SKILL.md (im Verzeichnis .claude/skills/). Sie erweitern das Wissen mit Informationen, die spezifisch für Projekt, Team oder Fachgebiet sind. Der Agent wendet sie automatisch an, wenn sie relevant sind, oder du kannst sie direkt aufrufen. Das Prinzip dahinter ist toolübergreifend: Die Briefing-Datei wird bei jeder Session geladen, daher solltest du nur Dinge aufnehmen, die breit gelten. Für Domänenwissen oder Workflows, die nur manchmal relevant sind, nutze stattdessen separate Dateien. Der Agent lädt sie bei Bedarf, ohne jede Konversation aufzublähen. Für wiederkehrende Workflows wie Debugging-Loops oder Log-Analyse speicherst du Prompt-Templates als Markdown-Dateien in einem dafür vorgesehenen Ordner (in Claude Code: .claude/commands). Diese werden über das Slash-Commands-Menü verfügbar. Recherchieren, Planen und Ausführen Das Phasenmodell aus dem Chat-Teil wird in agentischen KI-Werkzeugen noch wichtiger, weil der Kontext durch automatische Tool-Outputs schneller wächst. Die Grundlogik bleibt gleich: erst verstehen, dann planen, dann umsetzen. Die Werkzeuge ändern sich jedoch: Recherchephase: Bitte den Agenten, relevante Dateien, Bilder oder URLs zu lesen, entweder mit allgemeinen Hinweisen ("Lies die Datei mit den Marketinginformationen") oder mit konkreten Dateinamen ("Lies Marketing-Guidelines.docx"). Sag dabei explizit, dass noch kein finaler Text oder Code geschrieben werden soll. Prompt: Lies die folgenden Dateien und fasse für jede in maximal drei Sätzen zusammen, was sie für unser Problem beiträgt: [Dateiliste]. Schreib noch keinen Code. Es kann in dieser Phase sinnvoll sein, Subagents zu nutzen, besonders bei komplexen Problemen. Ein Subagent darf breit lesen und schickt dann nur ein kurzes Ergebnis an den orchestrierenden Hauptagenten (wo ist was, was ist wichtig). Der Hauptkontext bleibt dementsprechend schlank. Planungsphase: Bitte den Agenten, einen Plan zu erstellen. In Claude Code aktiviert das Wort "think" den Extended Thinking Mode, der zusätzliche Rechenzeit für eine gründlichere Evaluation gibt. Prompt: Think hard about this problem. Erstelle einen Plan als Checkliste und schreib ihn in plan.md. Pro Punkt: Was wird geändert, in welcher Datei, und warum. Den Plan in eine externe Datei wie plan.md zu schreiben und als Checkliste zu nutzen, hat sich in der Praxis als gute Arbeitsmethode erwiesen. Ausführungsphase: Der Plan wird abgearbeitet. Während langer Sessions kann sich das Kontextfenster mit irrelevanter Konversation, Dateiinhalten und Commands füllen. Bevor du das Kontextfenster mit /clear zurücksetzt, lässt du den Agenten den aktuellen Arbeitsstand in eine Datei wie status.md schreiben, etwa mit dem Prompt: "Fasse den aktuellen Stand zusammen: Was ist erledigt, was ist offen, welche Entscheidungen wurden getroffen. Schreib das Ergebnis in status.md." Nach dem Zurücksetzen liest der Agent status.md automatisch oder auf Anweisung und arbeitet mit einem sauberen Kontext weiter. Für längere Projekte lohnt es sich, den Agenten anzuweisen, nach jedem abgeschlossenen Arbeitsschritt die Statusdatei automatisch zu aktualisieren. So entsteht ein laufend gepflegtes Arbeitsgedächtnis, das unabhängig vom Chatfenster existiert. Das ist der zentrale Unterschied zum klassischen Chat: Das Dateisystem wird zum Arbeitsgedächtnis, das Chatfenster zur Steuerzentrale. Arbeitsunterlagen, die nicht unmittelbar gebraucht werden, liegen in Dateien. Auch das Briefing wird in einer persistenten Datei gepflegt. Das Chatfenster selbst bleibt so schlank wie möglich. Micro-Loops und Kontext-Isolation Kleine agentische Schleifen (Loops) mit engem Scope sind zuverlässiger als große "Mach alles"-Aufträge. Je kleiner der Loop, desto kontrollierbarer der Kontext. Praktisch heißt das: Du teilst große Tasks in kleine, testbare Abschnitte und änderst zwischen den Abschnitten vor allem, welche Dateien und Resultate in den Kontext gelangen. Der Prompt kann dabei gleichbleiben. Für komplexe Aufgaben gehen Subagents noch weiter. Jede Aufgabe verbraucht Token für Eingabe, Arbeit und Antwort. Bei vielen Aufgaben im selben Fenster summiert sich das schnell und führt in die Zone, in der die Modellqualität einbricht. Subagents lösen dieses Problem, indem sie die Arbeit an spezialisierte Agenten auslagern, die jeweils in einem eigenen, sauberen Kontextfenster arbeiten. Nur die finalen Antworten fließen an den Hauptagenten zurück. Ein Hinweis zur Praxis: Subagents sind nicht für jede Situation die beste Wahl. Zu stark spezialisierte Subagents können dem Hauptagenten wichtigen Kontext vorenthalten und ihn in starre Workflows zwingen. Manche Entwickler bevorzugen daher, dem Hauptagenten den gesamten Kontext zu geben und ihn selbst entscheiden zu lassen, wann er Aufgaben delegiert. Wie bei allen Context-Engineering-Entscheidungen gilt: Die richtige Balance hängt von der Aufgabe ab. Dasselbe Prinzip lässt sich auch auf die Recherche anwenden. Wer den Agenten viele Dateien auf einmal durchsuchen lässt, verbraucht schnell große Mengen an Kontext. Auch hier hilft es, in zwei Stufen zu arbeiten: Zuerst identifiziert eine schnelle Vorstufe, etwa ein Subagent oder ein kurzer Prompt, die relevanten Dateien. Dann folgt eine tiefe Analyse nur auf diesen Dateien. Schritt 1: Welche fünf bis zehn Dateien sind wahrscheinlich relevant für dieses Problem? Begründe kurz. Schritt 2: Analysiere diese Dateien gründlich. Für Wissensarbeit außerhalb von Code funktioniert das genauso. Im ersten Schritt fragst du: "Welche drei Dokumente aus diesem Ordner sind für meine Frage zentral?" und im zweiten: "Analysiere diese drei im Detail." Fazit: Die fünf Kernprinzipien Context Engineering ist eine Arbeitsweise. Die Prinzipien lassen sich in fünf Regeln zusammenfassen: Briefing und Arbeitsunterlagen trennen. Stabile Hintergrundinformationen wie Unternehmensprofil, Tonalität, Formatvorgaben gehören in ein gepflegtes Dokument, und wechselndes Material gehört nur in den Chat, in dem es gebraucht wird. So wenig wie möglich, so viel wie nötig. Das Prinzip der Progressive Disclosure ersetzt das Vorgehen "alles auf einmal". Jeder Arbeitsschritt bekommt nur den Kontext, den er braucht. In Phasen arbeiten. Das Muster ist immer dasselbe: zuerst verstehen, dann planen, dann ausführen. Das gilt im Chat ebenso wie im agentischen Werkzeug. Regelmäßig verdichten. Nutze Snapshots statt endloser Chatverläufe und starte neue Chats, statt überfüllte Kontextfenster weiterzuführen. Wenige, klare Regeln. Fünf zentrale Regeln sind wirksamer als fünfzig vage. Prompt-Hygiene gilt für Menschen und Agenten gleichermaßen. Wer diese Prinzipien anwendet, erhält bessere KI-Ergebnisse und wird feststellen, dass auch das eigene Denken über Aufgaben, Informationen und Arbeitsschritte klarer wird – ein wichtiger Baustein erfolgreicher KI-Nutzung und der Entwicklung zuverlässiger KI-Workflows. Mehr zu diesem Thema kannst du in unserem Deep Dive "KI-Workflows – Von Grundlagen bis zu intelligenten Agenten" und dem dazugehörigen Webinar erfahren.

Context Engineering: Leitfaden für die tägliche Arbeit mit KI-Modellen

heise KI PROKI VERSTEHEN UND ANWENDEN

heise KI PRO
KI VERSTEHEN UND ANWENDEN