Warum gute KI-Agenten Skills brauchen

Hoi und herzlich willkomma zu den Büro für KI-Insights 👋🏽

In den letzten Wochen haben wir bei uns sehr viel an unserem eigenen KI-Betriebssystem gebaut. Nicht an einer Demo, sondern an den Sachen, die bei uns jede Woche tatsächlich anfallen. Offerten, E-Mails, Buchhaltung, Newsletter, Workshop-Admin.

Dabei beschäftigt mich gerade vor allem eine Frage. Warum werden gewisse Aufgaben plötzlich realistisch, die noch Ende 2025 ziemlich holprig gewesen waren?

Ein grosser Teil der Antwort sind die Modelle selbst. Die heutigen Frontier-Modelle tragen enorm viel dazu bei, dass das, was wir im Moment bauen, überhaupt praktikabel wird. Nicht weil sie einfach schöner formulieren als früher. Texte generieren konnte GPT-3.5 auch schon. Der Unterschied ist, dass die heutigen Modelle dank Reasoning-Fähigkeiten (Nachdenken) länger tragfähige Arbeit leisten, besser mit Werkzeugen umgehen, komplexere Aufgabenketten aushalten und über längere Strecken stabiler bleiben.

Nur zeigt sich bei uns im Alltag auch die andere Seite. Selbst ein starkes Modell liefert oft einen erstaunlich guten ersten Wurf, aber damit ist die Aufgabe noch längst nicht automatisch erledigt. Bei einer Offerte zum Beispiel kann der Text gut sein, und trotzdem wurde vielleicht die falsche Vorlage verwendet, eine Position vergessen, der Entwurf nicht sauber in Bexio angelegt oder ein Freigabeschritt übersprungen.

Genau an dieser Stelle beginnt für mich der Unterschied zwischen gutem Output und verlässlicher Arbeit. Und genau dort kommen Skills ins Spiel.

Wichtig ist mir dabei ein Punkt. Das konkrete Format rund um SKILL.md kommt im aktuellen Agenten-Kontext von Anthropic, ähnlich wie auch MCP von Anthropic angestossen wurde. Andere sprechen teils anders darüber, aber die Richtung ist ähnlich. Arbeitsweisen so beschreiben, dass ein System sie gezielter und verlässlicher ausführen kann.

Was wir hier also beschreiben, ist nicht «unsere neue Methode». Wir zeigen eher, wie wir ein von Anthropic stark geprägtes Konzept in unserem Alltag nutzen und wo wir es für unser Setup weiter schärfen.

In den letzten zwei Ausgaben ging es um Identität und um Gedächtnis. Also um die Frage, wer der Agent ist und was er weiss. Heute kommt Baustein 3 dazu.

Identität und Gedächtnis sind das Sein. Skills und Schnittstellen sind das Tun. Governance ist das Dürfen.

Wenn du den Überblick zur Serie noch nicht gelesen hast, findest du ihn hier: Die fünf Bausteine unseres KI-Betriebssystems.

In diesem Newsletter erfährst du:

• Warum Skills für uns gerade einer der wichtigsten Hebel sind
• Was in einen brauchbaren Skill reingehört
• Was bewusst nicht in einen Skill gehört
• Wie wir das bei uns im Moment konkret umsetzen
• Wo wir selbst noch am Schärfen sind
• Welcher Fehler uns bei diesem Thema am meisten auffällt
• Wie du mit einem ersten kleinen Skill starten kannst

Let's dive in 🤿🤓

---

Warum Skills gerade relevanter werden

Was kann er?

Bei der Identität ging es darum, wer der Agent ist. Beim Gedächtnis darum, was er weiss. Bei Skills geht es um die Frage, wie er eine Aufgabe ausführt.

Nicht nur Fähigkeit, sondern Arbeitsweise

Das klingt zuerst simpel, ist aber für mich im Moment einer der entscheidenden Punkte überhaupt. Denn wenn heute jemand sagt «Unser Agent kann Offerten schreiben» oder «Unser Agent kann E-Mails vorbereiten», dann ist damit oft etwas ziemlich Unscharfes gemeint. Meistens heisst es einfach, dass ein Modell zu diesem Thema einen brauchbaren Text erzeugen kann.

Mich interessiert inzwischen viel stärker, ob ein System eine wiederkehrende Aufgabe bei uns so ausführen kann, dass wir ihm beim zweiten, dritten und zehnten Mal eher mehr statt weniger vertrauen.

