Context, Memory, Skills und Agents verstehen

Wer heute mit einem Coding Agent arbeitet, begegnet innerhalb weniger Minuten einer ganzen Reihe von Begriffen: Context, Memory, Agent Files, Skills, Tools und natürlich Agents selbst. Dazu kommen produktspezifische Namen wie AGENTS.md, CLAUDE.md, Custom Instructions oder SKILL.md.

Auf den ersten Blick klingt vieles davon wie unterschiedliche Bezeichnungen für dasselbe:

Informationen, die das Modell irgendwie kennt.

Für eine erste Benutzung mag diese Vorstellung ausreichen. Sobald wir aber verstehen wollen, warum ein Agent bestimmte Informationen berücksichtigt, andere nicht mehr zur Verfügung hat, Regeln unterschiedlich zuverlässig befolgt oder bei einer Aufgabe plötzlich einen bestimmten Workflow verwendet, wird sie zu ungenau.

Die interessantere Frage lautet deshalb:

Woher weiß ein Coding Agent eigentlich, was er wissen und wie er arbeiten soll?

Eine einfache Metapher hilft dabei erstaunlich weit. Stellen wir uns keinen künstlichen Menschen vor, sondern einen Arbeitsplatz mit einem Schreibtisch. Das Modell bringt bereits Wissen und Fähigkeiten mit. Auf dem Schreibtisch liegen die Informationen, die für die aktuelle Arbeit verfügbar sind. Daneben gibt es ein Archiv, Regeln für diesen Arbeitsplatz, Playbooks für bestimmte Tätigkeiten und Werkzeuge, mit denen etwas ausgeführt werden kann.

Vereinfacht sieht das so aus:

Model
=
bereits vorhandenes Wissen und Fähigkeiten

Context
=
was gerade auf dem Schreibtisch liegt

Memory
=
Archiv oder Notizbuch,
aus dem Informationen später wieder
auf den Schreibtisch geholt werden können

Agent Files
=
Regeln des Arbeitsplatzes

Skills
=
Playbooks oder Arbeitsanweisungen
für bestimmte Arten von Aufgaben

Tools
=
Werkzeuge, mit denen gearbeitet werden kann

Agent
=
das System, das einen Auftrag verfolgt
und diese Mechanismen zusammen verwendet

Diese Metapher beschreibt Rollen innerhalb eines Systems. Sie ist ausdrücklich keine Behauptung darüber, dass ein LLM wie ein menschliches Gehirn arbeitet oder ein Agent ein künstlicher Mitarbeiter mit menschlichem Gedächtnis wäre.

Gerade diese Einschränkung ist wichtig, weil viele Missverständnisse entstehen, sobald technische Mechanismen zu direkt mit menschlicher Kognition gleichgesetzt werden.

Warum Context kein Kurzzeitgedächtnis ist

Context wird häufig als Kurzzeit- oder Arbeitsgedächtnis eines LLMs beschrieben. Als grobe Alltagserklärung ist nachvollziehbar, woher diese Analogie kommt: Informationen stehen für eine begrenzte Verarbeitung zur Verfügung und beeinflussen, was als Nächstes geschieht.

Technisch führt die Analogie aber schnell in die falsche Richtung. Menschliches Arbeitsgedächtnis ist ein dynamischer biologischer Zustand. Inhalte müssen aktiv aufrechterhalten werden, können verblassen und werden durch zahlreiche kognitive Prozesse beeinflusst.

LLM-Context besteht dagegen aus Informationen, die einer Modellverarbeitung explizit zur Verfügung gestellt werden. Solange eine Information im aktuellen Context enthalten ist, kann sie prinzipiell berücksichtigt werden. Daraus folgt allerdings nicht, dass das Modell jede Information darin gleich zuverlässig findet, gewichtet oder für seine Antwort verwendet.

Deshalb funktioniert der Schreibtisch als Metapher besser. Auf einem Schreibtisch kann ein Dokument liegen, ohne dass die Person gerade auf die entscheidende Zeile darin achtet. Ein sehr großer Schreibtisch kann sogar so voll werden, dass relevante Informationen zwischen vielen weniger wichtigen Dokumenten schwerer zur Geltung kommen.

Auf den Schreibtisch passen und den Inhalt auf dem Schreibtisch zuverlässig beachten sind zwei verschiedene Eigenschaften.

Was das Model bereits mitbringt

Bevor wir Material auf den Schreibtisch legen, existiert bereits das Modell selbst. Seine Model Weights sind durch Training und Post-Training entstanden und bestimmen einen wesentlichen Teil dessen, was das Modell bereits kann und welche Muster es gelernt hat.

In unserer Arbeitsplatz-Metapher können wir uns das ungefähr als Ausbildung, Erfahrung und bereits internalisiertes Wissen vorstellen. Auch diese Analogie beschreibt nur die Rolle. Ein Modell erinnert sich nicht biologisch an eine Ausbildung und besitzt keine Berufserfahrung im menschlichen Sinn.

Technisch wichtiger ist eine andere Abgrenzung: Wenn wir einem Modell zusätzliche Informationen im Context bereitstellen oder ein Memory-System verwenden, verändern wir normalerweise nicht seine Model Weights. Das Modell wird dadurch nicht neu trainiert.

