Das Modell verstärken: Kontext, Gedächtnis und Skills
Das beste Ergebnis hängt seltener am Modell als an dem, was es umgibt: was im Kontextfenster landet, was über eine Sitzung hinaus erhalten bleibt und welche Fähigkeiten wiederverwendbar bereitstehen. Diese Seite ist der Schwerpunkt für die Werkzeugschicht über dem Modell – die Praktiken und Werkzeuge, die den Umgang mit KI-Modellen messbar verbessern, ohne das Modell selbst zu ändern: Kontext-Engineering, persistentes Gedächtnis, Wissensgraphen, Skills und die Kontextdateien, die ein Projekt für Agenten lesbar machen. Sie vertieft, was der Überblicksartikel zur Nutzung nur anreißt.
14 Min. Lesezeit
14 Abschnitte
21 Quellen
Stand: 21. Juni 2026
Warum der Umgang über das Modell entscheidet
Zwei Sitzungen mit demselben Modell können meilenweit auseinanderliegen – nicht weil das Modell ein anderes wäre, sondern weil das Drumherum ein anderes war. Genau dort liegt der größte und am meisten unterschätzte Hebel: nicht ein größeres Modell, sondern ein besser kuratierter Kontext, ein verlässliches Gedächtnis und wiederverwendbare Fähigkeiten. Anthropic nennt diese Disziplin Kontext-EngineeringDie Disziplin, gezielt zu kuratieren, welche Tokens während der Inferenz im Kontextfenster stehen – statt möglichst viel hineinzukippen. Kontext ist eine endliche Ressource; Ziel ist „informativ, aber knapp“. Gilt als Fortsetzung des Prompt-Engineerings.Mehr im Wissen → und beschreibt sie als natürliche Fortsetzung des Prompt-Engineerings: weg von der Suche nach den richtigen Worten, hin zur Frage, welche Konfiguration von Kontext das gewünschte Verhalten am wahrscheinlichsten macht.
Der Grund, warum es dafür überhaupt eine Disziplin braucht: Kontext ist eine endliche Ressource. Drei Effekte setzen ihm Grenzen. Erstens Context RotBeobachtung, dass die Treffsicherheit eines Modells beim Wiederfinden von Information sinkt, je mehr Tokens im Kontextfenster stehen – mehr Kontext heißt nicht automatisch mehr Können.Mehr im Wissen → – je mehr Tokens im Fenster stehen, desto unzuverlässiger findet das Modell die relevante Information wieder. Zweitens ein begrenztes „Attention Budget“: Die Aufmerksamkeit eines Transformers verteilt sich über alle Token-Paare (n² Beziehungen bei n Tokens), jeder zusätzliche Token zehrt davon. Drittens der positionsabhängige Qualitätsabfall – Information in der Mitte langer Kontexte geht unter („Lost in the Middle“), und die effektiv nutzbare Kontextlänge liegt regelmäßig unter der beworbenen (RULER).
meist kleiner als die beworbene (RULER); Mitte geht unter (Lost in the Middle)
MerksatzMehr Kontextfenster ist nicht mehr Können. Der Hebel ist nicht das größere Modell, sondern der besser verwaltete Kontext.
Kontext kuratieren: Just-in-time statt vorab
Die erste praktische Frage ist die nach dem Wann: Lädt man allen potenziell relevanten Stoff vorab ins Fenster – oder hält man nur leichte Verweise bereit (Dateipfade, gespeicherte Abfragen, Links) und holt die Inhalte zur Laufzeit gezielt nach? Anthropic empfiehlt für Agenten das Zweite („just in time“). Claude Code etwa schreibt gezielte Abfragen, speichert Zwischenergebnisse und nutzt Kommandos wie head und tail, um große Datenmengen zu sichten, ohne sie je vollständig ins Fenster zu ziehen. Für tempokritische Fälle ist eine Mischform sinnvoll: etwas vorab laden, den Rest autonom erkunden lassen.
Die zweite Frage stellt sich, wenn es eng wird: Compaction. Nähert sich ein Gespräch der Fenstergrenze, fasst man seinen Inhalt zusammen und startet ein frisches Fenster mit dieser Verdichtung. Die Kunst liegt in der Auswahl – was bleibt, was fällt weg; in der Praxis erst auf Vollständigkeit optimieren (nichts Wichtiges verlieren), dann auf Knappheit. Das gemeinsame Ziel all dieser Griffe bringt Anthropic auf eine Faustregel: den Kontext „informativ, aber knapp“ halten.
MerksatzKuratiere den Kontext, statt den Korpus reinzukippen: Verweise statt Volltext, verdichten statt anhäufen.
Kontext am Leben halten: zurücksetzen, verdichten, auslagern
Kuratieren ist die halbe Miete – die andere ist Pflege im laufenden Betrieb. Eine lange Sitzung sammelt zwangsläufig Ballast an: erledigte Nebenstränge, veraltete Tool-Ergebnisse, Fehlversuche. Anthropic ist hier ausdrücklich: Lange Sessions mit irrelevantem Kontext senken die Leistung, und zwischen unzusammenhängenden Aufgaben gehört der Kontext geleert – in Claude Code mit /clear. Eine handfeste Faustregel der offiziellen Best Practices: Wenn zwei Korrekturversuche an derselben Stelle scheitern, hilft kein dritter im selben vollgelaufenen Fenster – besser /clear und ein schärfer formulierter Prompt von vorn.
Wichtig ist die Unterscheidung zwischen Leeren und Verdichten. CompactionNähert sich ein Gespräch der Fenstergrenze, fasst Compaction die bisherige Historie zu einer Zusammenfassung zusammen und führt damit fort – bewusst so gebaut, dass wichtige Entscheidungen erhalten bleiben. Anders als /clear (das alles verwirft) bewahrt es den roten Faden. Auslösbar über /compact.Mehr im Wissen → fasst nahe der Fenstergrenze die bisherige Historie zu einer Zusammenfassung zusammen und führt das Gespräch mit dieser Verdichtung fort – bewusst so gebaut, dass wichtige Entscheidungen erhalten bleiben (auslösbar über /compact, in Claude Code zudem als Auto-CompactionAutomatische Compaction nahe der Fenstergrenze: Der Agent verdichtet die Historie selbsttätig, statt sie auflaufen zu lassen, und behält dabei gezielt wichtige Entscheidungen. In Claude Code Standardverhalten; manuell anstoßbar mit /compact.Mehr im Wissen → automatisch nahe der Grenze). /clear dagegen wirft alles weg. Praktiker propagieren gern „/clear statt Compaction“ als pauschale Regel – das ist zu grob. Anthropic differenziert: /clear nur zwischen wirklich unabhängigen Aufgaben; lebt der Faden weiter, bewahrt Compaction gezielt das, worauf die nächsten Schritte aufbauen. Die in der Szene kursierenden Schwellen („ab 20–25 % Füllstand leeren“, „nicht über ~200 K Token“) sind dabei Praktiker-Faustregeln, keine belegten Werte – sie widersprechen einander sogar und gehören als Heuristik gelesen, nicht als Messpunkt.
Zwei weitere Griffe halten das Fenster sauber, ohne den Faden zu kappen. Context EditingRäumt nahe dem Kontextlimit automatisch veraltete Tool-Aufrufe und -Ergebnisse aus dem Fenster, ohne den Gesprächsfaden zu kappen. In einer Anthropic-Eigenmessung über eine 100-Schritte-Websuche senkte das den Token-Verbrauch deutlich – eine Form laufender Kontext-Hygiene.Mehr im Wissen → räumt nahe dem Limit automatisch veraltete Tool-Aufrufe und -Ergebnisse aus dem Fenster; in einer Anthropic-Eigenmessung über eine 100-Schritte-Websuche senkte das den Token-Verbrauch um 84 % (eine Zahl aus einem spezifischen Eval, kein Allgemeinwert). Und für die schnelle Zwischenfrage gibt es /btw: Die Frage und ihre Antwort wandern nie in die Historie, der eigentliche Arbeitskontext bleibt unberührt. So lässt sich nachschlagen, ohne das Fenster zuzumüllen.
/clear vs. Compaction
leeren zwischen unabhängigen Aufgaben · verdichten, wenn der Faden weiterlebt
Context Editing
Anthropic-Eigenmessung: −84 % Token über 100 Schritte (Eval-Wert)
Szene-Schwellen
„20–25 %“ / „~200 K“ sind Faustregeln, keine belegten Werte
MerksatzLeeren, verdichten oder auslagern – je nachdem, ob der Faden abreißen darf. /clear zwischen unabhängigen Aufgaben, Compaction wenn er weiterlebt, Context Editing fürs Aufräumen unterwegs.
Warum ein größeres Fenster das Problem nicht löst
Es liegt nahe zu hoffen, ein größeres Kontextfenster mache die ganze Pflegearbeit überflüssig. Die Hoffnung trügt. Das namentliche Gegenargument liefert Chroma Research („Context Rot“, Juli 2025): Über 18 Frontier-Modelle hinweg – darunter GPT-4.1, Claude 4, Gemini 2.5 und Qwen3 – wurde die Leistung schlechter, je länger der Input, und zwar auch bei simplen Aufgaben. Der Abfall verläuft nicht gleichmäßig, aber er ist herstellerübergreifend real. Dazu passt der positionsabhängige Effekt aus dem Grundlagen-Abschnitt: Information am Anfang und Ende eines langen Kontexts wird zuverlässig gefunden, in der Mitte deutlich schlechter („Lost in the Middle“) – auch bei explizit auf lange Kontexte ausgelegten Modellen.
Auch der Preis löst die Sache nicht. Das 1-Mio-Token-Fenster (Opus 4.6/4.7/4.8, Sonnet 4.6) ist inzwischen generell zum Standardpreis verfügbar – der frühere Long-Context-Aufschlag oberhalb von 200 K Token (doppelter Input-, anderthalbfacher Output-Tarif) ist entfallen. Das ist eine gute Nachricht für die Rechnung, aber sie ändert nichts an der Qualitätskurve: Fenstergröße und Fensterpreis sind orthogonal zur nutzbaren Treffsicherheit. Ein vielbeachteter YouTube-Kanal feiert das 1-Mio-Fenster als „Sieg über Context Rot“ und beruft sich auf Anbieter-Angaben, wonach die Leistung von 256 K auf 1 Mio Token nur um wenige Prozent abfalle – das ist eine Herstellerzahl mit linearer Annahme, von unabhängigen Long-Context-Messungen nicht bestätigt und in Spannung zur Chroma-Studie, die für alle getesteten Modelle gilt: länger ist schlechter.
MerksatzDas große Fenster gibt dir Spielraum, nicht Sorglosigkeit. Mehr und billigeres Fenster ist nicht mehr Können – die relevanten Tokens gehören weiterhin gezielt platziert (an Anfang und Ende), nicht hineingeschüttet.
Ein oft übersehener Kontextfresser sind die Werkzeuge selbst. Verbindet man ein Modell über das MCP (Model Context Protocol)Offener Standard, über den ein Modell einheitlich externe Werkzeuge und Datenquellen anbindet. Macht Tool-Anbindungen austauschbar statt anbieterspezifisch.Mehr im Wissen → mit externen Tools, werden deren Definitionen in jede Nachricht eingespeist – auch die nie genutzten. Jedes Tool kostet so dauerhaft Kontextlast; Dritt-Benchmarks beziffern die Größenordnung grob auf einige Hundert bis über tausend Token pro Werkzeug, was bei einem überladenen MCP-Sortiment spürbar ins Gewicht fällt. Anthropic empfiehlt darum für Coding-Agenten ausdrücklich CLI-Werkzeuge als die kontext-effizienteste Variante: ein Kommandozeilenaufruf statt eines dauernd mitgeschleppten Schemas.
Daraus eine pauschale Regel „MCP stirbt aus, CLI ist immer überlegen“ zu machen – wie es in der Praktiker-Szene gelegentlich geschieht – greift zu kurz. MCP löst ein anderes Problem (standardisierte, entdeckbare Anbindung), und seine Implementierung in der Breite ist selbst eine offene Streitfrage. Der belastbare Kern ist schmaler und deckt sich mit dem Leitsatz dieses Artikels: Weniger, schärfer beschriebene Werkzeuge schlagen ein üppiges Sortiment – und wo ein schlanker CLI-Aufruf reicht, spart er den Kontext, den ein dauerhaft injiziertes Tool-Schema kostet.
MerksatzVerstärken heißt auch hier verschlanken: weniger, schärfer beschriebene Werkzeuge schlagen ein üppiges Sortiment – und ein CLI-Aufruf statt eines dauerhaft injizierten Tool-Schemas.
Was nicht ins Fenster passt – oder dort nicht dauerhaft Platz verdient –, gehört in ein Gedächtnis außerhalb davon. Das Muster: Der Agent schreibt strukturierte Notizen in einen persistenten Speicher und holt sie später gezielt zurück. Anthropic stellt dafür ein dateibasiertes „Memory“-Tool bereit, mit dem ein Agent Information außerhalb des Kontextfensters ablegen und nachschlagen kann.
Wie viel das ausmacht, zeigt ein anschauliches Beispiel: Ein Claude-Agent, der über Tausende Spielschritte hinweg Pokémon spielt, führt – ohne ausdrückliche Anweisung – präzise Zählstände und zeichnet Karten der erkundeten Gebiete. Solche Langhorizont-Strategien wären unmöglich, wenn alles allein im Kontextfenster gehalten werden müsste. Genau dieses Prinzip steckt hinter den Praktiker-Workflows, die eine Wissens-Datenbank wie Obsidian zum „zweiten Gehirn“ eines Coding-Agenten machen – das Gedächtnis lebt in Dateien, nicht im flüchtigen Kontext.
MerksatzDas Kontextfenster ist Arbeitsspeicher, kein Gedächtnis. Wichtiges gehört in dauerhafte Notizen, die der Agent bei Bedarf zurückholt.
Wissensgraphen: die Codebasis als Karte
Eine besonders wirksame Form solcher externen Struktur ist der WissensgraphWissen als Graph aus Entitäten (Knoten) und Beziehungen (Kanten). Fürs Retrieval (GraphRAG) erlaubt das „globale“ Schließen über einen Korpus und verbindet verstreute Fakten, die reine Vektorsuche übersieht.Mehr im Wissen →. Statt einen Korpus als losen Haufen von Textschnipseln zu behandeln (wie klassisches RAGRetrieval-Augmented Generation: dem Modell werden zur Anfrage passende Textstellen aus einer eigenen Wissensquelle beigelegt, damit es daraus antwortet statt nur aus dem Training. Reduziert Halluzinationen und hält Wissen aktuell.Mehr im Wissen → mit reiner Vektorsuche), organisiert man ihn als Graph aus Entitäten (Knoten) und Beziehungen (Kanten). Microsofts GraphRAG zeigte, dass ein Modell über einen solchen Graphen „global“ schließen und verstreute Fakten verbinden kann, die eine reine Ähnlichkeitssuche übersieht – es bekommt eine Karte des Korpus statt einzelner Fundstücke.
Für den Alltag mit Coding-Agenten bringt das ein Open-Source-Werkzeug wie Graphify auf den Punkt: Man richtet es als Skill auf einen Ordner – Code, SQL-Schemas, Doku, PDFs, sogar Bilder – und es destilliert daraus einen abfragbaren Wissensgraphen, den der Agent als Navigationskarte nutzt. Der Graph lässt sich nach Obsidian, als Neo4j-Export oder über einen MCP-Server bereitstellen. Das Projekt wirbt mit „71,5× weniger Tokens pro Abfrage“ gegenüber dem Einlesen der Rohdateien – eine Eigenangabe (Tier C), nicht unabhängig nachgemessen. Die Richtung ist plausibel (eine Karte ist billiger als das Gebiet), die genaue Zahl gehört vor dem Verlassen darauf selbst geprüft.
Graphify als Claude-Code-Skillbash
# einmalig installieren
pip install graphifyy && graphify install
# aktuellen Ordner zu einem Wissensgraphen verarbeiten
/graphify .
# externe Quelle (Doku, Repo, Artikel) dazuholen
/graphify add https://docs.example.com
Brauche ich überhaupt RAG? Die Entscheidungs-Leiter
Bevor du einen Wissensgraphen baust – oder auch nur eine Vektordatenbank aufsetzt –, lohnt die unbequeme Vorfrage: Braucht dein Projekt das überhaupt? RAGRetrieval-Augmented Generation: dem Modell werden zur Anfrage passende Textstellen aus einer eigenen Wissensquelle beigelegt, damit es daraus antwortet statt nur aus dem Training. Reduziert Halluzinationen und hält Wissen aktuell.Mehr im Wissen → und Graphen sind Werkzeuge, keine Pflicht. Die nützlichste Sicht ist eine Leiter, die man nur so weit hochsteigt, wie die Aufgabe es erzwingt – jede Stufe kostet mehr Aufbau und Pflege als die darunter.
Stufe eins ist gar kein Retrieval: Passt alles Nötige ins KontextfensterDie maximale Textmenge (in Tokens), die ein Modell pro Anfrage gleichzeitig „im Blick“ hat – Eingabe plus bisheriger Verlauf. Ist es voll, fällt Älteres aus dem Kontext.Mehr im Wissen →, gib es dem Modell einfach mit. Das skaliert aber schlecht. Ein großes Fenster ersetzt RAG bei Menge nicht – langer Kontext bedeutet drastisch höhere Kosten und Latenz pro Anfrage, und bei zehntausenden Anfragen am Tag wird genau das zum Engpass. Robuster als „immer alles hineinwerfen“ ist ein Routing: Das System entscheidet pro Frage, ob die Volltext-Antwort reicht oder ob gezieltes Retrieval nötig ist (das Self-Route-Prinzip aus der Long-Context-vs.-RAG-Forschung).
Stufe zwei ist ein Datei- oder Index-System mit agentischer Suche – oft die unterschätzte Antwort. Stufe drei ist klassisches RAG für großen, wechselnden Faktenbestand. Stufe vier ist der Wissensgraph für korpusweites Verstehen. Die folgenden Abschnitte gehen die Stufen der Reihe nach durch – und schließen mit einer Faustregel, die die Wahl nach Aufgabe zusammenfasst.
Wann ein Datei-Index reicht: agentische Suche statt Vektor-DB
Die zweite Stufe wird gern übersprungen, dabei trägt sie erstaunlich weit. Statt einen Korpus vorab in Vektoren zu zerlegen, lässt man das Modell wie ein erfahrener Mensch suchen: per Agentische SucheEin Agent navigiert eine Wissens- oder Codebasis wie ein Mensch – per Stichwortsuche (grep), Datei-Glob und gezieltem Lesen – statt über einen vorab gebauten Vektor-Index. Vorteil: kein Index zu pflegen, keine veralteten Treffer; setzt aber eine gute Struktur voraus, damit der Agent weiß, wo er suchen soll.Mehr im Wissen → – grep, glob, eine Datei öffnen, lesen, weiterspringen. Anthropic lässt Claude Code bewusst genau so über große Codebasen navigieren, ohne Embedding-Index und Vektordatenbank. Im eigenen Test schlug die agentische Suche RAG deutlich; die Begründung ist nüchtern: kein Index, der gebaut, gepflegt und re-indexiert werden muss, keine veralteten Treffer aus einem alten Index, eine sauberere Deployment-Story. Der Preis dafür steht offen dabei – der Agent braucht eine gute Struktur und eine aussagekräftige CLAUDE.md, damit er weiß, wo er suchen soll.
Dasselbe Muster jenseits von Code: Andrej Karpathys „LLM-Wiki“ ist ein schlichtes Markdown- und Dateisystem mit Index-Dateien, das ein Modell selbst pflegt – ganz ohne Vektordatenbank und Embeddings. Bei kleinem Maßstab genügt die Index-Datei; eine optionale Hybrid-Suche oder echtes RAG kommt erst ins Spiel, wenn das Wiki über grob hundert(e) Quellen hinauswächst. Praktiker ziehen daraus eine bewusst zugespitzte Faustregel: Für viele kleinere Wissensbestände sei ein Datei-Index plus agentische Suche die „99-Prozent-Lösung“, ein vollwertiges RAG-System brauche man oft gar nicht. Das ist eine attribuierte Praktiker-Position, kein gemessener Wert – und sie sagt nicht „RAG ist überflüssig“, sondern „fang weiter unten auf der Leiter an, als du denkst“.
MerksatzBevor du Vektoren baust: Lass den Agenten erst wie ein Mensch suchen (grep/glob/lesen). Für kleine Bestände trägt ein guter Datei-Index mit agentischer Suche überraschend weit.
Wann sich echtes RAG lohnt – und wann der Graph trägt
Ab Stufe drei wird RAG seine eigene Investition wert. Die belastbare Grenze macht sich nicht an einer fixen Korpusgröße fest, sondern an drei Bedingungen: Das Wissen ändert sich laufend (du willst es nicht ins Modell trainieren), der Bestand ist zu groß fürs Fenster, und du stellst viele Anfragen, bei denen Kosten und Latenz pro Anfrage zählen. (Eine im Umlauf befindliche Schwelle von „500–2.000 Seiten“ stammt aus Praktiker-Kreisen und ist nirgends unabhängig belegt – sie taugt als grobes Bauchgefühl, nicht als harte Linie.) Für die Heuristik dahinter gilt unverändert: RAG für Wissen und Fakten, die sich ändern; Fine-tuning erst für Verhalten, Stil und Format – und vorher Prompting und RAG ausreizen.
Die vierte Stufe, den WissensgraphWissen als Graph aus Entitäten (Knoten) und Beziehungen (Kanten). Fürs Retrieval (GraphRAG) erlaubt das „globale“ Schließen über einen Korpus und verbindet verstreute Fakten, die reine Vektorsuche übersieht.Mehr im Wissen → (siehe Abschnitt davor), rechtfertigt eine bestimmte Frageform, nicht bloß ein großer Korpus. Microsofts GraphRAG-Arbeit zeigt den Vorteil dort, wo es um globales „Sensemaking“ über einen ganzen Korpus geht – „Was sind die Hauptthemen?“, „Wie hängt alles zusammen?“ –, nachgewiesen für Datensätze im Bereich von rund einer Million Token, mit besseren, vollständigeren und vielfältigeren Antworten als reine Vektorsuche, die nur fragmentierte Schnipsel zieht. Für ein punktuelles Faktum („Wie lautet Parameter X?“) ist der Graph dagegen Overkill.
Und er ist nicht umsonst zu haben. Den Vorteil bei der Abfrage erkauft man mit teurem Aufbau: Den Index baut ein LLM, das jeden Quell-Abschnitt mehrfach aufruft, um Entitäten und Beziehungen zu extrahieren – laut Microsoft macht allein diese Extraktion rund 75 % der Indexierungskosten aus. Tier-C-Stimmen feiern die Token-Ersparnis pro Abfrage; die Primärquellen betonen die Kosten beim Bauen. Beide Seiten gehören in die Rechnung: Der Graph spart womöglich bei jeder Frage, kostet aber kräftig, bevor die erste Frage gestellt ist.
Und bevor du auf diese vierte Stufe steigst, lohnt der Gegencheck: Oft ist nicht der Graph die Antwort, sondern besseres RAG. Anthropics Contextual RetrievalRAG-Verbesserung von Anthropic: Jedem Textabschnitt wird vor dem Einbetten ein kurzer, modellgenerierter Kontextsatz vorangestellt und mit Stichwortsuche (BM25) kombiniert. Senkt fehlgeschlagene Retrievals um bis zu 49 %, mit Reranking um bis zu 67 % – besseres RAG statt Wissensgraph.Mehr im Wissen → zeigt das konkret – stellt man jedem Textabschnitt vor dem Einbetten einen kurzen, modellgenerierten Kontextsatz voran und kombiniert das mit Stichwortsuche (BM25), sinkt die Rate fehlgeschlagener Retrievals um bis zu 49 %, mit nachgeschaltetem Reranking um bis zu 67 %. Das deckt sich mit der Hybrid-Search-und-Reranking-Linie aus dem Nutzungsartikel: Bedeutungsnähe finden Embeddings, Relevanz sichert erst die Kombination aus Stichwort, Semantik und Reranker. Die verbreitete These „naives Vektor-RAG ist 2026 überholt, nimm einen Graphen“ kommt oft von Anbietern mit eigenem Graph-Produkt – und steht in Spannung dazu, dass Anthropic für Code ganz ohne Vektor-Index arbeitet und mit Contextual Retrieval zugleich zeigt, dass schlechtes RAG sich verbessern statt ersetzen lässt. Die Auflösung ist weder „RAG ist tot“ noch „Graph für alles“, sondern Werkzeugwahl nach Aufgabe: Code-Navigation per agentischer Suche, punktuelles Faktum per gutem Vektor-RAG, korpusweites Verstehen per Graph, Verhalten und Stil per Fine-tuning.
MerksatzSteig die Leiter nur so hoch, wie die Aufgabe es erzwingt – erst Kontext, dann Datei-Index und agentische Suche, dann gutes RAG; der Wissensgraph trägt das korpusweite Verstehen, nicht das nächste Faktum.
Wiederkehrende Abläufe muss man nicht jedes Mal neu erklären. Ein Agent SkillWiederverwendbares Können als Ordner mit einer SKILL.md (Name, Beschreibung, Anleitung, optional Skripte). Die vollen Anweisungen lädt der Agent erst, wenn eine Aufgabe zur Beschreibung passt (Progressive Disclosure) – viele Skills bei wenig Kontextkosten.Mehr im Wissen → verpackt ein Können als Ordner mit einer SKILL.md: ein YAML-Kopf mit Name und Beschreibung, dazu die Anleitung und optional Skripte, Vorlagen oder Referenzdateien. Der Clou ist die schrittweise Offenlegung (Progressive Disclosure): Der Agent sieht zunächst nur Name und Beschreibung; die vollen Anweisungen lädt er erst, wenn eine Aufgabe dazu passt. So lassen sich viele Skills bereithalten, ohne den Kontext im Leerlauf zu fluten.
Anthropic hat das SKILL.md-Format als offenen Standard veröffentlicht; es wird inzwischen über mehrere Agenten-Produkte hinweg unterstützt. In der Praktiker-Szene wird daraus oft eine ganze „Agentic-OS“-Schicht gebaut, in der Skills als anklickbare Knöpfe für nicht-technische Teammitglieder erscheinen – ein bequemes Frontend, aber dasselbe Fundament: ein klar beschriebenes, wiederverwendbares Können statt eines Wegwerf-Prompts.
Den dauerhaftesten Kontext schreibt man ins Projekt selbst. Eine AGENTS.mdMarkdown-Datei im Projekt, die Coding-Agenten zu Beginn jeder Sitzung lesen – Konventionen, Architektur, Ge- und Verbote („README für Maschinen“). AGENTS.md ist der offene, herstellerübergreifende Standard; CLAUDE.md ist Anthropics Variante.Mehr im Wissen → (Anthropics Variante heißt CLAUDE.md) ist eine Markdown-Datei, die ein Coding-Agent zu Beginn jeder Sitzung liest – ein „README für Maschinen“ mit Konventionen, Architektur, Befehlen und ausdrücklichen Ge- und Verboten. Statt jede Sitzung neu zu erklären, wie das Projekt tickt, steht es versioniert im Repo.
AGENTS.md ist dabei der herstellerübergreifende offene Standard, im August 2025 gemeinsam von OpenAI, Google, Cursor, Factory und Sourcegraph formalisiert und inzwischen in zehntausenden Repositories im Einsatz. Das Format ist bewusst schlicht – reines Markdown ohne erzwungene Struktur; in Monorepos gilt die jeweils nächstgelegene Datei (hierarchisch). Es ist Kontext-Engineering als festgehaltenes Artefakt: einmal sauber geschrieben, profitiert jede künftige Sitzung.
Ein wichtiger Vorbehalt: Mehr ist hier nicht besser. Eine kontrollierte Studie (Gloaguen et al., „Evaluating AGENTS.md“, Februar 2026) ließ vier Coding-Agenten über hunderte echte GitHub-Issues laufen – und fand, dass automatisch generierte Kontextdateien die Erfolgsrate im Schnitt um rund 3 % senkten und selbst handgeschriebene bestenfalls 4 % brachten, bei jeweils über 20 % höheren Kosten. Der Grund liegt nicht nur am längeren Prompt: Die Datei verleitet den Agenten auch zu mehr unnötigem Stöbern. Die Lehre ist also nicht „keine AGENTS.md“, sondern eine knappe, handkuratierte – nur die wirklich nötigen Regeln, keine automatisch erzeugte Wand aus Selbstverständlichkeiten.
Wird eine Aufgabe zu groß für ein sauberes Fenster, hilft Arbeitsteilung. Statt einen einzigen Agenten den Zustand über ein ganzes Projekt schleppen zu lassen, übernehmen spezialisierte SubagentSpezialisierter Hilfs-Agent mit eigenem, sauberem Kontextfenster: Ein Leit-Agent koordiniert den Plan, Subagenten erledigen Teilaufgaben und liefern nur eine verdichtete Zusammenfassung (oft 1.000–2.000 Tokens) zurück – Kontext-Isolation als Arbeitsteilung.Mehr im Wissen → fokussierte Teilaufgaben mit jeweils frischem Kontextfenster. Der Leit-Agent hält nur den groben Plan; jeder Subagent erledigt seine Tiefenarbeit isoliert und liefert lediglich eine verdichtete Zusammenfassung zurück (oft 1.000–2.000 Tokens). Der detaillierte Such- und Lese-Kontext bleibt in den Subagenten gekapselt – eine klare Trennung der Zuständigkeiten.
Das ist mächtig, aber nicht gratis: Multi-Agenten-Systeme verbrauchen ein Vielfaches an Tokens, und der Mehrwert lohnt nur, wenn der Aufgabenwert das trägt. Wann sich parallele Agenten auszahlen – und wann ein linearer Ablauf mit Verdichtungsschritt die bessere Wahl ist – behandelt der Agenten-Artikel im Detail.
So verlockend die Werkzeuge sind – der eigentliche Gewinn steckt in der Disziplin dahinter, nicht im einzelnen Tool. Kontext kuratieren, Zustand verlässlich persistieren, Zuständigkeiten isolieren, Können wiederverwendbar machen: Diese Prinzipien tragen, gleich ob man sie mit Graphify, dem Memory-Tool oder einer handgepflegten AGENTS.md umsetzt. Das Ökosystem ist jung und schnelllebig; viele Werkzeuge überlappen, und nicht jedes hält, was sein Titel verspricht.
Zwei Warnungen gehören dazu. Erstens: Werbezahlen aus Tier-C-Quellen (etwa „71,5× weniger Tokens“ oder „77 % günstiger“) sind Behauptungen, keine Messungen – im eigenen Projekt nachprüfen, bevor man darauf baut. Zweitens, scheinbar paradox: Mehr Werkzeuge machen einen Agenten oft schlechter, nicht besser. Jedes zusätzliche Tool bläht Kontext und Entscheidungsraum; ein einzelnes, sauber beschriebenes Werkzeug schlägt häufig ein überladenes Sortiment. Verstärken heißt hier auch verschlanken.
MerksatzNicht das Modell smarter machen, sondern den Kontext enger führen: kuratieren, erinnern, isolieren, wiederverwenden – und jede Werbezahl selbst nachmessen.