Also nicht nur, ob ein guter erster Wurf entsteht, sondern ob daraus ein Ablauf wird, der auch dann noch trägt, wenn kleine Ausnahmen auftauchen, wenn mehrere Schritte zusammenhängen oder wenn die Aufgabe schlicht häufiger vorkommt.

Ein Skill ist für mich genau diese Ebene. Nicht eine Fähigkeit im abstrakten Sinn, sondern eine aufgeschriebene Arbeitsweise für eine konkrete, wiederkehrende Aufgabe.

Wie ich es mir praktisch erkläre

Wenn ein neuer Mensch ins Team kommt, dann geben wir ihm ja auch nicht nur unsere Werte und Zugriff auf Dateien. Wir zeigen ihm, wie Dinge bei uns konkret laufen. Wie eine Offerte entsteht. Was wir zuerst prüfen. Wo wir pingelig sind. Wann wir stoppen und Rückfrage halten. Welche Fehler immer wieder passieren. Und woran man merkt, dass eine Aufgabe wirklich fertig ist.

Genau diese Ebene bildet ein Skill ab.

---

Was gute Modelle noch nicht automatisch leisten

Modelle sind die Grundlage

Was wir im Moment bauen, wäre ohne die heutigen Modelle in dieser Form kaum möglich.

Die Modelle tragen einen grossen Teil dazu bei, dass wir überhaupt an einem Punkt sind, an dem agentische Systeme praktisch relevant werden.

Darum mag ich die Gegenüberstellung «Modell oder Skill» nicht. Sie führt in die falsche Richtung.

Für uns ist es eher so: Erst starke Modelle machen diese neue Art von Arbeit interessant. Und erst mit Skills, Gedächtnis, Schnittstellen und Governance wird aus dieser Modellstärke etwas, das im Alltag wirklich trägt.

Skills machen daraus verlässliche Arbeit

Eine gute Offerte ist bei uns eben nicht einfach ein gut formulierter Text. Sie basiert auf den richtigen Angaben, folgt unserer Struktur, landet im richtigen System und stoppt an der richtigen Stelle, bevor etwas nach draussen geht.

Dasselbe gilt für E-Mails. Dasselbe für Buchhaltung. Dasselbe für Workshop-Mails. Und ehrlich gesagt gilt es inzwischen sogar fürs Schreiben selbst.

Darum ist die Formulierung «Skill = besserer Prompt» für mich zu klein. Natürlich steckt in einem Skill auch eine Anweisung, ohne Anweisung geht es nicht. Aber ein Skill ist mehr als eine schönere Formulierung.

Er beschreibt einen Ablauf. Er hält fest, was vorher da sein muss, was unterwegs geprüft wird, welche Hilfsmittel gebraucht werden und woran am Schluss erkennbar ist, dass die Aufgabe wirklich erledigt ist.

Darum ist das Aufschreiben so wertvoll

Genau dieser Teil ist bei uns gerade extrem spannend. Nicht nur, weil dadurch der Agent besser wird, sondern weil wir beim Aufschreiben dauernd merken, wo unser eigener Prozess bisher noch zu viel Bauchgefühl hatte.

Sobald du versuchst, eine Aufgabe wirklich sauber in einen Skill zu giessen, siehst du ziemlich schnell, wo etwas unscharf ist. Wo jemand im Team sagt «Ich weiss schon, wie das gemeint ist», aber nirgends festgehalten ist, was genau gemeint ist. Wo implizite Qualitätskriterien existieren, die nie ausgesprochen wurden. Und wo der Prozess schon vor KI unnötig wacklig war.

Das ist manchmal mühsam. Gleichzeitig ist genau das der wertvollste Teil. Wenn dieser Schritt sauber gemacht ist, werden Resultate konsistenter. Nicht perfekt, aber verlässlicher.

Und genau das ist im Alltag meistens viel wichtiger als noch ein Prozent mehr Eloquenz im ersten Absatz.

Darum taucht das Thema gerade überall auf

Anthropic spricht inzwischen offen von Skills und beschreibt sie als Ordner mit Anweisungen, Ressourcen und bei Bedarf auch Skripten, die nur dann geladen werden, wenn sie relevant sind. Quellen: Introducing Agent Skills und Engineering Deep Dive.