Wenn ein Coding Agent sich also merkt, dass ein bestimmtes Repository pnpm statt npm verwendet, hat das Basismodell nicht plötzlich dauerhaft etwas dazugelernt. Ein umgebendes System hat diese Information gespeichert und kann sie später wieder zur Verfügung stellen.

Context – was gerade auf dem Schreibtisch liegt

Context bezeichnet vereinfacht die Informationen, die dem Modell für die aktuelle Verarbeitung zur Verfügung stehen.

Dazu kann zunächst die sichtbare Nutzeranfrage gehören. In einem realen Agent-System ist sie aber häufig nur ein kleiner Teil. Zusätzlich können System Instructions, der bisherige Gesprächsverlauf, Repository-Dateien, Suchergebnisse, Tool-Beschreibungen, Testergebnisse, Compilerfehler, API-Antworten, geladene Agent Files, aktivierte Skills und abgerufene Memories in den aktuellen Context gelangen.

Ein Coding Agent, der einen fehlgeschlagenen Test untersucht, könnte beispielsweise gleichzeitig mit folgenden Informationen arbeiten:

Aufgabenbeschreibung
+
relevante Repository-Dateien
+
Architekturregeln
+
Testcode
+
Fehlerausgabe des letzten Testlaufs
+
vorherige Änderungen
+
aktueller Arbeitsauftrag

Das Modell muss diese Informationen nicht während seines Trainings gesehen haben. Wenn wir ihm die Dokumentation einer neuen Bibliothek oder einen Ausschnitt aus einem internen Repository bereitstellen, kann es diese Inhalte innerhalb der aktuellen Verarbeitung verwenden.

Damit erhalten wir eine ziemlich brauchbare Kurzform:

Context ist das, was gerade auf dem Schreibtisch liegt.

Das klingt einfacher, als Agent-Oberflächen es manchmal erscheinen lassen. Eine Datei, die ein Agent öffnet, wird nicht automatisch zu neuem Wissen in den Model Weights. Ein Suchergebnis ebenfalls nicht. Beide Mechanismen sorgen zunächst dafür, dass zusätzliche Informationen für eine Modellverarbeitung verfügbar werden.

Context Window – wie groß ist der Schreibtisch?

Im zweiten Artikel dieser Serie haben wir das Context Window bereits als technische Größenbegrenzung kennengelernt. Vereinfacht beschreibt es, wie viel Material innerhalb einer Modellverarbeitung berücksichtigt werden kann. Die genaue Aufteilung des Token-Budgets zwischen Eingabe, internem System-Context und Ausgabe hängt dabei vom jeweiligen Modell und Produkt ab.

Mit unserer Metapher ist das die Größe des Schreibtisches.

Ein größerer Schreibtisch ist offensichtlich nützlich. Ein Agent kann mehr Code, mehr Gesprächsverlauf oder mehr Dokumentation gleichzeitig berücksichtigen, bevor Informationen entfernt, zusammengefasst oder erneut geladen werden müssen.

Die Größe allein sagt jedoch wenig darüber aus, wie gut der Arbeitsplatz vorbereitet ist. Ein Schreibtisch mit zehntausend unsortierten Seiten enthält möglicherweise alle Informationen, die wir brauchen. Ein kleinerer Schreibtisch mit genau der relevanten API-Dokumentation, den betroffenen Modulen, den Architekturregeln und dem aktuellen Testfehler kann für die konkrete Aufgabe trotzdem besser sein.

Für praktische Agent-Systeme lohnt es sich deshalb, mehrere Fragen auseinanderzuhalten: Wie viel Context kann technisch aufgenommen werden? Welche Informationen davon sind für die Aufgabe relevant? Welche werden tatsächlich ausgewählt und zu welchem Zeitpunkt bereitgestellt? Und wie zuverlässig nutzt das Modell schließlich genau diese Informationen?

Ein großes Context Window beantwortet hauptsächlich die erste Frage.

Context Engineering – was kommt auf den Schreibtisch?

Damit sind wir wieder bei einem Begriff, der inzwischen häufig als Context Engineering bezeichnet wird.

Gemeint ist nicht, möglichst viel Material in einen möglichst großen Prompt zu kopieren. Bei großen Codebases besteht ein erheblicher Teil der Arbeit vielmehr darin, relevante Informationen auszuwählen, sinnvoll zu strukturieren und genau dann bereitzustellen, wenn sie gebraucht werden. Anthropic beschreibt dafür die Kombination von klassischem Retrieval mit einem „just in time“-Ansatz, bei dem weitere Informationen erst während der Arbeit über Dateien, Suche oder Tools nachgeladen werden. [8]

Für eine konkrete Änderung können das beispielsweise die betroffenen Module, aktuelle Tests, ein API Contract, wenige Architekturregeln und die Ausgabe eines fehlgeschlagenen Builds sein. Ein vollständiges Monorepo, sämtliche ADRs der letzten fünf Jahre und jede jemals dokumentierte Coding Convention würden zwar mehr Information liefern, aber nicht automatisch besseren Context.

Context Engineering entscheidet, was auf dem Schreibtisch landet.

Wie man das systematisch gestaltet, ist ein eigenes Thema. Für unser mentales Modell reicht zunächst die Erkenntnis, dass Context keine statische Wissensmenge ist. Agent-Systeme stellen ihn während ihrer Arbeit fortlaufend zusammen.

