Context Engineering für AI Agents: Vom Prompt zum Production-Ready System

„Der Agent hat perfekt funktioniert – bis zur 47. Iteration. Dann hat er einfach vergessen, was wir am Anfang besprochen haben.“ Kennt ihr das? Nach über 15 Jahren Erfahrung in Softwarequalität, Open Source und Remote Consulting zeigen wir euch heute, warum Context Engineering der entscheidende Faktor ist, der eure AI Agents von Demo-Spielereien zu verlässlichen Production-Systemen macht.

Warum Context Engineering euer Projekt retten wird

Die Wahrheit ist hart: Die meisten Agent-Failures sind keine Model-Failures – es sind Context-Failures. Während die AI-Community noch vor einem Jahr über perfekte Prompts diskutiert hat, ist längst klar geworden: Das eigentliche Engineering-Problem liegt in der intelligenten Verwaltung des Context Windows. Ein gut gebauter Agent mit durchdachtem Context Management schlägt einen „smarten“ Agent mit chaotischem Context um Längen.

Das Team von Never Code Alone hat in unzähligen Consulting-Projekten erlebt, wie Developer monatelang an Agent-Systemen arbeiten, nur um dann festzustellen: Das Problem war nie der Code – es war das Context Management. Zeit, das zu ändern.

Die 10 kritischen Fragen zu Context Engineering – direkt beantwortet

1. Was ist Context Engineering und wie unterscheidet es sich von Prompt Engineering?

Context Engineering ist der natürliche nächste Schritt nach Prompt Engineering. Während Prompt Engineering sich auf das Schreiben optimaler Instruktionen fokussiert, geht Context Engineering einen Schritt weiter: Es managt die gesamte Information, die dem LLM zur Verfügung steht – System-Prompts, Tools, Message History, externe Daten und mehr.

Der entscheidende Unterschied:

Prompt Engineering = "Was sage ich dem Modell?"
Context Engineering = "Was sieht das Modell zu jedem Zeitpunkt?"

In Production-Systemen läuft ein Agent über mehrere Turns, generiert ständig neue Daten und muss intelligent entscheiden, welche Informationen relevant bleiben. Das ist keine einmalige Prompt-Optimierung mehr – das ist kontinuierliche Context-Curation.

Praxis-Tipp aus 15+ Jahren Consulting: Startet mit Prompt Engineering für One-Shot-Tasks. Sobald euer Agent über mehrere Turns läuft oder länger als 5 Minuten arbeitet, braucht ihr Context Engineering. Keine Diskussion.

2. Warum verlieren AI Agents wichtige Informationen im Context Window?

Das Phänomen heißt „Context Rot“ und ist wissenschaftlich belegt: Je mehr Tokens im Context Window sind, desto schlechter kann das Modell Informationen abrufen. Es ist wie beim Menschen – auch wir haben ein limitiertes Working Memory.

Die technische Realität dahinter:

• LLMs basieren auf Transformer-Architektur mit n² pairweisen Beziehungen zwischen Tokens
• Bei längeren Sequenzen wird die Attention „dünn gestreckt“
• Modelle sind auf kürzeren Sequenzen trainiert, haben weniger Erfahrung mit langen Kontexten
• Result: Performance-Degradation statt harter Cliff

Konkretes Beispiel aus der Praxis: Ein Contract-Analysis-Agent verarbeitet 50-seitige Verträge. Auf Seite 5 steht eine kritische Haftungsklausel. Auf Seite 40 wird darauf Bezug genommen. Ohne Context Management „vergisst“ der Agent die Klausel von Seite 5 – mit fatalen Folgen für eure Legal-Compliance.

Consulting-Insight: Behandelt Context wie CPU-Zeit oder RAM – als knappe Ressource mit Diminishing Returns. Jedes Token kostet Attention Budget.

3. Wie groß sollte mein Context Window für Production-Systeme sein?

Die unbequeme Wahrheit: Größer ist nicht automatisch besser. Ein 1M Token Context Window klingt beeindruckend, aber was zählt ist effektiver Context, nicht maximaler Context.

Realistische Context-Grenzen für Production:

• System-Prompts: 1.000-3.000 Tokens
• Tools & Definitions: 500-2.000 Tokens
• Message History: 10.000-30.000 Tokens (mit Compaction)
• Retrieved Context: 5.000-15.000 Tokens
• Working Space: 10.000-20.000 Tokens