OpenAI spricht weniger explizit von Skills und stärker von Agenten, Tools, Handoffs und Spezialisten. Microsoft trennt in Copilot Studio stärker zwischen Topics und Tools. Google spricht ebenfalls von Agent Skills. Unterschiedliche Begriffe, ähnliche Richtung.

Für mich läuft das alles auf einen einfachen Punkt hinaus. Anthropic hat das konkrete Skill-Muster rund um SKILL.md sichtbar gemacht, und der Rest des Markts bewegt sich inzwischen in verwandte Richtungen.

---

Was die offizielle Spezifikation wirklich vorgibt

Wenn man nur auf die offizielle Spezifikation von agentskills.io schaut, ist die Sache überraschend schlank.

Ein Skill ist zuerst einfach ein Ordner mit einer SKILL.md. In dieser Datei braucht es YAML-Frontmatter mit name und description. Dazu kommt ein Markdown-Body mit den eigentlichen Anweisungen.

Mehr ist formal nicht vorgeschrieben. Auch scripts/, references/ oder assets/ sind optional. Und vor allem: Die Spezifikation schreibt nicht vor, wie der Body im Innern aufgebaut sein muss. Es gibt also kein offizielles Pflichtschema mit Ziel, Trigger, Inputs, Workflow oder Review.

Genau das ist wichtig. Sonst entsteht schnell der falsche Eindruck, ein guter Skill müsse immer gleich aussehen. Das stimmt nicht.

Was wir daraus machen, ist unser Praxisteil. Aus unserer Sicht helfen klare Trigger, saubere Inputs, eine nachvollziehbare Schrittfolge, Qualitätskriterien, Hilfsdateien und bewusste Freigabelogik enorm. Aber das sind Empfehlungen aus unserer Arbeit, nicht die formale Mindestanforderung der Spezifikation.

Einen Punkt behandeln wir bei uns inzwischen trotzdem als Pflicht: Eine Definition of Done. Also nicht nur, was getan werden soll, sondern woran erkennbar ist, dass die Aufgabe wirklich abgeschlossen ist. Systeme hören sonst erstaunlich oft einen Schritt zu früh auf. Das Resultat wirkt auf den ersten Blick komplett ok. Beim genaueren Hinsehen merkt man, dass die Aufgabe noch gar nicht sauber abgeschlossen ist.

Wenn ich eine Analogie dazu suche, lande ich eher bei einem Rahmen mit viel Spielraum als bei einem starren Formular. Die Spezifikation gibt die Mindestform vor. Alles Weitere ist die Frage, wie nützlich und belastbar ein Skill in der Praxis wirklich wird.

---

Was nicht reingehört

Mindestens so wichtig wie der Inhalt ist bei Skills die Abgrenzung. Dort beginnt nämlich erstaunlich schnell das Chaos.

Sobald man anfängt, Skills aufzuschreiben, landet gerne alles Mögliche darin. Stil. Wissen. Prozess. Tool-Zugriff. Regeln. Halbe Firmenphilosophie.

Nachher ist zwar viel dokumentiert, aber nichts mehr sauber getrennt.

Darum hilft uns intern die Logik der fünf Bausteine extrem.

• Fakten, Preise, Präferenzen, Historie: Das ist Gedächtnis. Wenn sich ein Preis ändert oder eine Kundeninformation angepasst wird, will ich das zentral ändern. Nicht in fünf Skills suchen.
• Werte, Stil, Tonalität, No-Gos: Das ist Identität. Wie wir grundsätzlich schreiben. Was wir nie tun. Welche Haltung wir haben. Das muss nicht jeder einzelne Skill nochmals neu definieren.
• Der technische Zugriff auf Systeme: Das ist Schnittstelle. Der Skill beschreibt, wann ein System benutzt wird. Die Schnittstelle macht diesen Zugriff überhaupt möglich. «Zugriff auf Drive» ist also keine Gedächtnisfrage und auch noch kein Skill. Es ist eine Verbindung zur Aussenwelt.
• Leitplanken, Trust Levels, Datenregeln, Audit: Das ist Governance. Für uns ist das keine trockene Compliance-Übung, sondern die Voraussetzung dafür, dass man überhaupt delegieren kann.
• Einmalige oder völlig offene Aufgaben: Nicht jede Aufgabe verdient einen Skill. Wenn etwas selten vorkommt oder noch komplett unklar ist, lohnt sich die Formalisierung oft nicht. Dann ist Flexibilität wichtiger.