Memory – das Archiv neben dem Arbeitsplatz

Damit können wir Memory sauberer einordnen.

Wenn ein Agent-System Informationen über einen einzelnen Arbeitsschritt oder eine Sitzung hinaus aufbewahren soll, müssen diese irgendwo gespeichert werden. Das kann beispielsweise eine Datei, eine Datenbank, ein Suchindex oder ein anderer Persistenzmechanismus sein. Später kann das System relevante Informationen wiederfinden und erneut für die aktuelle Arbeit verfügbar machen.

Vereinfacht:

Memory
↓
Retrieval
↓
Context
↓
Model

Memory ist deshalb weniger das menschliche Langzeitgedächtnis des Modells als ein Archiv oder Notizbuch neben dem Arbeitsplatz.

Darin könnte beispielsweise stehen, dass ein Nutzer eine bestimmte Ausgabeform bevorzugt, dass sich ein Team gegen eine technische Variante entschieden hat, dass ein ungewöhnlicher Build-Schritt erforderlich ist oder an welchem Stand eine längerfristige Aufgabe zuletzt unterbrochen wurde.

Entscheidend ist die Richtung: Solange eine Information lediglich im Archiv liegt, arbeitet das Modell nicht automatisch damit. Das Agent-System muss sie finden und in geeigneter Form wieder auf den Schreibtisch bringen.

Context ist verfügbarer Arbeitsinhalt. Memory ist gespeicherte Information, die später wieder zu Context werden kann.

Die Produktbegriffe sind allerdings nicht vollständig einheitlich. Claude Code bezeichnet beispielsweise CLAUDE.md-Dateien und Auto Memory ausdrücklich als zwei komplementäre Memory-Systeme. Gleichzeitig stellt Anthropic klar, dass beide letztlich als Context behandelt werden: CLAUDE.md enthält von Menschen gepflegte persistente Instruktionen, während Auto Memory vom Agenten selbst gespeicherte Learnings und Muster enthält. [3]

Für unser mentales Modell ist es deshalb hilfreicher, nach der Rolle zu unterscheiden. Von Menschen gepflegte Repository- und Projektregeln behandeln wir im Folgenden als Agent Files. Mit Memory meinen wir gespeicherte Informationen, die über Arbeitsschritte oder Sitzungen hinweg erhalten bleiben und später wieder verfügbar gemacht werden können.

Das sind Kategorien für unser Verständnis, keine Naturgesetze der Anbieter. Technisch bleibt jedoch die wichtigste Abgrenzung bestehen: Das Speichern einer solchen Information verändert normalerweise nicht die Model Weights. Es handelt sich um Persistenz und erneute Bereitstellung, nicht automatisch um Training.

Agent Files – wie arbeiten wir hier?

Bei Agent Files wird die Terminologie noch deutlicher produktspezifisch.

AGENTS.md ist inzwischen ein offenes Format für Instruktionen an Coding Agents. Es versteht sich selbst sinngemäß als eine Art README für Agents: ein vorhersehbarer Ort für Build-Kommandos, Tests, Konventionen und projektspezifischen Context. Das Format wird inzwischen von zahlreichen Coding-Agent-Werkzeugen unterstützt. [1]

GitHub Copilot kennt daneben eigene Repository Instructions über .github/copilot-instructions.md und pfadspezifische NAME.instructions.md-Dateien. Für Agents unterstützt GitHub außerdem verschachtelte AGENTS.md-Dateien; alternativ können im Repository-Root auch CLAUDE.md oder GEMINI.md verwendet werden. [2]

Claude Code wiederum arbeitet nativ mit CLAUDE.md und .claude/rules/. Eine vorhandene AGENTS.md liest Claude Code nicht automatisch als eigenes Format, die aktuelle Dokumentation empfiehlt aber ausdrücklich, sie aus einer CLAUDE.md zu importieren, wenn ein Repository dieselben Regeln mit mehreren Agent-Systemen teilen möchte. [3]

Es wäre deshalb wenig hilfreich, „Agent File“ als Namen eines einzelnen Standards zu behandeln. Für diesen Artikel verwende ich den Begriff als Sammelbezeichnung für Dateien, mit denen wir einem Coding Agent projektspezifische Regeln und Arbeitskontext geben.

Die Kernfrage lautet:

Wie arbeiten wir in diesem Projekt?

Ein solches File kann Architekturregeln, Namenskonventionen, Dependency-Grenzen, Teststrategien, Build-Kommandos oder andere projektspezifische Entscheidungen enthalten.

Für ein Angular-Projekt könnte ein Ausschnitt beispielsweise so aussehen:

# Frontend Architecture

- Components orchestrieren keine Business-Logik.
- Domain State liegt unter `domain/+state`.
- HTTP-Zugriffe gehören nach `infrastructure`.
- Verwende Signals für lokalen State.
- Neue Features benötigen Unit Tests.

Diese Regeln beschreiben noch keinen konkreten Ablauf zum Implementieren eines Features. Sie sagen dem Agenten vielmehr, welche Grenzen innerhalb dieses Repositories gelten.

Ein anderes Projekt könnte vollkommen legitimerweise NgRx verwenden, HTTP-Zugriffe anders schneiden oder andere Testgrenzen definieren. Genau deshalb ist ein gutes Agent File keine Sammlung allgemeiner Aussagen darüber, wie Softwareentwicklung immer funktionieren sollte.

