Ein Pull Request wird zusammengeführt, danach lässt sich eine Webanwendung mit einem Befehl installieren: npx skills add phazonoverload/wordsworth. Wer den Befehl ausführt, bekommt sieben Werkzeuge zur Textanalyse direkt in den Agenten: Lesbarkeitswerte, Hedge-Wörter-Erkennung, die Prüfung, ob ein Text seine Versprechen einlöst. Keine Oberfläche nötig.
Dahinter steht Kevin Lewis, der Entwickler von Wordsworth, einer Webanwendung für technische Redakteure. In seinem Bericht schreibt er etwas, das zunächst wie ein Eingeständnis klingt: Er hat die App gebaut, gestartet und seit Monaten nicht mehr geöffnet. Sein eigenes Produkt nutzt er nicht über das Dashboard, sondern über den Agenten, der es bei Bedarf aufruft.
Das ließe sich als persönliche Anekdote abtun. Interessanter ist die Einordnung, die er gleich mitliefert: kein Scheitern des Produkts, sondern eine Verschiebung. Damit stellt sich die Frage, wie dein eigenes Werkzeug überhaupt noch zu den Leuten kommt, die es brauchen.
Was ein Agent Skill technisch ist und was Wordsworth daraus macht
Ein Agent Skill ist kein Programm im klassischen Sinn. Es ist eine Beschreibung von Fähigkeiten in einer Form, die ein Agent lesen, verstehen und bei Bedarf aufrufen kann. Eine Werkzeugdefinition, oft nicht mehr als eine Markdown-Datei mit klaren Angaben dazu, was das Werkzeug tut und welche Eingaben es erwartet. Der Agent muss nichts über die interne Umsetzung wissen. Er braucht den Namen der Fähigkeit und die Zusage, dass sie verlässlich ein Ergebnis zurückliefert.
Wordsworth besteht aus sieben solcher Fähigkeiten. Eine bewertet die Lesbarkeit. Eine andere sucht nach Weichmachern und Formulierungen, die sich vor einer klaren Aussage drücken. Eine dritte prüft, ob ein Text das einlöst, was er am Anfang verspricht. Als Web-App bedeutete jede dieser Analysen denselben Ablauf: URL merken, Browser öffnen, Text einfügen, Knöpfe drücken, Ergebnis lesen, zurückkopieren. Als Skill bleibt der Teil übrig, der tatsächlich Wert erzeugt. Die Analyse läuft, wenn sie gebraucht wird.
Entscheidend ist die Reichweite. Ein Skill, der einmal veröffentlicht ist, funktioniert in jedem Agenten, der das Format unterstützt. Keine Version für Plattform A, keine Sonderlösung für Plattform B. Eine standardisierte Einbindung, ein standardisierter Aufruf. Das ist der Unterschied zwischen einem Werkzeug im Regal und einem in der Tasche.
Das Dashboard war immer die Vertriebsschicht, nie das Produkt
Lewis bringt es in einem Satz unter: Das Dashboard sei immer die Distributionsebene gewesen. Banner, Newsletter, SEO-Seiten, Landingpages. Das alles diente nie dazu, eine Fähigkeit bereitzustellen, sondern dazu, Aufmerksamkeit zu kaufen. Man überzeugt jemanden, eine URL zu besuchen, dort zu bleiben und die eigene Sache zu benutzen.
Das funktioniert, wenn drei Dinge zusammenkommen: Marketingbudget, gutes Timing und die Geduld eines Missionars. Wer Software als Einzelperson oder kleines Team baut, hat selten alle drei. Und selbst mit allen drei bleibt der Umweg: Identität anlegen, Seite laden, Oberfläche verstehen, Aufmerksamkeit aufbringen. Jeder Schritt ist Reibung, und Reibung kostet Nutzer.
Eine Werkstatt als Bild: Ein gutes Werkzeug im Schaufenster ist noch lange nicht in der Hand des Handwerkers. Das Schaufenster erklärt, warum das Werkzeug gut ist. Die Werkzeugtasche entscheidet, ob es benutzt wird. Solange Software nur im Schaufenster stand, war das der Preis des Geschäfts. Lewis hält Web-Apps nicht für schlecht, ausdrücklich nicht. Seine These ist enger: Die Art, wie Menschen mit Software umgehen, verschiebt sich, und damit verschiebt sich, welcher Kanal noch trägt.
Agent Integration: Der Agent wird zum Nutzer
Wenn ein Großteil der täglichen Arbeit über einen einzigen Agenten läuft, der sich mit verschiedenen Plattformen verbindet, ist es nicht mehr die Aufgabe des Nutzers, sich den Weg zu deinem Werkzeug zu merken. Es ist deine Aufgabe, dich mit diesem Agenten zu verbinden. Skills und MCP Server sind die beiden Wege. Der MCP Server stellt dem Agenten eine Schnittstelle bereit, der Skill eine konkrete, benannte Fähigkeit in einem Format, das der Agent direkt ausführen kann.
Lewis verweist auf einen MCP Server, über den nach seinen Angaben zehntausende AI Tools erreichbar sind, bereit zum Entdecken und Nutzen. Seine Beobachtung daraus: Es gibt viele Werkzeuge, die existieren, funktionieren und nützlich sind, und trotzdem öffnet sie niemand, weil niemand von ihnen weiß. Sobald dasselbe Werkzeug als Skill erreichbar wird, landet es bei tausenden Nutzern, die nie gewusst haben, dass ihnen etwas gefehlt hat.
Der Nutzer beschreibt in natürlicher Sprache, was er will. Der Agent kümmert sich um das Routing, wählt das passende Werkzeug und führt es aus. Dein Werkzeug muss in dieser Kette nicht überzeugen, sondern funktionieren. Die Oberfläche verschwindet aus dem Entscheidungsprozess, die Fähigkeit bleibt.
Die Verteilungsrechnung kippt zugunsten von Skill Distribution
Sieben Analysen als Web-App bedeuten sieben Gründe, eine Seite zu besuchen und sich durch eine Oberfläche zu klicken. Dieselben sieben Analysen als Skill bedeuten sieben Aufrufe, die in der Arbeitsumgebung stattfinden, in der die Arbeit ohnehin passiert. Der Unterschied liegt nicht in der Funktion, sondern in den Kosten, die der Nutzer vor dem ersten Ergebnis tragen muss.
Das Skill-Format ist nicht neu. Was sich ändert, ist die Zahl der Agentenplattformen, die Skills konsumieren. Solange es eine einzige Insellösung war, blieb Veröffentlichen ein Nischenprojekt. Sobald mehrere Plattformen dasselbe Format verstehen, wird aus einem Sonderweg eine Distributionsstrategie. Ein Werkzeug, das als Agent Skill publiziert ist, muss nicht mehr erklären, wie man es findet. Es muss gefunden werden können.
Für Software Distribution heißt das konkret: Die Einbindung wird zum Produktmerkmal. Eine Fähigkeit, die man mit einer Zeile installiert, konkurriert nicht mit einer besseren Fähigkeit, sondern mit einer erreichbaren. Lewis formuliert es drastisch: Du kannst die ausgefeilteste Schreibanalyse-Plattform der Welt bauen. Wenn der Wettbewerber als Skill ausgeliefert wird, der sich mit einem Befehl installiert und in dem Agenten läuft, den dein Team bereits benutzt, gewinnt der Wettbewerber. Nicht wegen der Qualität, sondern weil er ankommt.
Web App in Agent Skill umwandeln: was das praktisch verlangt
Wer diesen Schritt gehen will, muss sein Produkt nicht neu bauen. Die Fähigkeit ist vorhanden, sie braucht nur eine Beschreibung, die ein Agent lesen kann. Statt einer Landingpage mit Featureliste entsteht eine knappe Definition: Was tut das Werkzeug, welche Eingabe erwartet es, was gibt es zurück, welche Grenzen hat es. Genau dieser Text entscheidet, ob ein Agent das Werkzeug im richtigen Moment auswählt oder daneben greift.
Der zweite Teil ist die Anbindung. Ein MCP Server für Tool Distribution deckt Fälle ab, in denen mehrere Fähigkeiten oder dynamische Daten im Spiel sind. Ein einzelner Skill genügt, wenn die Funktion klar umrissen ist und ohne großen Zustand auskommt. Wordsworth mit seinen sieben Analysen liegt in dieser zweiten Kategorie: überschaubare Funktionen, klare Ein- und Ausgaben, kein Grund für eine eigene Oberfläche.
Der dritte Teil ist der unbequemste: die Frage, was mit dem bestehenden Dashboard passiert. Lewis nennt es einen versunkenen Kostenposten. Die Web-App existiert weiter, sie bleibt erreichbar, sie wird nicht abgeschaltet. Sie ist nur nicht mehr der Ort, an dem das Produkt sein Geld verdienen wird. Für viele Teams bedeutet das, den sichtbarsten Teil ihrer Arbeit ruhigzustellen und stattdessen in etwas zu investieren, das man nicht mit einem Screenshot zeigen kann.
Was das nüchtern betrachtet bedeutet
Vor zehn Jahren bestand die Distribution von Software aus Hosting, Landingpage, Werbung oder SEO, Blogbeiträgen, Konferenzen und Pressearbeit. All das war Aufwand für eine Fähigkeit, die Menschen einfach nur benutzen wollten. Heute kann dieselbe Fähigkeit in einer Markdown-Datei und einer Werkzeugdefinition bestehen. Das klingt kleiner, als es ist, und ist mehr Arbeit, als es aussieht.
Trotzdem wäre es falsch, daraus eine Regel für alles abzuleiten. Werkzeuge, bei denen das Sehen, Vergleichen und Erkunden Teil des Werts ist, gehören weiterhin in eine Oberfläche. Datenbanken, Bildbearbeitung, alles Visuelle wird nicht dadurch besser, dass es unsichtbar im Hintergrund läuft. Die Verschiebung betrifft Werkzeuge mit klar benennbaren Fähigkeiten: analysieren, prüfen, umwandeln, abrufen. Dort ist die Oberfläche Ballast, und dort entscheidet die Einbindung über Sichtbarkeit.
Die praktische Konsequenz ist unangenehm konkret. Prüfe, ob deine Kernfunktion sich in einem Satz beschreiben lässt. Wenn ja, prüfe, ob ein Agent sie heute aufrufen könnte. Wenn nein, ist das der nächste Pull Request, nicht das nächste Redesign. Ein Werkzeug, das nur im Browser erreichbar ist, hat kein Marketingproblem. Es hat ein Erreichbarkeitsproblem, und das löst kein Banner.
Quelle: lws.io