Rechnet mal durch: Selbst bei „kleinen“ Agents kommt ihr schnell auf 30k-70k Tokens. Bei 1M Token Context Window habt ihr theoretisch Platz – aber praktisch degradiert die Model-Performance deutlich ab 100k Tokens.

Best Practice aus unzähligen Projekten: Startet mit 50k Token Context Budget als Zielgröße für Production-Agents. Optimiert eure Context-Strategie, bevor ihr einfach das Window vergrößert. Claude Code macht das beispielsweise exzellent – kompakter Context, hohe Effizienz.

4. Was ist Context Rot und wie verhindere ich es?

Context Rot ist der schleichende Tod eurer Agent-Performance. Je voller euer Context Window wird, desto schwerer fällt es dem Modell, relevante Informationen zu finden. Das mittlere Drittel des Context ist besonders betroffen – das berühmte „Lost in the Middle“ Problem.

Die drei Haupt-Ursachen für Context Rot:

1. Context Pollution: Halluzinationen und Fehler landen im Context und werden immer wieder referenziert
2. Premature Optimization: Frühe, falsche Antworten bleiben im Context und beeinflussen spätere Generationen
3. Tool Output Bloat: Ungefilterter Tool-Output füllt den Context mit irrelevanten Details

Proven Solutions aus der Praxis:

# Context Pruning - Alte/konfliktäre Info entfernen
def prune_context(messages, current_task):
    relevant_msgs = filter_by_relevance(messages, current_task)
    return deduplicate(relevant_msgs)

# Tool Result Clearing - Raw Results nach Verarbeitung löschen
def clean_tool_results(context):
    # Keep tool summaries, drop raw outputs
    return [msg for msg in context if not is_raw_tool_result(msg)]

Projekt-Erfahrung: Ein Customer-Service-Agent verbesserte seine Accuracy um 34%, nachdem wir Context Pruning implementierten. Der Trick: Nicht jede Information muss forever im Context bleiben.

5. Welche Strategien gibt es für Context Compaction?

Compaction ist eure erste Verteidigungslinie gegen Context-Overflow. Die Idee: Wenn der Context voll wird, komprimiert ihr ihn intelligent und startet mit einem „sauberen“ Window neu.

Die drei Compaction-Levels:

Level 1 – Tool Result Clearing (Leichtester Touch):

// Anthropic bietet das als native Feature
const compactedContext = await claude.clearToolResults(messages);
// Reduziert Context um 40-60% ohne Info-Verlust

Level 2 – Selective Summarization:

def compact_context(messages, keep_recent=5):
    # Summarize old messages
    old_messages = messages[:-keep_recent]
    summary = llm.summarize(old_messages, focus_on=[
        "architectural_decisions",
        "unresolved_bugs", 
        "implementation_details"
    ])

    # Keep recent messages verbatim
    recent = messages[-keep_recent:]

    return [summary] + recent

Level 3 – Intelligent File Access (Claude Code Approach):
Statt alle Dateien im Context zu halten, nur die 5 zuletzt genutzten plus Summary. Reduziert Context drastisch bei minimalem Performance-Loss.

Consulting-Warnung: Overly aggressive Compaction führt zu subtilen Context-Verlusten. Testet eure Compaction-Prompts gründlich auf komplexen Agent-Traces. Maximiert erst Recall (alle relevanten Infos behalten), dann Precision (Überflüssiges entfernen).

6. Wie implementiere ich effektives Note-Taking für AI Agents?

Note-Taking (auch „Agentic Memory“) ist brillant simpel: Der Agent schreibt regelmäßig Notes außerhalb des Context Windows. Diese Notes werden bei Bedarf zurückgeladen.

Praktisches Beispiel – Persistent Memory:

# Agent schreibt NOTES.md während der Arbeit
class AgentMemory:
    def __init__(self):
        self.notes_file = "NOTES.md"

    def add_note(self, category, content):
        note = f"## {category} [{timestamp}]n{content}nn"
        append_to_file(self.notes_file, note)

    def recall_notes(self, category=None):
        notes = read_file(self.notes_file)
        if category:
            return filter_by_category(notes, category)
        return notes