Es beschreibt, wie gute Arbeit hier aussieht.

Agent Files sind kein universelles Best-Practice-Paket

An dieser Stelle beginnt erstmals etwas, das über reine Begriffserklärung hinausgeht.

Es ist verlockend, ein umfangreiches AGENTS.md, CLAUDE.md oder eine Sammlung von Copilot Instructions aus einem erfolgreichen Projekt zu übernehmen. Schließlich hat jemand die Arbeit bereits investiert, und viele Regeln klingen auf den ersten Blick vernünftig.

Das Problem liegt nicht darin, sich von guten Ideen inspirieren zu lassen. Es entsteht, wenn wir projektspezifische Entscheidungen mit universellen Best Practices verwechseln.

Ein Repository kann bewusst Feature-Slices verwenden, während ein anderes technisch nach Layern organisiert ist. Ein Team kann Signals als primäres State-Modell verwenden, ein anderes NgRx. In einem Projekt sind Integrationstests die wichtigste Sicherheitsgrenze, in einem anderen existiert eine wesentlich stärkere Unit-Test-Strategie. Selbst identische Frameworks führen nicht automatisch zu identischen Architekturregeln.

Wer einem Agenten eine fremde Regel sehr präzise vorgibt, bekommt deshalb nicht automatisch bessere Ergebnisse. Unter Umständen bekommt er lediglich die falsche Regel besonders konsequent angewendet.

Agent Files sind kein universelles Best-Practice-Paket. Sie müssen die tatsächliche Architektur und Arbeitsweise des Projekts beschreiben.

Skills – wie erledige ich diese Art von Aufgabe?

Ein Skill beantwortet eine andere Frage.

Während das Agent File beschreibt, wie in einem bestimmten Umfeld gearbeitet wird, beschreibt ein Skill typischerweise ein Playbook für eine bestimmte Art von Tätigkeit:

Wie erledige ich diese Art von Aufgabe?

Das kann ein Workflow für Code Reviews, systematisches Debugging, TDD, eine Migration, Architecture Reviews oder die Implementierung einer wiederkehrenden Feature-Struktur sein.

In unserer Arbeitsplatz-Metapher ist der Skill deshalb keine Hausordnung, sondern eine Arbeitsanweisung.

Das inzwischen offen spezifizierte Agent-Skills-Format macht diesen Mechanismus besonders anschaulich. Ein Skill ist dort ein Verzeichnis mit mindestens einer SKILL.md. Diese enthält Metadaten wie name und description sowie die eigentlichen Instruktionen. Zusätzlich kann ein Skill Scripts, Referenzmaterial und andere Assets enthalten. Das Format wurde ursprünglich von Anthropic entwickelt und Ende 2025 als offener Standard veröffentlicht. [4]

Ein Skill könnte sinngemäß beschreiben:

Code Review

1. Diff gegen den Ausgangsstand bestimmen.
2. fachliche Anforderung prüfen.
3. Projektregeln berücksichtigen.
4. Architekturverletzungen suchen.
5. Tests und Verifikation prüfen.
6. Findings nach Relevanz strukturieren.

Das ist etwas anderes als eine Projektregel wie „HTTP-Zugriffe gehören nach infrastructure“. Der Skill beschreibt einen Arbeitsablauf. Das Agent File liefert Regeln, die innerhalb dieses Ablaufs berücksichtigt werden können.

Ein Skill ist nicht automatisch eine gelernte Fähigkeit

Das Wort Skill ist dabei etwas tückisch.

Bei Menschen verbinden wir eine Fähigkeit häufig mit internalisiertem Können. Fahrradfahren, Blindtippen oder eine eingeübte Debugging-Methode befinden sich nicht als Markdown-Datei in einem Ordner, den wir vor jeder Tätigkeit einlesen.

Bei Agent Skills liegt eine andere Vorstellung näher. Ein Workflow wird als Datei oder strukturierte Ressource gespeichert. Wenn er für eine Aufgabe relevant wird, kann das Agent-System die entsprechenden Instruktionen laden und damit dem Modell als zusätzlichen Context bereitstellen.

SKILL.md
↓
laden
↓
Context
↓
Model

Ein Skill heißt Skill, ist technisch aber häufig eher ein Playbook als eine erlernte Fähigkeit.

Natürlich bringt das Modell selbst bereits Fähigkeiten aus seinem Training mit. Wenn ein Verhalten durch Training oder Fine-Tuning in den Model Weights verankert wurde, wäre die Analogie zu internalisiertem Können wesentlich näher.

Ein SKILL.md, das einen TDD-Workflow erklärt, verändert dagegen nicht die Model Weights. Es stellt dem Agent-System ein wiederverwendbares Playbook zur Verfügung.

Agent File und Skill ergänzen sich

Der Unterschied wird an einer konkreten Coding-Aufgabe besonders deutlich.

Nehmen wir an, der Auftrag lautet:

Implementiere einen Update Slice.

Das Agent File könnte festlegen, dass Domain State unter domain/+state liegt, Components keine Business-Orchestrierung übernehmen, HTTP-Zugriffe ausschließlich über Infrastructure laufen und neue Änderungen durch Unit Tests abgesichert werden.

