Context Engineering: KI-Agenten im Mittelstand stabil halten

Das Problem, das niemand benennt

In KMU-Projekten taucht ein Muster auf, das sich nicht in Hochglanz-Präsentationen findet. Ein Mitarbeiter lässt einen KI-Agenten ein Angebot prüfen, der erste Durchlauf wirkt brillant. Beim zweiten Lauf, eine halbe Stunde später, schreibt derselbe Agent denselben Kunden mit anderem Namen an, vergisst die zuvor erkannten Risiken, schlägt eine Klausel vor, die genau das verbietet, was im Vorgespräch zwingend gefordert wurde. Niemand hat das Modell verändert, niemand hat die Eingabe verändert. Der Agent ist denselben Tag, dieselbe Version, dasselbe Prompt. Trotzdem ist das Ergebnis unbrauchbar.

Solche Vorfälle haben einen Namen. Sie heißen nicht Halluzination, nicht Modellfehler, nicht “die KI spinnt”. Sie heißen Context Degradation, und sie sind das Kernproblem produktiver KI-Anwendungen im Mittelstand.

Worum es bei Context Engineering geht

Context Engineering ist die Disziplin, alles zu kuratieren, was in das begrenzte Aufmerksamkeitsfenster eines KI-Modells eingeht. Systemanweisung, Werkzeugbeschreibungen, vergangene Konversation, abgerufene Dokumente, Werkzeugausgaben. Jeder Token kostet Aufmerksamkeit, und Aufmerksamkeit ist endlich.

Prompt Engineering optimiert eine einzelne Frage. Context Engineering optimiert den gesamten Informationsfluss über eine Session oder ein System hinweg. Der Unterschied ist der zwischen “den richtigen Satz finden” und “den Schreibtisch eines Sachbearbeiters so vorbereiten, dass er ohne Rückfrage entscheiden kann”.

Für mittelständische IT-Verantwortliche ist die wichtigere Botschaft, dass die Qualität eines KI-Assistenten im Tagesbetrieb nicht primär vom Modell abhängt. Sie hängt davon ab, wie der Kontext gepflegt wird.

Fünf Risikomuster, die jeder kennen sollte

In langen Sessions verschlechtert sich KI-Leistung nicht zufällig. Sie folgt fünf wiederkehrenden Mustern.

1. Lost-in-Middle. Modelle achten verlässlich auf den Anfang und das Ende ihres Kontextfensters. Was in der Mitte steht, verliert 10 bis 40 Prozent Trefferquote. Wer ein wichtiges Vertragsdetail in Absatz 14 einer 30-seitigen Vorlage einbettet, riskiert, dass es überlesen wird, selbst wenn es im Kontext steht.

2. Poisoning. Sobald eine falsche Annahme oder eine Halluzination in den Kontext gelangt, verstärkt sie sich selbst. Spätere Antworten beziehen sich auf den falschen Eintrag, korrigierende Hinweise prallen ab. Bei Beratungs-Anwendungen ist das gefährlich, eine falsche Branchenzuordnung im ersten Satz vergiftet die nächsten zwanzig.

3. Distraction. Schon ein einziges irrelevantes Dokument im Kontext senkt die Qualität messbar. Mehrere senken sie stark. KI-Modelle können Inhalte nicht “überblättern”, sie müssen alles verarbeiten, was vor ihnen liegt.

4. Confusion. Wenn ein Kontext Anweisungen aus zwei Aufgaben enthält, mischen Modelle Anforderungen. Ein Agent, der gerade ein technisches Pflichtenheft prüfen soll, antwortet plötzlich im Stil einer Vertriebs-Mail, weil im selben Fenster vorher ein Marketing-Auftrag stand.

5. Clash. Zwei korrekte, aber widersprüchliche Quellen erzeugen unvorhersagbares Verhalten. Veraltete Datenschutzerklärung neben aktueller Fassung, alte Preisliste neben neuer. Das Modell wählt eine Variante, ohne den Konflikt zu signalisieren.

Wer diese fünf Muster kennt, kann KI-Probleme im Mittelstand schneller diagnostizieren als jedes Generaldebugging.

Drei Werkzeuge aus der Praxis

Aus der Open-Source-Bibliothek Agent-Skills-for-Context-Engineering lassen sich drei Werkzeuge ableiten, die direkt im Tagesbetrieb wirken.

Werkzeug eins, strukturierte Kompression

Wenn eine Session zu lang wird, ist die Versuchung groß, alles in eine kurze Zusammenfassung zu pressen. Das ist falsch optimiert. Das richtige Maß ist nicht “Tokens pro Anfrage”, sondern “Tokens pro Aufgabe”. Wenn die Kompression Dateipfade oder Entscheidungen verliert, exploriert der Agent neu und verbraucht am Ende mehr Tokens, als die Kompression sparte.

Praktisch hilft ein festes Skelett mit Pflicht-Abschnitten, die wie eine Checkliste wirken.

Session-Ziel
Bearbeitete Dateien
Getroffene Entscheidungen
Aktueller Stand
Naechste Schritte

Jede Sektion zwingt das Modell, einen kritischen Bereich zu füllen. Lautlose Informationsverluste werden sichtbar, weil eine Sektion entweder Inhalt hat oder offensichtlich leer bleibt.

Werkzeug zwei, Diagnose statt Raten

Wenn ein KI-Agent in einer langen Sitzung plötzlich Mist baut, lautet die übliche Reaktion “neues Chatfenster”. Das funktioniert, aber es lehrt nichts. Sinnvoller ist eine kurze Diagnose nach den fünf Mustern oben. In neun von zehn Fällen passt eines exakt, und die Mitigation ist klar definiert.

Das ist kein KI-Mystizismus. Das ist Methodenwissen.

