Wissen
Context Engineering
Context Engineering beschreibt die systematische Gestaltung der Informationsumgebung, die einem Large Language Model während einer Anfrage zur Verfügung steht. Dazu gehören nicht nur Prompts, sondern auch Gesprächshistorie, Retrieval-Ergebnisse, Memory, Tool-Ausgaben, Zustände, Beispiele, Regeln, Daten und andere Informationen, die das Modell für den aktuellen Arbeitsschritt benötigt.
Nicht möglichst viel Kontext bereitstellen, sondern möglichst relevanten, aktuellen und handlungsfähigen Kontext.
Prompt, Retrieval, Memory, Conversation State, Tools, Beispiele, Constraints und strukturierte Daten.
Informationsdichte, Zuverlässigkeit und Aufgabenerfolg bei begrenztem Context Window verbessern.
Dokument-Metadaten
Worum geht es in diesem Wissensbeitrag?
Einordnung des Inhalts
- Entity Class
- Wissen
- Content-Typ
- Ratgeber / technischer Wissensbeitrag
- Hauptthema
- Context Engineering
- Themenkategorie
- Large Language Models / Agenten / RAG / Memory / Context Management
- Primäres Optimierungsobjekt
- Aktiver Informationskontext während der LLM-Inferenz
- Verwandte Konzepte
- Prompt Engineering, RAG, Context Folding, Prompt Compression, Memory, Tool Use und Long Context
- Kernfrage
- Welche Informationen sollte das Modell für den aktuellen Arbeitsschritt in welcher Form tatsächlich sehen?
Definition
Was ist Context Engineering?
Context Engineering umfasst die systematische Auswahl, Erzeugung, Strukturierung, Platzierung, Verdichtung und Aktualisierung der Informationen, die ein LLM während der Inferenz erhält. Der Begriff erweitert damit Prompt Engineering von der Formulierung einzelner Instruktionen auf die Architektur der gesamten Informationsumgebung.
Definition als Faktenstruktur
- Input
- Informationen aus Prompt, Nutzereingabe, Memory, Retrieval, Tools, Daten und Systemzustand
- Processing
- Filtern, priorisieren, strukturieren, ordnen, verdichten, normalisieren und gegebenenfalls erzeugen
- Output
- Ein auf den aktuellen Arbeitsschritt optimierter aktiver Kontext
- Constraint
- Context Window, Tokenkosten, Latenz und begrenzte zuverlässige Nutzung sehr langer Eingaben
- Qualitätsziel
- Hohe Relevanzdichte bei möglichst geringem Verlust kritischer Informationen
- Systemebene
- Context Engineering kann statisch vor einer Anfrage oder dynamisch während eines Agenten-Workflows erfolgen
Abgrenzung
Prompt Engineering ist ein Teil von Context Engineering
Wie wird die Aufgabe formuliert?
Prompt Engineering optimiert Instruktionen, Beispiele, Rollen, Ausgabeformate und sprachliche Formulierungen, mit denen das gewünschte Modellverhalten beschrieben wird.
Welche Informationswelt sieht das Modell?
Context Engineering bestimmt zusätzlich, welche Dokumente, Erinnerungen, Tool-Ausgaben, Zustände, Regeln, Daten und vorherigen Ergebnisse dem Modell überhaupt zur Verfügung stehen.
Prompt Engineering = Instruktion gestalten
Context Engineering = gesamte Informationsumgebung gestalten
Context Model
Der aktive Kontext ist das Ergebnis einer Informationspipeline
Kontext sollte nicht als statischer Textblock verstanden werden. In komplexen LLM-Systemen wird er für jeden Arbeitsschritt neu zusammengestellt und kann sich nach Tool-Aufrufen, Retrieval oder Zustandsänderungen kontinuierlich verändern.
Prompt, User, Memory, Dokumente, Daten, Tools und Systemzustand.
Welche Informationen könnten für die Aufgabe relevant sein?
Welche Informationen sollen tatsächlich in den aktiven Kontext?
Wie werden Regeln, Fakten, Beispiele und Evidenz organisiert?
Welche redundanten oder abgeschlossenen Informationen lassen sich verdichten?
Wo im Kontext werden kritische Informationen positioniert?
Das Modell nutzt den aktiven Kontext für den aktuellen Schritt.
Neue Ergebnisse verändern State, Memory und den nächsten Kontext.
Context Sources
Aus welchen Informationsschichten kann Kontext bestehen?
Systemregeln und Rolle
Grundlegende Verhaltensregeln, Zuständigkeiten, Sicherheitsgrenzen und dauerhafte Systeminstruktionen.
Aktuelle Nutzerintention
Frage, Ziel, gewünschtes Ergebnis und aktuell formulierte Bedingungen des Nutzers.
Dialoghistorie
Frühere Fragen, Antworten, Entscheidungen, Korrekturen, Präferenzen und offene Aufgaben.
Extern abgerufenes Wissen
Dokumentpassagen, Produktdaten, Datenbankergebnisse oder andere Informationen, die für die aktuelle Anfrage gesucht wurden.
Persistente Information
Relevante Informationen aus früheren Sitzungen oder ausgelagerte Zustände außerhalb des aktuellen Context Windows.
Beobachtungen aus externen Systemen
Suchergebnisse, API-Antworten, Berechnungen, Codeausführung oder Daten aus anderen Anwendungen.
Arbeits- und Prozesszustand
Bereits erledigte Schritte, aktuelle Phase, offene Punkte, Entscheidungen und nächste Aktionen.
Beispiele und Ausgabeschemata
Demonstrationen, Referenzausgaben, Style Guides, Datenmodelle oder formale Output-Strukturen.
Context Layers
Nicht jede Information besitzt dieselbe Lebensdauer
Beispielhafte Kontext-Hierarchie
- Policy Context
- Langfristig stabile Regeln und Systemgrenzen
- Domain Context
- Fachmodelle, Definitionen, Taxonomien und dauerhaft relevante Domänenlogik
- Task Context
- Ziel, Deliverable, Constraints und Anforderungen der aktuellen Aufgabe
- Working Context
- Informationen, die für den aktuellen Reasoning- oder Aktionsschritt unmittelbar benötigt werden
- Evidence Context
- Retrievte Quellen, Fakten, Dokumente und Daten zur Begründung konkreter Claims
- Tool Context
- Temporäre Ergebnisse aus API-, Search-, Code- oder anderen Tool-Aufrufen
- Memory Context
- Ausgelagerte historische Informationen, die nur bei Relevanz aktiviert werden
Context Problem
Mehr Kontext ist nicht automatisch besserer Kontext
Große Kontextfenster erhöhen die verfügbare Kapazität. Sie lösen aber nicht automatisch die Frage, welche Informationen relevant sind und wie zuverlässig das Modell diese Informationen nutzt.
Relevante Information geht zwischen vielen irrelevanten Tokens unter.
Modelle nutzen Information abhängig von ihrer Position im langen Kontext unterschiedlich zuverlässig.
Mehrere Kontextquellen können unterschiedliche oder veraltete Aussagen enthalten.
Frühere Entscheidungen bleiben im Kontext, obwohl sich der aktuelle Zustand verändert hat.
Unnötige Informationen erhöhen Kosten, KV-Cache-Größe und Latenz.
Viele gleichzeitig verfügbare Signale konkurrieren um begrenzte Modellaufmerksamkeit.
Context Retrieval
RAG ist eine Form von Context Engineering
Retrieval-Augmented Generation löst einen Teil des Context-Engineering-Problems: Statt sämtliches potenziell relevantes Wissen dauerhaft in den Prompt zu legen, wird für jede Anfrage eine Teilmenge externer Informationen ausgewählt und in den aktiven Kontext eingebracht.
Context Retrieval Pipeline
- Query Understanding
- Welche Information wird für die aktuelle Aufgabe benötigt?
- Candidate Retrieval
- Welche Dokumente, Daten oder Memory-Objekte könnten relevant sein?
- Ranking / Reranking
- Welche Kandidaten besitzen die höchste fachliche Relevanz?
- Context Assembly
- Welche Ausschnitte werden tatsächlich in den aktiven Kontext übernommen?
- Grounding
- Welche Antwort-Claims können auf die abgerufenen Informationen zurückgeführt werden?
Context Processing
Gefundener Kontext muss häufig erst aufbereitet werden
Irrelevantes entfernen
Inhalte ohne ausreichende Relevanz für den aktuellen Schritt sollten den aktiven Kontext nicht unnötig belasten.
Relevanz priorisieren
Besonders wichtige Evidenz kann stärker priorisiert und prominenter im Kontext platziert werden.
Information vereinheitlichen
Strukturierte Daten, Einheiten, Identitäten und Formate können vor der Übergabe an das Modell normalisiert werden.
Detailhistorie verdichten
Lange Abschnitte können in kompakte Zustands- oder Ergebnisrepräsentationen überführt werden.
Informationstypen trennen
Regeln, Facts, Evidence, Examples und State sollten möglichst eindeutig voneinander unterscheidbar sein.
Metadaten erhalten
Quelle, Zeitpunkt, Entity, Gültigkeit und Vertrauensniveau erhöhen die spätere Verwendbarkeit von Kontext.
Context Compression
Informationsdichte ist oft wichtiger als rohe Tokenmenge
Prompt Compression und Context Folding verfolgen unterschiedliche Mechanismen, aber ein gemeinsames Ziel: Der aktive Kontext soll weniger unnötige Tokens enthalten, ohne relevante Aufgabeninformation zu verlieren.
Bestehende Eingabe verdichten
Redundante oder wenig informative Teile eines langen Prompts werden reduziert, damit relevante Information dichter vorliegt.
Abgeschlossene Arbeit zusammenfalten
Tokenintensive Sub-Trajektorien werden nach Abschluss durch kompakte Ergebnisse im aktiven Working Context ersetzt.
Wissensbeitrag öffnenMemory
Context Engineering entscheidet auch, was nicht aktiv im Kontext bleibt
Aktiver Kontext versus ausgelagerte Information
- Working Memory
- Information, die für den aktuellen Schritt unmittelbar erforderlich ist
- Episodic Memory
- Frühere Interaktionen, Ereignisse und abgeschlossene Arbeitsschritte
- Semantic Memory
- Stabilere Fakten, Regeln, Präferenzen und Domänenwissen
- External Store
- Dokumente oder historische Daten außerhalb des Context Windows
- Recall
- Nur relevante Erinnerungen werden bei Bedarf wieder in den aktiven Kontext geladen
- Eviction
- Irrelevante beziehungsweise überholte Information wird aus dem Working Context entfernt
Tool Context
Tool Use erzeugt neuen Kontext während der Laufzeit
Agentische Systeme erweitern ihren Kontext aktiv. Das Modell kann beispielsweise eine Suche, Datenbankabfrage oder Berechnung auslösen. Das Resultat wird zur neuen Beobachtung und beeinflusst den nächsten Reasoning- oder Handlungsschritt.
Aktueller Wissens- und Aufgabenstand.
Welche externe Information oder Aktion fehlt?
Search, API, Code, Datenbank oder andere Aktion.
Das Tool liefert ein neues Ergebnis.
Relevante Information wird in den Working Context integriert.
Das Modell entscheidet auf Basis des aktualisierten Kontextes weiter.
Context Placement
Auch die Position relevanter Information kann wichtig sein
Praktische Platzierungsprinzipien
- Priorität sichtbar machen
- Kritische Ziele und Constraints sollten nicht zwischen großen Mengen sekundärer Information verschwinden.
- Evidence bündeln
- Claims und dazugehörige Evidenz sollten möglichst klar miteinander verbunden sein.
- State aktuell halten
- Der aktuelle Arbeitszustand sollte gegenüber veralteter Historie eindeutig erkennbar sein.
- Konflikte explizit machen
- Widersprüchliche Quellen sollten nicht ungekennzeichnet nebeneinanderstehen.
- Long-Context-Risiko
- Forschung zeigt, dass relevante Information in langen Kontexten positionsabhängig unterschiedlich zuverlässig genutzt werden kann.
Context Lifecycle
Kontext ist ein veränderlicher Laufzeitzustand
Neue Aufgabe, Instruktion oder Information entsteht.
Relevante externe oder historische Information wird gesucht.
Ausgewählte Information gelangt in den aktiven Kontext.
Information wird strukturiert, verdichtet oder normalisiert.
Das Modell verwendet den Kontext für Reasoning oder Handlung.
Neue Beobachtungen verändern die Kontextrepräsentation.
Langfristig relevante Information wird außerhalb des Working Context gespeichert.
Irrelevante, redundante oder überholte Information wird entfernt.
Beispiel
Context Engineering bei einem B2B-Research-Agenten
Beispielhafte Kontextarchitektur
- System Context
- Rechercheprinzipien, Quellenanforderungen, Ausgabeformat und Umgang mit Unsicherheit
- Task Context
- Zu untersuchender Markt, Unternehmen, Zeitfenster und konkrete Nutzerfrage
- Retrieval Context
- Aktuell relevante Webseiten, Paper, Dokumente und Daten
- Tool Context
- Suchergebnisse, Datenbankabfragen und extrahierte Fakten
- Working State
- Welche Teilfragen bereits beantwortet wurden und welche Evidenz noch fehlt
- Folded Context
- Abgeschlossene Recherchepfade werden auf Kernergebnisse, Quellen und offene Unsicherheiten reduziert
- Final Context
- Nur die für Synthese und Quellenbegründung relevanten Ergebnisse verbleiben aktiv
Designprinzipien
Was guten Kontext auszeichnet
Aufgabenrelevant
Information sollte einen nachvollziehbaren Beitrag zur aktuellen Entscheidung oder Ausgabe leisten.
Informationsdicht
Wenig redundanter Inhalt bei hoher Dichte an relevanten Fakten, Regeln und Constraints.
Aktuell
Veraltete Zustände oder Quellen sollten gegenüber neueren Informationen nicht ungekennzeichnet dominieren.
Rückverfolgbar
Wichtige Fakten sollten möglichst mit Quelle, Entity und Gültigkeitskontext verbunden bleiben.
Eindeutig strukturiert
Instruktionen, Fakten, Beispiele, Tool-Ausgaben und Nutzerdaten sollten semantisch unterscheidbar sein.
Wiederherstellbar
Verdichtete Details sollten bei Bedarf aus Originalquellen oder Memory erneut abrufbar sein.
Measurement
Context Engineering benötigt Qualitäts- und Effizienzmetriken
Erreicht das System mit dem bereitgestellten Kontext das gewünschte Ergebnis?
Welcher Anteil des aktiven Kontexts ist für die konkrete Aufgabe tatsächlich relevant?
Wurden alle für eine korrekte Antwort notwendigen Informationen in den Kontext aufgenommen?
Wie hoch ist der Anteil wirklich hilfreicher Informationen unter allen eingebrachten Kontextobjekten?
Wie viele aktive Tokens werden für einen erfolgreichen Arbeitsschritt benötigt?
Wie zuverlässig stützen die ausgewählten Kontextquellen die erzeugten Claims?
Welche Laufzeitkosten verursachen Retrieval, Kompression und Context Assembly?
Bleiben relevante Constraints, Entscheidungen und offene Aufgaben über längere Abläufe erhalten?
Task Success ↑ + Groundedness ↑ + relevante Informationsdichte ↑ bei aktiven Tokens ↓
Failure Modes
Typische Fehler entstehen nicht nur im Modell, sondern bereits in der Kontextarchitektur
Context-Engineering-Fehler
- Missing Context
- Eine notwendige Information wird gar nicht bereitgestellt.
- Context Overload
- Zu viele potenziell relevante Informationen verwässern die wirklich wichtigen Signale.
- Wrong Retrieval
- Semantisch ähnliche, aber fachlich falsche Informationen gelangen in den Prompt.
- Stale Memory
- Veraltete Informationen werden als aktueller Zustand reaktiviert.
- Constraint Loss
- Wichtige Anforderungen gehen bei Summarization oder Folding verloren.
- Context Conflict
- Mehrere Quellen oder Instruktionen widersprechen sich, ohne dass eine Priorität festgelegt ist.
- Tool Noise
- Große Tool-Ausgaben werden vollständig in den Kontext kopiert, obwohl nur wenige Ergebnisse relevant sind.
- Context Collapse
- Wiederholtes Umschreiben oder Zusammenfassen reduziert schrittweise wichtige Details und Nuancen.
- Provenance Loss
- Ein Fakt bleibt erhalten, aber seine Quelle oder Gültigkeitsbedingung geht verloren.
Agentic Context Engineering
Fortgeschrittene Systeme verändern ihren Kontext selbst
In Agentensystemen ist Context Engineering nicht ausschließlich eine statische Entwickleraufgabe. Der Agent kann selbst entscheiden, welche Informationen er sucht, welche Ergebnisse er behält, welche Zwischenschritte er verdichtet und welche Erfahrungen in zukünftigen Aufgaben wiederverwendet werden.
Kontext erzeugen
Der Agent formuliert Strategien, Zwischenziele oder neue Suchanfragen.
Ergebnisse bewerten
Erfahrungen und Ausführungsergebnisse werden auf Nutzen und Fehler analysiert.
Kontext weiterentwickeln
Hilfreiche Regeln, Strategien oder Memory-Objekte werden aktualisiert und organisiert.
Verwandte Entitäten
Context Engineering verbindet mehrere Leadterion-Wissensobjekte
Large Language Models
Erklärt das Context Window und die Transformer-Grundlage, innerhalb derer der aktive Kontext verarbeitet wird.
Wissensbeitrag öffnenRetrieval-Augmented Generation
RAG ist ein zentraler Context-Engineering-Mechanismus zur dynamischen Auswahl externer Information.
Wissensbeitrag öffnenContext Folding
Context Folding behandelt die aktive Reduktion abgeschlossener Arbeitstrajektorien in Long-Horizon-Agenten.
Wissensbeitrag öffnenGroundedness & Faithfulness
Bewertet, ob die durch Context Engineering bereitgestellte Evidenz in der finalen Antwort tatsächlich korrekt genutzt wird.
Wissensbeitrag öffnenItemRAG
Zeigt Context Engineering über strukturierte Produktattribute, Relationen und item-zentriertes Wissen.
Wissensbeitrag öffnenConversational Commerce
Lang laufende Dialoge benötigen dynamisches Context Management, um Präferenzen, Produktwissen und Journey-State konsistent zu halten.
Wissensbeitrag öffnenFAQ
Häufige Fragen zu Context Engineering
Was ist Context Engineering?
Context Engineering ist die systematische Gestaltung der Informationen, die ein LLM während der Inferenz sieht. Dazu gehören Auswahl, Retrieval, Strukturierung, Platzierung, Verdichtung, Aktualisierung und Entfernung von Kontext.
Was ist der Unterschied zu Prompt Engineering?
Prompt Engineering optimiert primär Instruktionen und Formulierungen. Context Engineering umfasst zusätzlich Conversation History, Retrieval, Memory, Tools, Zustände, Daten, Beispiele und andere Laufzeitinformationen.
Ist RAG Context Engineering?
Ja. RAG ist eine wichtige Context-Engineering-Technik, weil externe Informationen dynamisch ausgewählt und für eine konkrete Anfrage in den aktiven Kontext eingebracht werden.
Ist mehr Kontext grundsätzlich besser?
Nein. Mehr Kontext kann zusätzliche relevante Information enthalten, erhöht aber auch Kosten, Redundanz und mögliche Ablenkung. Forschung zu langen Kontexten zeigt zudem, dass Modelle relevante Informationen nicht an jeder Position gleich zuverlässig nutzen.
Welche Rolle spielt Memory?
Memory ermöglicht, Informationen außerhalb des aktiven Context Windows zu speichern und nur bei Bedarf wieder zu aktivieren. Dadurch muss nicht die gesamte Historie dauerhaft im Prompt verbleiben.
Was ist der Unterschied zwischen Context Compression und Context Folding?
Context Compression reduziert die Tokenmenge bestehender Eingaben. Context Folding verwaltet zusätzlich den Lebenszyklus abgeschlossener Agenten-Subtasks und ersetzt ihre Zwischenhistorie durch kompakte Ergebnisse.
Was ist Agentic Context Engineering?
Dabei entscheidet ein Agent selbst dynamisch, welche Informationen er beschafft, behält, strukturiert, verwirft oder als wiederverwendbare Strategien und Erinnerungen weiterentwickelt.
Wie lässt sich Context Engineering messen?
Wichtige Dimensionen sind Task Success, Context Relevance, Evidence Recall, Token Efficiency, Groundedness, Latenz und die zuverlässige Erhaltung kritischer Zustände und Constraints.
Quellen
Wissenschaftliche Arbeiten zu Context Engineering und seinen Komponenten
Context Engineering ist ein junges übergeordnetes Forschungsfeld. Die Auswahl verbindet aktuelle Arbeiten, die den Begriff systematisch definieren, mit grundlegender Forschung zu Retrieval, Long Context, Memory, Tool Use und Context Compression.
| Quelle | Autoren / Jahr | Einordnung | Originalquelle |
|---|---|---|---|
| A Survey of Context Engineering for Large Language Models | Lingrui Mei et al. · 2025 | Systematisiert Context Engineering als übergeordnetes Feld und gliedert es unter anderem in Context Retrieval and Generation, Context Processing und Context Management sowie deren Integration in RAG, Memory, Tool- und Multi-Agent-Systeme. | arXiv:2507.13334 |
| A comprehensive survey of prompt engineering and context engineering techniques in large language models | Tonmoy Debnath et al. · 2026 | Ordnet die Entwicklung von promptbezogener Steuerung hin zu systemweiter Kontextorchestrierung ein und verbindet klassische Prompting-Techniken mit RAG und mehrstufigen Reasoning-Systemen. | DOI 10.1016/j.cosrev.2026.100979 |
| Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks | Patrick Lewis et al. · 2020 | Grundlegende RAG-Arbeit. Verbindet parametrisches Modellwissen mit einer externen nicht-parametrischen Wissensquelle und etabliert Retrieval als dynamische Kontextquelle für Generierung. | arXiv:2005.11401 |
| Lost in the Middle: How Language Models Use Long Contexts | Nelson F. Liu et al. · 2024 | Zeigt, dass relevante Information in langen Kontexten nicht positionsunabhängig gleich zuverlässig genutzt wird. Das begründet die Bedeutung von Auswahl, Struktur und Placement. | ACL Anthology / TACL |
| LongLLMLingua: Accelerating and Enhancing LLMs in Long Context Scenarios via Prompt Compression | Huiqiang Jiang et al. · 2024 | Untersucht Prompt Compression für Long-Context-Szenarien und verbindet reduzierte Tokenmengen mit Relevanzdichte, Kosten- und Latenzoptimierung. | ACL Anthology |
| MemGPT: Towards LLMs as Operating Systems | Charles Packer et al. · 2023 | Führt ein hierarchisches beziehungsweise virtuelles Context-Management-Modell ein, das Informationen zwischen verschiedenen Memory-Ebenen verschiebt und dadurch lange Dialoge und Dokumentaufgaben unterstützt. | arXiv:2310.08560 |
| ReAct: Synergizing Reasoning and Acting in Language Models | Shunyu Yao et al. · 2023 | Verbindet Reasoning und externe Aktionen in einer Schleife. Tool- beziehungsweise Environment-Beobachtungen erzeugen dabei laufend neuen Kontext für die nächsten Modellentscheidungen. | ICLR 2023 |
| Toolformer: Language Models Can Teach Themselves to Use Tools | Timo Schick et al. · 2023 | Untersucht, wie Sprachmodelle lernen können, externe APIs aufzurufen und deren Resultate in die weitere Tokenvorhersage zu integrieren. | NeurIPS 2023 |
| Scaling Long-Horizon LLM Agent via Context-Folding | Weiwei Sun et al. · 2025 | Behandelt aktives Working-Context-Management in Long-Horizon-Agenten: Subtasks können verzweigt und nach Abschluss als kompaktes Ergebnis in den Hauptkontext zurückgeführt werden. | arXiv:2510.11967 |
| Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models | Qizheng Zhang et al. · 2025 | Behandelt Kontext als veränderliche, kuratierte Wissens- und Strategieschicht. Das Framework aktualisiert Kontext über Generation, Reflexion und Curation statt ausschließlich über statische Promptdefinitionen. | arXiv:2510.04618 |
| Context Engineering for AI Agents in Open-Source Software | Seyedmoein Mohsenimofidi et al. · 2025 | Empirische Untersuchung realer Projektkontexte für Coding-Agenten. Analysiert, welche Architektur-, Workflow-, Test- und Coding-Regeln Entwickler in agentenspezifischen Kontextdateien bereitstellen. | arXiv:2510.21413 |
Wissen
Context Engineering entscheidet, welche Welt das Modell für den nächsten Arbeitsschritt sieht
Ein leistungsfähiges LLM kann nur mit den Informationen arbeiten, die in seinem aktiven Kontext verfügbar und erkennbar relevant sind. Gute Context-Architekturen kombinieren deshalb Retrieval, Memory, Tool Results, State, Regeln und Evidenz zu einem dynamischen, aufgabenbezogenen Working Context.