Ein projektspezifischer Skill könnte dagegen den eigentlichen Arbeitsablauf definieren:

Update Slice implementieren

1. Command prüfen oder anlegen.
2. bestehenden Read State analysieren.
3. Application Use Case implementieren.
4. Infrastructure anbinden.
5. Invalidierung berücksichtigen.
6. Tests ergänzen.
7. Verification ausführen.

Die beiden Mechanismen konkurrieren nicht miteinander. Der Skill beschreibt, welche Schritte bei dieser Art Aufgabe sinnvoll sind. Das Agent File beschreibt, welche Regeln innerhalb dieses Projekts dabei gelten.

In Kurzform:

Agent File
=
Wie arbeiten wir hier?

Skill
=
Wie erledige ich diese Art von Aufgabe?

Oder mit unserem Arbeitsplatz:

Agent File
=
Hausordnung

Skill
=
Playbook

Diese Trennung ist nicht in jedem Produkt technisch exakt so implementiert. Als mentales Modell ist sie trotzdem hilfreich, weil sie zwei unterschiedliche Verantwortlichkeiten sichtbar macht.

Progressive Disclosure – Playbooks erst dann auf den Tisch legen, wenn sie gebraucht werden

Wenn wir viele Skills besitzen, entsteht sofort ein Context-Problem. Ein Agent benötigt für einen einfachen Bugfix nicht gleichzeitig die vollständigen Arbeitsanweisungen für Release Management, Datenmigration, UX Reviews, Incident Response und zehn verschiedene Feature-Typen.

Die offene Agent-Skills-Spezifikation sieht deshalb Progressive Disclosure als zentrales Designprinzip vor. Ein Skills-kompatibler Client kann zunächst nur Name und Beschreibung verfügbar machen. Wird ein Skill aktiviert, gelangt seine vollständige SKILL.md in den Context. Zusätzliche Scripts, Referenzen oder Assets werden erst bei Bedarf verwendet. Wie Discovery und Activation konkret umgesetzt werden, bleibt dabei Teil des jeweiligen Agent-Systems. [4]

Für unsere Metapher bedeutet das: Im Raum steht ein Regal mit beschrifteten Playbooks. Nicht jedes davon liegt permanent geöffnet auf dem Schreibtisch. Erst wenn eine passende Aufgabe auftaucht, wird das relevante Playbook herausgenommen.

Das spart Context und reduziert irrelevante Instruktionen. Gleichzeitig sehen wir daran erneut, dass ein Skill nicht zwingend etwas ist, das das Modell permanent „weiß“. Das Agent-System organisiert, welche Information wann in den aktuellen Arbeitsbereich gelangt.

Wiederverwendbar bedeutet nicht universell

Skills können stärker wiederverwendbar sein als Agent Files. Ein sauber formulierter Ablauf für systematisches Debugging, Code Review oder TDD kann in vielen Projekten sinnvoll sein.

Aber auch daraus folgt keine universelle Portabilität.

Je näher ein Skill an der tatsächlichen Architektur oder am Entwicklungsprozess eines Teams liegt, desto stärker wird er projektspezifisch. Ein Skill namens create-angular-crud-slice muss beispielsweise wissen, was dieses Projekt unter einem Slice versteht. Ein add-domain-command-Skill hängt davon ab, wie Commands, State und Application Layer in dieser Codebase aufgebaut sind. Ein Skill für eine Legacy-Migration muss möglicherweise sogar bewusst mit Strukturen arbeiten, die in keinem neuen Projekt nachgebaut werden sollten.

Je näher ein Skill an Architektur, Fachlichkeit und tatsächlichem Entwicklungsprozess liegt, desto stärker muss er an das Projekt angepasst werden.

Die Unterscheidung lautet deshalb nicht „Agent Files sind lokal, Skills sind global“. Es handelt sich um unterschiedliche Verantwortlichkeiten. Agent Files sind ihrer Rolle nach meist stark umgebungsbezogen. Skills beschreiben wiederholbare Arbeit, können dabei aber von sehr allgemein bis hochgradig projektspezifisch reichen.

Hier beginnt Engineering

Context und Memory lassen sich zunächst relativ neutral als technische Mechanismen erklären. Informationen werden bereitgestellt, gespeichert und später erneut verfügbar gemacht.

Bei Agent Files und Skills muss ein Team dagegen Entscheidungen treffen. Welche Architektur ist tatsächlich beabsichtigt? Welche Patterns sollen neue Änderungen reproduzieren und welche existieren nur noch aus historischen Gründen? Welche Commands gehören zum normalen Workflow? Welche Tests sind für welche Änderung relevant? Was bedeutet in diesem Repository überhaupt „fertig“?

Bei Skills kommen weitere Fragen hinzu: Wie sieht ein gutes Code Review im Team aus? Welche Debugging-Schritte haben sich bewährt? Wie wird ein Feature geschnitten? Welche Verifikationen dürfen nicht übersprungen werden?

Ein Team, das seine eigene Arbeitsweise kaum erklären kann, wird Schwierigkeiten haben, daraus gute Agent Files und Skills zu bauen.