Werkzeug drei, das Memory-Stockwerk

Die meisten KMU-Projekte starten mit der Annahme, dass ein KI-Agent eine ausgefeilte Memory-Datenbank braucht. In Wirklichkeit zeigen Benchmarks, dass ein Agent mit simpler Dateisystem-Ablage 74 Prozent auf dem LoCoMo-Benchmark erreicht, während spezialisierte Memory-Frameworks bei 68,5 Prozent landen (Stand Mai 2026). Zuverlässige Ablage schlägt komplexes Werkzeug.

Die Eskalation läuft in fünf Stufen. Beginne mit der einfachsten, die noch funktioniert.

1. Working Memory. Aktuelles Kontextfenster, nichts darüber hinaus.
2. Kurzzeitspeicher. Zwischenstände einer Session in einer Datei.
3. Langzeitspeicher. Dateien plus Index, über Sessions hinweg.
4. Entity-Memory. Ein Eintrag pro Person, Firma, Kunde, über Sessions konsistent.
5. Temporal Knowledge Graph. Fakten mit Gültigkeitszeitraum, für Fälle wie “wer war im März 2024 Geschäftsführer”.

Erst wenn Stufe drei nicht mehr reicht, lohnt Schritt vier. Erst wenn Stufe vier nicht mehr reicht, lohnt Stufe fünf. Wer auf der ersten Folie Frameworks wie Mem0, Zep oder Cognee vorgeschlagen bekommt, ohne dass jemand vorher gefragt hat, was die Anwendung braucht, sollte misstrauisch werden.

Ein Praxisbeispiel, das Mokh2-Verfahren

Wir nutzen intern einen Obsidian-Vault namens Mokh2 als langfristigen Wissensspeicher für Projekte, Kunden, Methodik. Der Vault ist im Kern ein Dateisystem-Memory mit Wikilink-Graph-Layer, also exakt die dritte Stufe der oben genannten Eskalation. Wir haben ihn vor knapp zwei Jahren mit klaren Regeln aufgesetzt, lange bevor das Wort Context Engineering im Mainstream auftauchte.

Wesentliche Bausteine, lesbar als Memory-Architektur:

• Eine home.md als zentrale Index-Datei, die zu jedem Sessionstart geladen wird. Sie steht an der attention-favored Position. Lost-in-Middle ist hier ausgeschlossen.
• Eine Open Loops-Sektion führt alle offenen Aufgaben mit Datum und Projekt-Wikilink. Das ist anchored iterative Summarization, lange bevor die Forschung den Begriff prägte.
• Pro Ordner eine README.md, die Zweck, zentrale Dateien und Pflegepunkte erklärt. Das ist Entity-Memory light.
• Tagebuch, Wochenrückblicke, Monatsrückblicke als Memory-Consolidation, täglich, wöchentlich, monatlich.
• Schreibvorgänge laufen über ein Triage-Skript, triviale Einträge gehen direkt ans Dateisystem, komplexe Patches an einen spezialisierten Subagenten. Das ist Just-in-time-Retrieval auf der Schreibseite.

Was dieses Verfahren stark macht, ist nicht das gewählte Tool. Es ist die Disziplin, jeden Eintrag mit Datum, Wikilink und Vertrauensstufe zu versehen. Ein KI-Agent, der mit einem so gepflegten Memory arbeitet, vergisst seltener und verwechselt fast nie.

Was das für mittelständische IT-Strategie bedeutet

Drei Schlussfolgerungen für Geschäftsführer, IT-Leiter und Verantwortliche für KI-Einführung.

Erstens, Modellwechsel überschätzt. Ein Wechsel von einem Modell zum nächsten bringt selten den Sprung, den Anbieter versprechen. Was Sprunghöhe bringt, ist saubere Kontextpflege. Ein gut kuratiertes System mit einem Mittelklasse-Modell schlägt ein chaotisches System mit Spitzenmodell, regelmäßig und nachweisbar.

Zweitens, Memory nicht als Vendor-Frage behandeln. Wer einem Anbieter erlaubt, das Memory-System komplett zu definieren, kauft Lock-in. Wer mit Dateisystem-Memory anfängt und Strukturen selbst pflegt, behält die Hoheit über die eigenen Daten. Eskalation auf spezialisierte Frameworks lohnt, sobald die Anforderung das verlangt, nicht bevor.

Drittens, Methodik vor Tool. Die fünf Degradationsmuster und die vier Mitigation-Buckets (Write, Select, Compress, Isolate) sind tool-unabhängig. Sie funktionieren mit ChatGPT, Claude, Gemini, jedem produktiven KI-System. Wer sie im Team verankert, baut Resilienz auf, die auch dem nächsten Modellwechsel standhält.

Was wir bei Techiota und Netzleiter daraus machen

Wir verankern die drei beschriebenen Werkzeuge als wiederverwendbare Skills in unserer Claude-Code-Umgebung. Bei jedem KI-Beratungsmandat im DACH-Raum prüfen wir zuerst das Memory-Stockwerk des Kunden, danach die Diagnose-Fähigkeit für Degradationsmuster, erst dann sprechen wir über Modelle und APIs.

Wer im Hamburger Mittelstand KI in Eigenleistung aufbaut, kann den ersten Schritt heute machen. Ein Markdown-Vault, klare Indexstruktur, jede Information mit Datum und Quelle. Das kostet keine Lizenz, kein neues Tool, keine Schulung in einer proprietären Sprache. Es kostet Disziplin, und genau dort entscheidet sich, ob KI im Unternehmen ein Werkzeug ist oder ein Showcase.

Lesetipps für Interessierte

• Open-Source-Skills, https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering
• Grundlagenpaper “Lost in the Middle”, Liu et al. 2023
• Anthropic Skill-Konzept für Claude Code