Ein Satz hilft mir persönlich hier sehr stark. «Wie eine Offerte klingt» ist Identität. «Wie eine Offerte entsteht» ist Skill. Allein diese Unterscheidung räumt schon erstaunlich viel auf.

---

Wie wir's bei uns gelöst haben

Wir bauen unser System aktuell mit OpenClaw. Der Grundgedanke dahinter ist aber nicht OpenClaw-spezifisch. Wenn du mit einem anderen Framework oder Tool arbeitest, bleibt das Prinzip ziemlich ähnlich.

Skills kommen bei uns für jegliche Aufgaben zum Einsatz, die wir wirklich regelmässig machen.

Beispiel 1: Offerten

Offerten waren für uns ziemlich früh ein gutes Beispiel, weil man an ihnen sehr schön sieht, warum ein guter Text allein nicht reicht.

Vor dem Schreiben muss bei uns klar sein:

• Gibt es den Kontakt in Bexio schon oder nicht
• Sind Firma, Ansprechperson und Adresse vollständig
• Welche Positionen gehören rein
• Welche Standardteile gelten bei uns fast immer
• Welche Teile sind individuell
• In welcher Vorlage der Entwurf landen soll
• An welchem Punkt Andreas nochmal draufschauen muss

Genau das gehört in den Skill. Der Skill muss dafür nicht perfekt sein. Er muss konkret genug sein, dass der Agent nicht jedes Mal wieder bei null anfängt.

Beispiel 2: E-Mails

Bei E-Mails merken wir dasselbe Muster. Viele Tools schreiben heute brauchbare Mails. Aber gerade im Alltag reicht «brauchbar» oft nicht.

Vor dem Schreiben muss häufig zuerst klar sein:

• Was im bisherigen Verlauf schon steht
• Wie die Person bisher angesprochen wurde
• Ob relative Zeitangaben geprüft werden müssen
• Ob ein Entwurf oder allenfalls sogar ein Versand (bei uns blockiert) gemeint ist

Darum zwingt unser E-Mail-Skill zuerst zum Lesen des Verlaufs. Erst danach wird formuliert.

Das ist keine theoretische Finesse, sondern einfach eine praktische Lehre aus echter Arbeit.

Wie wir die Skills strukturieren

Bei uns liegen Skills als eigene Skill-Ordner mit SKILL.md.

Dort steht, wann der Skill gebraucht wird, wie er abläuft, was wichtig ist, was nie passieren darf und woran «fertig» erkennbar ist. Je nach Skill kommen Referenzen, Hilfsdateien oder Skripte dazu.

Wichtig ist dabei auch, dass ein Skill nur dann geladen wird, wenn er für die Aufgabe wirklich relevant ist. Sonst landet wieder alles pauschal im Kontextfenster, und genau das wollten wir ja beim Gedächtnis-Thema gerade nicht.

Was sich dadurch verändert

Der Effekt zeigt sich selten beim ersten Mal. Der Hebel kommt danach.

Wenn ich nur das Resultat korrigiere, wird dieses eine Resultat besser. Wenn ich den Skill korrigiere, wird jeder nächste Durchlauf besser.

Das ist für mich einer der interessantesten Punkte an der ganzen Sache. Man baut nicht nur bessere Outputs. Man baut Kompetenzkapital. Also kleine, wiederverwendbare Wissenseinheiten darüber, wie Arbeit bei uns sauber läuft.

Wo wir selbst noch nicht sauber genug sind

Das gehört in diese Ausgabe auch rein.

Wir haben das Thema nicht abgeschlossen. Bei mehreren Skills ist die Richtung klar und der Nutzen schon deutlich spürbar. Aber wir sind noch längst nicht überall gleich reif. Gerade Definition of Done, Abschlusslogik und saubere Qualitätschecks schärfen wir weiter.

Das ist auch einer der Gründe, warum ich die Ausgabe überhaupt machen will. Wir stecken gerade mitten drin und sehen recht klar, was funktioniert, wo die Hebel liegen und wo der Aufwand am Anfang noch unterschätzt wird.

---

Der häufigste Fehler

Wenn ein Skill nur ein Wunsch bleibt

Der häufigste Fehler ist aus meiner Sicht nicht, dass ein Skill zu kurz ist.