# Im Agent-Loop
agent.memory.add_note("Progress", 
    "Trained Pikachu 8 levels in Route 1, target: 10 levels")
agent.memory.add_note("Combat Strategy", 
    "Thunderbolt effective vs Water types")

Real-World Case: Anthropic’s „Claude plays Pokémon“ demonstriert das perfekt. Der Agent maintained tallies über tausende Game-Steps, entwickelt Maps, trackt Achievements – alles in Notes. Nach Context-Resets liest er seine eigenen Notes und macht nahtlos weiter.

Best Practice Structure:

# AGENT_NOTES.md

## Current Objective
[What we're trying to achieve]

## Progress Tracker
- Task 1: ✅ Completed
- Task 2: 🔄 In Progress (73%)
- Task 3: ⏸️ Blocked by dependency

## Key Decisions
- 2025-10-01: Chose PostgreSQL over MongoDB (reason: ACID requirements)

## Known Issues
- API timeout on large datasets (>10k records)
- Workaround: Implement pagination

Developer-Tipp: Anthropic bietet seit Sonnet 4.5 ein natives Memory Tool. Nutzt es für file-based persistent memory. Spart euch Custom-Implementation.

7. Wann sollte ich RAG vs. Just-in-Time Context Retrieval nutzen?

Das ist die Millionen-Dollar-Frage für moderne Agent-Architekturen. Die Antwort: Kommt drauf an – aber es gibt klare Patterns.

RAG (Pre-Inference Retrieval):

• ✅ Gut für: Statische Knowledge Bases, Q&A über Dokumente
• ✅ Vorteil: Schnell, vorhersagbar
• ❌ Nachteil: Stale indices, komplexe Syntax Trees

Just-in-Time Retrieval (Agentic Exploration):

• ✅ Gut für: Dynamische Codebases, explorative Tasks
• ✅ Vorteil: Immer aktuell, intelligent exploriert
• ❌ Nachteil: Langsamer, braucht gutes Tool-Design

Hybrid-Ansatz (Best of Both Worlds):

# Beispiel: Claude Code Approach
def hybrid_context_retrieval(task):
    # Pre-load kritische Dateien
    context = load_critical_files([
        "CLAUDE.md",  # Naiv in Context
        "README.md"
    ])

    # Agent explored rest just-in-time
    available_tools = [
        "grep",      # Findet relevante Code-Sections
        "glob",      # Navigiert Dateistruktur
        "read_file"  # Lädt Files on-demand
    ]

    return context, available_tools

Projekt-Erfahrung aus Finance-Sector: Hybrid-Strategy reduzierte Context-Size um 67% und verbesserte Response-Quality um 41%. Compliance-kritische Docs waren pre-loaded (RAG), Research-Material wurde just-in-time explored.

Entscheider-Perspektive: RAG ist CapEx (Infrastruktur-Investment), Just-in-Time ist OpEx (Runtime-Cost). Hybrid optimiert beide Dimensionen.

8. Wie manage ich Tools für optimale Context-Effizienz?

Tools sind ein Doppel-Edge-Sword: Sie erweitern eure Agent-Capabilities massiv, aber jedes Tool kostet Context. Schlechtes Tool-Design ist der #1 Context-Killer.

Die goldenen Tool-Design-Regeln:

1. Self-Contained & Clear:

# ❌ Schlecht: Vage Tool-Description
def process_data(data, options):
    """Process some data with options"""
    pass

# ✅ Gut: Kristallklare Tool-Definition
def calculate_customer_churn_rate(
    customer_ids: list[str],
    period_start: date,
    period_end: date
) -> float:
    """
    Calculates churn rate for specified customers in date range.

    Returns: Percentage (0-100) of customers who cancelled.
    Use this when: Analyzing customer retention metrics.
    """
    pass

2. Minimale Tool-Sets ohne Overlap:

• ❌ 50 Tools mit overlapping functionality → Agent verwirrt
• ✅ 10-15 hochspezialisierte Tools → Agent weiß genau was wann

3. Token-Efficient Returns:

# ❌ Bloated Tool Output
def search_codebase(query):
    return {
        "results": [...],  # 500 Dateien, 50k Tokens
        "metadata": {...},
        "statistics": {...}
    }

# ✅ Smart Tool Output
def search_codebase(query, max_results=5):
    results = search(query)[:max_results]
    return {
        "matched_files": [f.path for f in results],
        "relevance_scores": [f.score for f in results],
        "total_matches": len(results),
        # Full content available via read_file(path)
    }

Production-Reality: Ein Code-Analysis-Agent hatte 43 Tools im ersten Design. Nach Refactoring auf 12 core Tools: 58% weniger Context-Usage, 34% bessere Task-Completion-Rate.

Consulting-Insight: Wenn ihr als Human Engineer nicht definitiv sagen könnt welches Tool für Situation X zu nutzen ist, kann es der Agent erst recht nicht. Vereinfacht!

9. Was sind die häufigsten Context Failures und wie behebe ich sie?

Aus hunderten Consulting-Projekten: Das sind die Top 5 Context Failures und ihre Fixes.

Failure #1 – Conversational Snowball:
Problem: Jeder Exchange konsumiert mehr Context, Agent vergisst frühe Infos.

# Fix: Aggressive Message Pruning
def prune_conversation(messages, keep_first=3, keep_last=5):
    if len(messages) <= keep_first + keep_last:
        return messages

    important = messages[:keep_first]  # Original context
    recent = messages[-keep_last:]     # Recent exchanges

    # Summarize middle
    middle = messages[keep_first:-keep_last]
    summary = create_summary(middle)

    return important + [summary] + recent

Failure #2 – Context Poisoning:
Problem: Halluzination landet im Context, infiziert alle folgenden Outputs.

# Fix: Fact Checking Layer
def validate_agent_output(output, ground_truth_sources):
    if conflicts_with_sources(output, ground_truth_sources):
        return reject_and_retry(output, 
            reason="Conflicts with established facts")
    return output

Failure #3 – Premature Answers:
Problem: Agent antwortet bevor alle Infos da sind, frühe Antwort bleibt im Context.

# Fix: Scratchpad Pattern (Anthropic "think" tool)
def agent_reasoning(task):
    # Separate workspace für Reasoning
    scratchpad = agent.think(task)  # Not in main context

    # Only final answer in context
    final_answer = agent.conclude(scratchpad)
    return final_answer

Improvement: Bis zu 54% bessere Performance in specialized benchmarks.

Failure #4 – Tool Output Flooding:
Problem: Ungefilterter Tool-Output füllt Context mit noise.

# Fix: Smart Tool Result Filtering
def execute_tool_with_filtering(tool_call):
    raw_result = tool.execute(tool_call)

    # Extract nur relevante Parts
    filtered = extract_relevant_info(raw_result, 
        context=current_task)

    # Store full result extern, return summary
    store_full_result(raw_result, ref_id)
    return {
        "summary": filtered,
        "full_result_ref": ref_id  # Falls Details gebraucht
    }

Failure #5 – Lack of Progressive Disclosure:
Problem: Alles auf einmal laden statt schrittweise explorieren.

# Fix: Layered Information Access
def explore_codebase(initial_query):
    # Layer 1: High-level struktur
    structure = get_directory_tree(max_depth=2)

    # Layer 2: Relevant directories
    relevant_dirs = agent.identify_relevant(structure, initial_query)

    # Layer 3: Specific files
    files = [explore_directory(d) for d in relevant_dirs]

    # Layer 4: File contents (only wenn needed)
    content = [read_file(f) for f in files if agent.needs_details(f)]

Team-Synergie: Diese Patterns sind battle-tested in Production. Implementiert sie systematisch, nicht ad-hoc.

10. Wie messe ich die Effizienz meines Context Managements?

„Was ihr nicht messt, könnt ihr nicht optimieren.“ Die wichtigsten Metriken für Production-Agents:

Core Metrics:

class ContextMetrics:
    def __init__(self):
        self.kv_cache_hit_rate = 0.0  # THE most important metric
        self.avg_context_size = 0
        self.context_overflow_rate = 0.0
        self.tool_result_retention_time = 0
        self.compaction_frequency = 0

    def calculate_efficiency_score(self):
        return (
            self.kv_cache_hit_rate * 0.4 +      # Latency & Cost
            (1 - self.context_overflow_rate) * 0.3 +  # Reliability
            self.context_utilization * 0.3       # Efficiency
        )

KV-Cache Hit Rate (Most Critical):

• Target: >80% für Production
• Impact: Direkt auf Latency & Cost
• Interpretation: Wie oft können Tokens aus Cache wiederverwendet werden?

Context Utilization:

utilization = (
    meaningful_tokens / total_context_tokens
)
# Target: >70% (30% overhead acceptable)

Compaction Effectiveness:

effectiveness = (
    info_retained_after_compaction / 
    context_reduction_ratio
)
# Target: >0.8 (80% Info bei 50% Size-Reduktion)

Cost per Task:

cost_efficiency = (
    task_completion_rate / 
    (avg_tokens_per_task * token_price)
)
# Optimiert über Zeit

Monitoring in Production:

# Real-time Dashboard Metrics
@app.route('/metrics')
def agent_metrics():
    return {
        "context_health": {
            "avg_size": get_avg_context_size(last_24h),
            "overflow_incidents": count_overflows(last_24h),
            "compaction_triggers": count_compactions(last_24h)
        },
        "performance": {
            "kv_cache_hit_rate": get_cache_hit_rate(),
            "avg_latency": get_avg_latency(),
            "cost_per_1k_tasks": calculate_cost_efficiency()
        },
        "quality": {
            "task_completion_rate": get_completion_rate(),
            "retry_rate": get_retry_rate(),
            "context_failure_rate": get_context_failures()
        }
    }

Entscheider-Reporting: Diese Metriken translated zu Business-KPIs:

• KV-Cache Hit Rate → Infrastruktur-Cost
• Context Efficiency → Task-Throughput
• Compaction Effectiveness → System-Reliability

Best Practices aus über 15 Jahren Consulting-Erfahrung

Nach unzähligen Agent-Projekten haben wir bei Never Code Alone folgende Standards etabliert:

✅ Context als Finite Resource behandeln: Jedes Token kostet Attention Budget
✅ Hybrid Retrieval nutzen: RAG für Critical Docs, Just-in-Time für Exploration
✅ Tools radikal vereinfachen: 10-15 core Tools statt 50+ mit Overlap
✅ Proaktiv Compaction implementieren: Nicht warten bis Overflow
✅ Note-Taking von Anfang an: Persistent Memory ist kein Nice-to-have
✅ Metrics kontinuierlich messen: KV-Cache Hit Rate als North Star
✅ Progressive Disclosure favorisieren: Layer by Layer statt All-at-Once

Der entscheidende Vorteil für eure Projekte

Context Engineering ist der Unterschied zwischen „funktioniert im Demo“ und „läuft reliable in Production“. Ein gut-engineerter Context:

• Reduziert Token-Costs um 40-60%
• Verbessert Task-Completion-Rate um 30-50%
• Eliminiert 80% der „Agent vergisst Kontext“-Probleme
• Ermöglicht Long-Horizon Tasks (Stunden statt Minuten)
• Schafft Predictable Performance für Business-Critical Applications

Direkte Unterstützung für euer Team

Ihr wollt Context Engineering optimal in euren Agent-Workflow integrieren? Oder braucht ihr Unterstützung bei der Architektur eurer Production-Agents? Mit über 15 Jahren Expertise in Softwarequalität und Remote Consulting helfen wir euch gerne weiter.

Kontakt: roland@nevercodealone.de

Gemeinsam bauen wir Agents, die nicht nur beeindrucken, sondern liefern – keine theoretischen Konzepte, sondern Production-Ready Systems die funktionieren.

Fazit: Context ist King

Prompt Engineering war gestern. Context Engineering ist heute. Die Fähigkeit, intelligent zu managen welche Information wann in den begrenzten Context-Window eures Agents kommt, entscheidet über Erfolg oder Failure eurer AI-Systeme.

Die Techniken in diesem Post sind battle-tested in Production. Von Claude Code bis zu Custom Enterprise-Agents: Context Engineering ist das Fundament für reliable Agentic Systems.

Startet heute: Reviewed euren aktuellen Agent. Wie groß ist euer durchschnittlicher Context? Wie oft triggered ihr Compaction? Wo verliert ihr Information? Die Antworten auf diese Fragen sind der erste Schritt zu besserer Agent-Performance.

Never Code Alone – Gemeinsam für Production-Ready AI Systems!