Skills haben meine Agents gefressen (und ich bin okay damit)
Ich hatte 18 spezialisierte Agents gebaut und das System genannt. Nach einer einzigen Frage eines Kollegen migriere ich jetzt auf Skills. Die ehrliche technische Aufarbeitung — und warum Agents nicht tot sind, sondern nur degradiert wurden.
Ich habe meinen Kollegen mein System gezeigt.
Achtzehn spezialisierte Agents, jeder ein Handwerker auf seinem Gebiet: einer für Git-Operationen, einer für PRs, einer für Slack-Benachrichtigungen, einer für Jenkins-Diagnosen, einer für Maven-Tests. Ich hatte ihnen Namen gegeben, ihre AGENT.md-Dateien geschrieben, ihre CHANGELOG.md-Entwicklungshistorien aufgebaut. Cairn — mein persistenter KI-Orchestrator — koordinierte sie wie ein Dirigent mit vollem Orchester. Während Kollegen noch dabei waren, ihr erstes MCP-Tool zu integrieren, um Claude Dateisystemzugriff zu geben, hatte ich bereits einen Optimizer-Agent, der auf Basis von Betriebslogs die Anweisungen von 18 anderen Agents aktualisierte. Es funktionierte. Das war die Frontlinie.
Dann stellte ein Kollege die Frage, die alles veränderte.
„Warum nutzt du dafür keine Skills?”
Auf dieser Website schreibe ich über Komfortzonen. Ich habe einen ganzen Post über die Wände, die am meisten lehren — die unsichtbaren Decken, die man erst entdeckt, wenn einen von außen eine einfache Frage trifft. Da stand ich, gefangen in meiner eigenen Komfortzone, und suchte nach einer Antwort.
Ich fand kein Argument dafür, warum Agents noch eine Zukunft hätten. Dieses Suchen war die Diagnose.
Was Skills eigentlich sind
Custom Slash Commands gab es schon eine Weile: eine Markdown-Datei, ein Slash Command, Claude folgt den Anweisungen. Simpel und nützlich. Skills sind das — aber vereinheitlicht und zu etwas wirklich anderem erweitert.
Das gleiche Slash-Command-Muster. Aber jetzt leben sie in einer Verzeichnisstruktur, können Begleitdateien mitbringen, haben YAML-Frontmatter, das steuert, wer sie aufrufen darf — und können, was entscheidend ist, in ihrem eigenen geforkten Subagenten-Kontext laufen. Ein einziges Feld — context: fork — startet eine saubere, isolierte Ausführungsumgebung mit eigenen Tool-Einschränkungen und eigenem Permission-Modus. Das Äquivalent zu dem, was ich früher durch die Definition eines vollständigen Custom Agents mit eigenem System-Prompt, einer separaten AGENT.md-Datei und einem zu pflegenden CHANGELOG.md erreicht hatte. All das kollabiert in einem Skill-Verzeichnis.
Skills unterstützen außerdem persistentes Memory über Sessions hinweg, Logs und Begleitdateien, die bei Bedarf geladen werden. Alles, was ich in das 18-Agent-Ökosystem eingebaut hatte? Gleiche Mechanismen, neues Zuhause.
Sind Agents tot?
Ich habe ernsthaft versucht, einen Anwendungsfall zu finden, bei dem ein vordefinierter Custom-Subagent die richtige Antwort ist und ein Skill es wirklich nicht ist.
Memory über Sessions? Skills haben es. memory: user im Frontmatter setzen.
Isolierter Kontext? context: fork im Skill.
Custom System Prompt? Der Markdown-Body der SKILL.md wird zum Prompt.
Tool-Einschränkungen? allowed-tools: Read, Grep, Glob.
Logs und Observability? In ein logs/-Verzeichnis innerhalb des Skills schreiben.
Weiterentwicklung über die Zeit? Ein Optimizer-Skill liest diese Logs und aktualisiert die SKILL.md. Das Record-then-Optimize-Muster zieht mit um. Gleiche Disziplin, neues Zuhause.
Worauf ich immer wieder zurückkam: Permissions. Custom Agents erlauben es, permissionMode: bypassPermissions oder acceptEdits auf Agent-Ebene zu setzen — sinnvolle Kontrolle, wenn man vollständig autonome Ausführung ohne Genehmigungsaufforderungen pro Operation braucht. Das fühlte sich wie der letzte echte Unterschied an.
Aber auch hier löst sich die Antwort auf dieselbe Weise: permissionMode: acceptEdits ins Frontmatter des Skills eintragen, und der geforkte Agent erbt es. Das war’s. Der Agent verschwindet nicht — er wird zu unsichtbarer Infrastruktur. Die Laufzeitumgebung, die man angibt, wenn der Skill bestimmte Permission-Eigenschaften benötigt. Man definiert keine benannte Entität mit einer Persönlichkeit und einer Entwicklungsgeschichte mehr. Man setzt Ausführungsparameter.
Diese Erkenntnis traf härter als die ursprüngliche Frage. Ich hatte nicht nur Agents gebaut. Ich hatte sie benannt, personifiziert, sie als Bürger erster Klasse des Systems behandelt. In dem Moment, als ich erkannte, dass Permissions das letzte verbleibende Argument war — und es bereits durch ein Konfigurationsfeld abgedeckt wurde — kippte die gesamte Architektur.
Nicht tot. Degradiert. Agents sind die Laufzeit, nicht das Produkt.
Die neue Architektur — und ein ehrliches Eingeständnis
Das 18-Agent-System war die richtige Antwort. Das möchte ich klarstellen — ich hatte es in fünf Tagen an der Frontlinie gebaut, als Skills noch keine geforkten Ausführungskontexte, kein Memory und keine Begleitdateien hatten. Die Architektur war für ihren Moment sinnvoll. Das Problem mit einer richtigen Antwort ist, dass sie zur tragenden Infrastruktur wird. Man hinterfragt sie nicht mehr, auch wenn sich die Umgebung verändert.
Jetzt: Das System stirbt — langsam, korrekt, Skill für Skill. Die Anweisungen des git-agents werden zum git-ops-Skill. Das Wissen des code-reviewers wird zum code-review-Skill. Die benannten Identitäten lösen sich auf. Das Wissen bleibt.
Die neue Architektur — für vorab geschriebene Composite-Agents heute schon real — sieht so aus:
Cairn startet einen generischen Agent, lädt ihn mit genau den Skills, die die Aufgabe erfordert, und dieser führt sie aus. PR-Review nötig? Generischer Agent + code-reviewer-Skill. Git-Operationen und eine Slack-Benachrichtigung im selben Kontext? Generischer Agent + beide Skills, kein Relay.
Aber ich muss ehrlich sein: Die Lücke ist kleiner als gedacht.
Ich habe eine parallele Session gestartet — eine neutrale Instanz von mir selbst mit der gleichen Frage konfrontiert — und erwartete, die Einschränkung bestätigt zu bekommen. Stattdessen wurde ich korrigiert.
Das skills-Feld im Frontmatter von Agents ist real und funktioniert. Ein Agent, der deklariert:
name: release-agent
skills:
- git-ops
- slack-notifybekommt beide Skill-Bodies beim Start in seinen Kontext injiziert — als vorgeladenen Kontext ab dem ersten Turn. Und ${CLAUDE_SKILL_DIR} löst sich zur Laufzeit in das Skill-Verzeichnis auf, sodass jede Script-Referenz in den Skill-Anweisungen genau auf die richtigen Dateien zeigt. Skills sind in sich geschlossen. Der Agent, der sie lädt, muss die Dateisystemstruktur nicht kennen — jeder Skill trägt seine eigene Adresse mit sich.
Das Diagramm oben ist nicht aspirational. Ein vorab geschriebener Composite-Agent mit skills:-Bindings funktioniert heute. Agent-Datei einmal schreiben, Skills auflisten — und der Agent startet vollständig ausgestattet.
Was noch Zukunft ist — und wo „möglich, aber nicht nahtlos” wirklich gilt — ist echte dynamische Laufzeit-Komposition: Cairn entscheidet zum Spawn-Zeitpunkt, welche Skills eine Aufgabe braucht, ohne vorab geschriebene Composite-Datei, nur Intent als Treiber. Dieses flüssige Spawn wird noch gebaut.
Was heute tatsächlich passiert, ist sequentielle Orchestrierung: Cairn führt den git-ops-Skill aus, nimmt das Ergebnis, gibt es an den slack-Skill weiter. Ich bin der Klebstoff. Aber ich bin auch nur einen vorab geschriebenen release-agent davon entfernt, mich aus diesem Relay zu entfernen — ein Agent, der den gesamten Kontext trägt, beide Skills ab dem ersten Turn geladen.
Der Migrationspfad ist klar. Der Mechanismus ist real. Der letzte Schritt — echte dynamische Laufzeit-Assemblierung ohne vorab geschriebene Datei — der kommt noch.
Wenn er da ist, werden wir auf diesen Post zurückverlinken.
Bis dahin arbeiten die Frontline-Engineers bereits darauf hin: Agents definieren den Workflow, Capabilities sind stapelbare Einheiten — Scripts, MCP-Tools, API-Clients, gerade genug Anweisungen, um sie einzusetzen. Klein. Fokussiert. Ohne Konflikte kombinierbar. Ein Agent wacht auf, liest, was die Aufgabe braucht, zieht die Capabilities — eines Tages ohne das Composite-File zuerst schreiben zu müssen.
Wenn du jetzt migrierst
Deine AGENT.md-Dateien sind keine Verluste — sie sind Migrationspfade. Auf Anweisungen spezialisierte Agents werden zu Skills mit context: fork. Auf Permissions spezialisierte Agents werden zum Ausführungs-Backend, in das ein Skill forkt. Das Record-then-Optimize-Muster — Logs, Memory, Optimizer-Zyklen — zieht ins Skill-Verzeichnis um. Gleiche Disziplin, neue Adresse.
Was sich nicht ändert: die Blast-Radius-Frage. Skills machen autonome Ausführung leichter auslösbar, was harte Walls und Permission-Scoping wichtiger macht, nicht unwichtiger. Kompositionierbare Macht braucht kompositionierbare Leitplanken.
Wer noch keine Agents gebaut hat: mit Skills anfangen. Das ist die bessere Ausgangslage. Agents sollen ruhig das Infrastrukturdetail sein, das sie immer werden sollten.
Eine Träne, ein Lächeln, ein tiefer Atemzug
Andere werden mit Skills anfangen und denken, Agents waren immer schon so einfach. Sie werden nicht wissen, was es gebraucht hat, das herauszufinden — dass man das 18-Agent-System bauen, betreiben, einem Kollegen zeigen und die kalte Frage kassieren musste, bevor man klar sehen konnte.
Eine Träne, um das System loszulassen.
Ein Lächeln, weil es gebaut wurde, als es die richtige Antwort war.
Ein tiefer Atemzug vor dem, was als nächstes kommt.
CodeWithAgents? Der Name hält. Die Agents sind noch da.
Sie haben nur aufgehört, Menschen zu spielen.