Damit beginnt ein Stück Engineering. Das bedeutet nicht, dass vor dem ersten Einsatz ein perfektes Agent-System entworfen werden muss. Wahrscheinlicher ist ein iterativer Prozess: reale Aufgaben beobachten, wiederkehrende Fehler erkennen, Regeln explizit machen, einen Skill begrenzen, Agent-Verhalten prüfen und die Instruktionen anschließend nachschärfen.

Auch Anthropic empfiehlt bei Skills ausdrücklich, mit konkreten Lücken im Agent-Verhalten und repräsentativen Aufgaben zu beginnen, Skills daraufhin aufzubauen und ihre Nutzung anschließend in realen Szenarien weiter zu beobachten. [4]

Ein Skill ist deshalb nicht gut, weil seine Markdown-Datei überzeugend klingt.

Ein guter Skill ist gut, wenn er das Verhalten des Agents bei realen Aufgaben zuverlässig verbessert.

Diese Aussage schützt vor einer neuen Form von Cargo Cult: umfangreiche Agent-Konfigurationen zu sammeln, deren tatsächlicher Effekt nie überprüft wurde.

Matt Pococks „Skills for Real Engineers“ – Inspiration statt Blaupause

Ein aktuelles Beispiel dafür, wie solche Playbooks geschnitten werden können, ist Matt Pococks Repository Skills for Real Engineers. Die Sammlung enthält unter anderem Skills für code-review, diagnosing-bugs, tdd, implement, Research und weitere Teile eines Entwicklungsprozesses. Der implement-Workflow baut beispielsweise auf bereits getroffenen Entscheidungen auf, verwendet TDD an vorher bestimmten Seams und führt zum Abschluss einen Code Review aus. Der Debugging-Skill formuliert einen disziplinierten Diagnosezyklus aus Reproduktion, Minimierung, Hypothesenbildung, Instrumentierung, Fix und Regressionstest. [5]

Interessant daran ist weniger die Vorstellung, diese Dateien unverändert in jedes Repository zu kopieren. Interessant ist ihre Struktur: Aufgaben werden relativ eng geschnitten, Arbeitsweisen erhalten einen Namen, größere Abläufe können kleinere Skills kombinieren und wiederkehrende Engineering-Praktiken werden explizit gemacht.

Damit eignet sich die Sammlung vor allem als Inspirationsquelle für Zuschnitt und Aufbau eigener Skills. Sie zeigt, welche Arten von Arbeitswissen sich überhaupt als Playbook ausdrücken lassen und dass Skills mehr sein können als einzelne Prompt-Tricks.

Die projektspezifischen Entscheidungen nimmt sie einem Team trotzdem nicht ab. Was ein gutes Review ist, welche Testgrenzen gelten, welche Architektur erhalten werden soll und welche Arbeitsweise zu einer konkreten Codebase passt, muss weiterhin im jeweiligen Projekt entschieden werden.

Die Struktur kann man sich abschauen. Die Inhalte muss man sich erarbeiten.

Tools – womit kann der Agent handeln?

Bis hierhin haben wir vor allem darüber gesprochen, welche Informationen und Anweisungen ein Modell erhält.

Tools verändern eine andere Dimension: Sie geben dem System Möglichkeiten, Informationen aus seiner Umgebung abzurufen oder dort Aktionen auszuführen.

Ein Tool kann Dateien lesen oder schreiben, Repository-Inhalte durchsuchen, einen Shell-Befehl ausführen, git diff aufrufen, Tests starten, einen Compiler verwenden, einen Browser bedienen, eine Datenbank abfragen oder eine externe API ansprechen. Auch über MCP bereitgestellte Funktionen können in diese Kategorie fallen.

In der Schreibtisch-Metapher sind Tools die Werkzeuge am Arbeitsplatz.

Ein Modell ohne Schreibzugriff kann erklären, wie eine Datei verändert werden sollte. Mit einem entsprechenden Tool kann ein Agent die Datei tatsächlich öffnen und ändern. Mit einem Test Runner kann er anschließend die Wirkung beobachten. Mit Git kann er den entstandenen Diff untersuchen.

Damit wird eine weitere wichtige Trennung sichtbar:

Skill
=
welche Schritte sind sinnvoll?

Tool
=
womit kann ein Schritt ausgeführt werden?

Ein Code-Review-Skill kann verlangen, zunächst den Diff zu analysieren. git diff beziehungsweise ein entsprechendes Repository-Tool ermöglicht diese Aktion.

Ein Debugging-Skill kann verlangen, eine Hypothese durch einen reproduzierbaren Test zu prüfen. Shell und Test Runner ermöglichen die Ausführung.

Tools sind also keine Skills und Skills keine Tools.

Agent – das System, das den Auftrag verfolgt

Erst jetzt lohnt es sich, den Begriff Agent wieder aufzunehmen.

Auch dafür existiert keine einzige universelle Definition. OpenAI beschreibt Agents als Systeme, die Aufgaben im Auftrag eines Nutzers mit einem hohen Maß an Selbstständigkeit erledigen und dafür ein LLM zur Steuerung des Workflows sowie Tools für Informationen und Aktionen einsetzen. Anthropic verwendet den Oberbegriff agentic systems, unterscheidet innerhalb davon aber zwischen vordefinierten Workflows und Agents, bei denen das Modell Prozess und Tool-Nutzung dynamisch steuert. [6][7]

Die Grenze ist also nicht normiert.