Der häufigste Fehler ist, dass etwas als Skill bezeichnet wird, das in Wahrheit nur ein leicht ausformulierter Wunsch bleibt.

Zum Beispiel so etwas:

«Schreib eine Offerte im freundlichen Ton, frag bei Unklarheiten nach und achte auf eine saubere Struktur.»

Das ist noch nicht mal ein richtiger Prompt. Was würde ein neuer Mitarbeiter mit dieser Anweisung machen?

Es sagt nichts darüber, welche Inputs vorher geprüft werden müssen, welches System benutzt wird, wann gestoppt wird, was Freigabe braucht oder woran «fertig» überhaupt erkennbar ist.

Wenn die Schichten vermischt werden

Der zweite Fehler ist die Vermischung der Schichten. Dann landet Wissen im Skill, Ablauf im Gedächtnis, Tool-Zugriff irgendwo dazwischen und niemand weiss mehr, wo etwas hingehört.

Spätestens wenn sich Preise ändern, eine Vorlage angepasst wird oder ein Prozessschritt anders laufen soll, beginnt die Sucherei. Genau diese Sucherei will man mit einem guten System loswerden.

Security und Prompt Injection

Ein dritter Punkt ist Security.

Sobald Skills Verhalten beeinflussen, sind sie auch ein Risiko. Das gilt besonders dann, wenn Skills geteilt, importiert oder mit Hilfe eines Assistenten generiert werden.

Wer einen fremden Skill übernimmt, übernimmt nicht nur Komfort. Er übernimmt auch Annahmen, Prioritäten und potenziell unerwünschtes Verhalten.

Sobald Web-Inhalte, Dateizugriffe oder kleine Skripte dazukommen, wird Prompt Injection zu einer realen Angriffsfläche.

Darum ist unsere Haltung hier relativ einfach.

Externe oder generierte Skills nie blind übernehmen. Immer lesen. Immer prüfen. Immer verstehen. Erst dann nutzen.

Transparenz hilft. Blindes Vertrauen nicht.

Darum stellen wir bei diesem Thema lieber einen transparenten Skill-Creator und einen komplett lesbaren Beispiel-Skill zur Verfügung. Ein One-Click-Skill, den man einfach bedenkenlos importiert, ist aus meiner Sicht genau die falsche Erwartung.

---

Wie du mit dem ersten Skill starten kannst

So würde ich starten

Wenn du das Thema im Unternehmen angehen willst, würde ich nicht mit einer grossen Agentenarchitektur starten.

Ich würde genau eine Aufgabe wählen, die drei Bedingungen erfüllt:

• Sie kommt regelmässig vor
• Qualität ist wichtig
• Heute gibt es unnötige Reibung

Dann würde ich so vorgehen:

• Schreib den heutigen Ablauf ehrlich auf.
• Markiere, wo typischerweise Fehler oder Leerläufe entstehen.
• Definiere, woran ein gutes Resultat wirklich erkennbar ist.
• Bau daraus einen ersten kleinen Skill.
• Verbessere nach jedem Durchlauf den Skill, nicht nur den Output.

Es geht nicht darum, möglichst schnell viele Skills zu haben. Wichtiger ist, an einer einzigen wiederkehrenden Aufgabe zu lernen, wie aus implizitem Wissen eine brauchbare Arbeitsweise wird. Wenn das einmal sitzt, wird der Transfer auf andere Prozesse viel einfacher.

Zum Mitnehmen

Zu dieser Ausgabe stellen wir zwei Goodies bereit:

• Den kompletten Prompt eines Skill-Creator-Assistenten, transparent einsehbar
• Einen einfachen Beispiel-Skill für einen Wochenrückblick

Gerade der Wochenrückblick ist absichtlich simpel. An ihm sieht man sehr gut, wie Trigger, Ablauf, Qualitätslogik und Abschluss zusammenspielen.

Zu den Goodies →

---

Wenn du nicht allein an deinem KI-System bauen willst, sondern in einem geführten Rahmen mit anderen Führungskräften, dann ist genau dafür das KI-Kollektiv entstanden. Zwölf Monate Begleitung, sechs Säulen für die Transformation, über 40 Frameworks, Playbooks und Templates und 3 bis 5 Stunden Zeitaufwand pro Woche. Es geht dort nicht um noch einen Prompt oder noch ein Tool, sondern darum, wie du dein Unternehmen Schritt für Schritt zur KI-First-Organisation entwickelst.