Für unser mentales Modell ist die gemeinsame Idee wichtiger: Ein Agent verarbeitet nicht nur einmal einen Prompt und gibt einmal Text zurück. Er kann über mehrere Schritte hinweg den Zustand seiner Aufgabe betrachten, eine nächste Aktion auswählen, ein Ergebnis aus der Umgebung erhalten und darauf reagieren.

Vereinfacht:

Task
↓
Agent

Model
+ Context
+ Memory
+ Agent Files
+ Skills
+ Tools

↓
Aktion wählen
↓
ausführen
↓
Ergebnis beobachten
↓
nächsten Schritt wählen
↓
...

Nicht jeder Agent besitzt exakt diese Komponenten, und nicht jeder organisiert sie auf dieselbe Weise. Ein System kann ohne persistentes Memory arbeiten. Ein anderes kennt keine Skills. Wieder ein anderes erlaubt nur wenige strikt begrenzte Tools.

Der entscheidende Unterschied zu einem einfachen einzelnen LLM-Aufruf liegt damit weniger in einem neuen „denkenden Baustein“ als in der Organisation eines mehrstufigen Arbeitsprozesses.

Ein Coding Agent ist nicht nur ein Modell, sondern ein Modell in einer Arbeitsumgebung.

Wie ein Coding Agent daraus tatsächlich arbeitet

Nehmen wir einen relativ normalen Auftrag:

Behebe den Fehler aus Issue 381 und ergänze einen Regressionstest.

Ein Coding Agent könnte zunächst das Issue lesen und anschließend das Repository durchsuchen. Er öffnet die wahrscheinlich relevanten Dateien und bekommt dabei möglicherweise lokale Agent Instructions für diesen Bereich des Repositories in den Context. Für die Fehleranalyse kann ein Debugging-Skill aktiviert werden.

Danach führt der Agent einen bestehenden Test aus oder erzeugt einen reproduzierbaren Fehlerfall. Das Tool liefert eine Fehlerausgabe zurück, die wiederum Teil des neuen Arbeitskontexts werden kann. Das Modell entscheidet auf Basis dieses aktualisierten Zustands, welche Datei als Nächstes untersucht oder verändert werden sollte.

Nach einer Änderung läuft der Test erneut. Vielleicht erscheint jetzt ein TypeScript-Fehler. Auch diese Beobachtung kann in den nächsten Modellschritt eingehen. Der Agent korrigiert den Patch, führt weitere Verifikation aus und untersucht abschließend den Diff.

Der Ablauf könnte ungefähr so aussehen:

Issue
↓
Repository untersuchen
↓
relevante Dateien laden
↓
Agent Files berücksichtigen
↓
Debugging Skill verwenden
↓
Test ausführen
↓
Fehler beobachten
↓
Code ändern
↓
Test erneut ausführen
↓
Diff prüfen

Ein langer Prompt könnte viele dieser Schritte ebenfalls beschreiben. Ein Agent-System organisiert jedoch zusätzlich die Aktionen, die Rückführung ihrer Ergebnisse, den sich verändernden Context und weitere Modellaufrufe. Genau diese Arbeitsumgebung war bereits im vorherigen Artikel relevant, als wir gesehen haben, dass Coding-Benchmarks nicht nur das nackte Modell messen.

Am Ende landet erstaunlich viel im Context

Damit können wir die verschiedenen Begriffe noch einmal zusammenführen.

Memory kann außerhalb der aktuellen Modellanfrage gespeichert sein. Ein Agent File liegt als Datei im Repository. Ein Skill kann in einem Skill-Verzeichnis darauf warten, aktiviert zu werden. Ein Tool existiert als ausführbare Funktion außerhalb des Modells.

Damit das Modell die Informationen aus diesen Mechanismen berücksichtigen kann, müssen relevante Inhalte oder Beschreibungen normalerweise in irgendeiner Form Teil des aktuellen Contexts werden.

Agent File ─┐
Skill ──────┤
Memory ─────┤
Repository ─┤
Tool Output ┤
            ↓
         Context
            ↓
          Model

Das bedeutet nicht, dass alle Mechanismen technisch identisch wären. Ihre Lebensdauer, Auswahlregeln, Persistenz, Prioritäten und Ausführungssemantik unterscheiden sich erheblich. Ein Tool beispielsweise bleibt eine externe Handlungsmöglichkeit; nur seine Beschreibung und seine Ergebnisse werden für das Modell zu Context.

Für die Demystifizierung ist die gemeinsame Beobachtung trotzdem zentral:

Viele Begriffe rund um Agentic AI beschreiben keine neuen Arten von Intelligenz, sondern unterschiedliche Wege, einem Modell Informationen, Regeln, Arbeitsabläufe und Handlungsmöglichkeiten bereitzustellen.

Ein Memory-System entscheidet beispielsweise, was gespeichert und später wiedergefunden wird. Progressive Disclosure entscheidet mit darüber, welcher Skill wann vollständig geladen wird. Agent Files stellen lokale Regeln bereit. Tools liefern neue Beobachtungen aus der Arbeitsumgebung oder ermöglichen Änderungen an ihr.

Das Modell arbeitet anschließend mit dem Context, der daraus für den jeweiligen Schritt entstanden ist.

Ein kompaktes mentales Modell

Mechanismus	Kernfrage	Schreibtisch-Metapher
Model	Was kann das System bereits?	Ausbildung und Erfahrung
Context	Welche Information ist gerade verfügbar?	Material auf dem Schreibtisch
Memory	Was kann gespeichert und später wiedergefunden werden?	Archiv / Notizbuch
Agent File	Wie arbeiten wir hier?	Hausordnung
Skill	Wie erledige ich diese Art von Aufgabe?	Playbook / Arbeitsanweisung
Tool	Womit kann ich handeln oder Informationen beschaffen?	Werkzeug
Agent	Wie wird daraus ein mehrstufiger Arbeitsprozess?	Arbeitsorganisation

Wie bei jeder Metapher sollte man sie nicht weiter treiben als nötig. Ein Modell besitzt keine menschliche Ausbildung, ein Memory-System kein biologisches Langzeitgedächtnis und ein Agent ist kein digitaler Mitarbeiter.

Die Tabelle soll Rollen unterscheiden, keine menschliche Kognition nachbauen.

Der Schreibtisch allein macht noch keine gute Arbeit

Von außen wirkt ein moderner Coding Agent schnell wie ein einziges intelligentes System. Wir geben einen Auftrag ein, beobachten einige Arbeitsschritte und erhalten am Ende einen Patch.

Die Unterscheidung dieser Mechanismen ist nicht nur terminologische Pedanterie. Sie hilft uns zu verstehen, an welcher Stelle ein Problem überhaupt entsteht. Fehlt dem Modell Wissen? Wurde die relevante Information nicht in den Context geladen? Ist ein Memory veraltet? Widerspricht ein Agent File der tatsächlichen Architektur? Ist ein Skill falsch geschnitten? Fehlt ein Tool oder liefert es schlechtes Feedback?

Erst wenn diese Fragen getrennt werden können, wird aus „der Agent macht manchmal komische Dinge“ ein Problem, das sich technisch untersuchen lässt.

Gerade bei Agent Files und Skills folgt daraus eine erste praktische Konsequenz. Fremde Repositories können gute Ideen liefern, aber sie kennen unsere Codebase nicht. Sie kennen unsere Architekturentscheidungen, Legacy-Grenzen, Definition of Done und tatsächlichen Entwicklungsabläufe ebenfalls nicht.

Gerade bei Agent Files und Skills reicht es nicht, fremde Best Practices zu kopieren. Sie müssen zur eigenen Codebase und Arbeitsweise passen.

Der große Schreibtisch, das Archiv, die Hausordnung, die Playbooks und die Werkzeuge erklären damit einen erheblichen Teil der Arbeitsumgebung eines Coding Agents. Eine Besonderheit bleibt allerdings übrig: Selbst wenn wir demselben Agenten denselben Context, dieselben Regeln, dieselben Skills und dieselben Tools bereitstellen, erhalten wir nicht zwingend jedes Mal exakt dieselbe Lösung.

Das zugrunde liegende Modell arbeitet probabilistisch. Warum daraus Ergebnisvarianz entsteht und was das für Software Engineering bedeutet, schauen wir uns im nächsten Artikel an.

Quellen

[1] AGENTS.md: A simple, open format for guiding coding agents. Aktuelle Projektdokumentation, Stand September 2026. Beschreibt AGENTS.md als vorhersehbaren Ort für Build-Schritte, Tests, Konventionen und weiteren projektspezifischen Context für Coding Agents.

[2] GitHub: Adding repository custom instructions for GitHub Copilot. GitHub Docs, Stand September 2026. Dokumentiert unter anderem .github/copilot-instructions.md, pfadspezifische .instructions.md-Dateien sowie AGENTS.md, CLAUDE.md und GEMINI.md als Agent Instructions.

[3] Anthropic: How Claude remembers your project. Claude Code Docs, Stand September 2026. Dokumentiert CLAUDE.md, .claude/rules/, Auto Memory, deren Laden als Context sowie den Import bestehender AGENTS.md-Instruktionen.

[4] Agent Skills: Agent Skills Overview, Specification und How to add skills support to your agent. Offener Agent-Skills-Standard, Stand September 2026. Das ursprünglich von Anthropic entwickelte Format beschreibt SKILL.md, optionale Scripts, References und Assets sowie Progressive Disclosure für Discovery, Activation und Execution.

[5] Matt Pocock: Skills for Real Engineers. GitHub Repository, Stand September 2026. Sammlung von Engineering-Skills unter anderem für TDD, Debugging, Code Review, Implementation, Research und Domain Modeling.

[6] Erik Schluntz, Barry Zhang / Anthropic: Building effective agents. Anthropic, 19. Dezember 2024. Unterscheidet vordefinierte Workflows von Agents, bei denen das LLM Prozess und Tool-Nutzung dynamisch steuert.

[7] OpenAI: A practical guide to building agents. Beschreibt Agents als Systeme, die Aufgaben im Auftrag von Nutzern mit einem hohen Maß an Selbstständigkeit erledigen, wobei ein LLM Workflow-Ausführung und Tool-Auswahl steuert.

[8] Anthropic: Effective context engineering for AI agents. Anthropic Engineering, 29. September 2025. Beschreibt unter anderem den Übergang von reinem Pre-Inference Retrieval zu „just in time“-Strategien, bei denen Agents benötigten Context während der Ausführung dynamisch nachladen.