agency-agents: 300+ Rollendefinitionen für deinen Coding-Agent – und wo sie an ihre Grenzen stoßen

Dein Coding-Agent hat genau eine Standardpersönlichkeit: der fähige Generalist. Bittest du ihn, einen Authentifizierungs-Flow zu prüfen, bekommst du vernünftige, aber beliebige Ratschläge. Bittest du dagegen einen Security-Reviewer mit Threat Model und Checkliste, bekommst du echte Findings. Dieser Unterschied kostet nichts außer einer Markdown-Datei – und genau deshalb hat agency-agents 149.312 Sterne erreicht.

Die Bibliothek ist wirklich nützlich. Sie ist aber auch nur ein Ordner voller Dateien auf einem einzigen Rechner – und das wird genau in dem Moment zur Grenze, in dem mehr als eine Person darauf angewiesen ist, dass diese Rollen tatsächlich etwas bedeuten. Dieser Artikel zeigt, was du bekommst, wie du nur den Teil installierst, den du brauchst, und wo der Unterschied zwischen einer Rollendefinition und einem Agent liegt, dem ein Team Arbeit zuweisen kann.

TL;DR

Dies ist einer von fünf Deep Dives aus unserer Übersicht über Open-Source-Tools, die Coding-Agents erweitern.

agency-agents ist eine Sammlung von mehr als 300 Agent-Rollendefinitionen in rund 20 Kategorien, MIT-lizenziert und mit einem einzigen Befehl installierbar in Claude Code, Cursor, Codex, Gemini CLI, OpenCode und etwa ein Dutzend weitere Tools. Jede Datei beschreibt eine Identität, einen Arbeitsprozess, Deliverables und eine Definition of Done. Eine Rolle verändert, wie ein Agent eine Aufgabe einordnet; sie gibt dem Agent kein Wissen, das ihm fehlt, und sie überdauert die Session nicht. Installiere eine Division, passe die Dateien an deinen Stack an und befördere die, zu denen du wöchentlich greifst, in gespeicherte Konfigurationen, die ein Team zuweisen kann.

Was du da installierst

Laut Repository-Baum vom 1. September 2026 sind es 312 Markdown-Dateien in 20 Kategorieordnern der obersten Ebene. Das README des Repositories spricht weiterhin von „230+“ – das ist veraltet.

Die Division engineering ist für die meisten Teams der Einstieg, und die Spezifität ist höher, als Prompt-Sammlungen üblicherweise erreichen. Neben Frontend Developer und Backend Architect gibt es einen Network Engineer, der auf Cisco IOS-XE und Juniper Junos zugeschnitten ist, einen Embedded Firmware Engineer für ESP32- und STM32-Targets, einen Incident Response Commander für Post-Mortems und On-Call-Bereitschaft sowie einen Codebase Onboarding Engineer, der darauf ausgelegt ist, ein Repository nur lesend zu erkunden und Fakten festzuhalten, statt Änderungen vorzuschlagen.

Gerade dieser letzte Fall zeigt, wie das Muster funktioniert. Eine schreibgeschützte Rolle mit ausdrücklichem Änderungsverbot ist ein anderes Werkzeug als dein Standard-Agent – und sie kostet eine einzige Datei.

Nur installieren, was du brauchst

git clone https://github.com/msitarzewski/agency-agents.git
cd agency-agents

./scripts/install.sh                                       # interactive
./scripts/install.sh --tool claude-code --division engineering,security
./scripts/install.sh --tool cursor --agent frontend-developer
./scripts/install.sh --list teams
./scripts/install.sh --tool opencode --division engineering --dry-run

Eine Warnung, die das Repository dokumentiert und die die meisten Artikel auslassen: Die Runtime von OpenCode registriert etwa 119 Agents und verwirft den Rest stillschweigend. Wenn du mit --division nur eine Teilmenge installierst, bleibst du unter dem Limit, und der Installer warnt dich, sobald eine Auswahl es überschreiten würde. Stilles Abschneiden ist der schlechteste überhaupt mögliche Fehlerfall, denn die Rolle, die du wolltest, fehlt – und nichts weist darauf hin.

Auch ohne diesen Bug ist es ein Fehler, alle 300 zu installieren. Eine Liste, an die du dich nicht erinnern kannst, ist eine Liste, die du nicht nutzen wirst. Installiere die Division, in der du arbeitest, lies fünf Dateien und lösche die, die nicht dazu passen, wie dein Team arbeitet.

Wo eine Rollendefinition an ihre Grenzen stößt

Eine Rolle ist ein Rahmen. Sie legt fest, wonach der Agent sucht, in welchem Format er liefert und was für ihn als erledigt gilt. Das ist mehr wert, als es klingt, denn schwache Agent-Ausgaben entstehen meist nicht dadurch, dass das Modell falsch liegt, sondern dadurch, dass es auf die falsche Form von Antwort hin optimiert.

Zwei Dinge kann eine Rolle nicht.

Sie kann keine Informationen liefern, die das Modell nicht hat. Eine Backend-Architect-Rolle produziert gut strukturierten Code gegen eine Schnittstelle, die sie sich selbst erschlossen hat. Die Rolle hat die Struktur verbessert. Das Ergebnis korrekt gemacht hat sie nicht.

Sie überdauert die Session nicht. Du aktivierst eine Rolle, sie erledigt eine Aufgabe, das Terminal wird geschlossen. Morgen tippst du die Aktivierung erneut. Neun der Divisions in diesem Repository beschreiben Jobs, die es nur innerhalb einer Organisation gibt – und das Tool, das sie installiert, kennt das Konzept Organisation überhaupt nicht. Es gibt keine Zuweisung, keinen Eintrag darüber, was der Security-Reviewer letzten Dienstag gefunden hat, und keine Möglichkeit für eine Kollegin oder einen Kollegen, irgendetwas davon zu sehen.

Von der Rollendefinition zum zuweisbaren Agent

Eine Rollendefinition ist ein Prompt, den du immer wieder neu eintippst. Ein Agent in Sharkly ist eine gespeicherte Konfiguration: Anweisungen, Runtime, Skills, Repositories und Umgebung. Das ist die dauerhafte Variante dessen, was eine Datei in ~/.claude/agents/ anstrebt.

Jeder Baustein hat genau eine Aufgabe. Der Agent legt fest, wie Arbeit behandelt werden soll. Der Computer stellt den Host und die lokalen Ressourcen bereit. Die Runtime führt die eigentliche Agent-Session aus, und zwar mit dem Coding-Tool, das dein Team ohnehin installiert hat. Der Task bleibt das gemeinsame Protokoll.

Sharkly ersetzt weder Claude Code noch Codex noch die Rollen aus diesem Repository. Es ergänzt sie um die gemeinsame Ebene aus Task, Computer, Kontext, Kontrolle und Review. Die Modellnutzung läuft weiterhin über die Abos oder API-Keys, die in diesen Tools konfiguriert sind.

Das Division-Konzept lässt sich direkt übertragen. Eine Crew ist eine wiederverwendbare Gruppe aus People und Agents, die von einem leitenden Agent koordiniert wird. Crews arbeiten leader-first: Der Leader liest den Aufgabenkontext, entscheidet, welche Mitglieder einzubeziehen sind, und führt deren Ergebnisse in einem einzigen Task zusammen, statt dass jeder Spezialist gleichzeitig loslegt. Genau darauf deutet agency-agents mit seinen acht Divisions hin, kann es aber nicht umsetzen, weil ein Ordner voller Dateien keinen Leader hat und keinen gemeinsamen Task, zu dem Ergebnisse zurückfließen könnten.

Ausführung, Blocker, Ergebnisse und die anschließende Diskussion landen in der Timeline des Tasks. Wenn jemand fragt, was der Security-Reviewer gefunden hat, steht die Antwort im Task.

Nutze das Repository als Bibliothek, nicht als Team

Nutze agency-agents direkt, wenn du eine Einzelperson bist, lokal arbeitest und für die heutige Arbeit einfach eine bessere Rahmung willst. Installiere eine Division, lies die Dateien, hab in zwanzig Minuten einen Nutzen davon.

Greife zu gespeicherten Agents, wenn mehr als eine Person die Rolle wiederverwenden muss, wenn Ergebnisse erst geprüft werden müssen, bevor sie zählen, oder wenn jemand in drei Monaten fragen wird, was eine Rolle produziert hat und warum. Der entscheidende Punkt ist keine Teamgröße, sondern die Frage, ob die Rolle die Session überdauern muss.

Der praktische Workflow: Behandle das Repository als Rohmaterial. Übernimm die Dateistruktur – das ist der wirklich wiederverwendbare Teil –, ersetze den generischen Inhalt durch deinen Stack und deine Definition of Done und befördere alles, wozu du zweimal pro Woche greifst, in eine gespeicherte Konfiguration. Die guten Dateien folgen alle demselben Aufbau: Identität, Mission, geordneter Prozess, Deliverables mit Format und Erfolgskriterien. Eine Review-Rolle mit einem siebenstufigen Prozess liefert über Sessions hinweg konsistente Ergebnisse. Eine ohne einen solchen Prozess liefert, was das Modell an diesem Tag eben so ausgibt.

Agents recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, übertragen Befugnisse und nehmen das Ergebnis ab.

Häufig gestellte Fragen

Funktioniert agency-agents auch mit anderen Tools als Claude Code? Ja. Ein Konvertierungsskript erzeugt pro Tool passende Integrationsdateien, und install.sh --tool richtet sich an ein bestimmtes. Zu den unterstützten Zielen gehören Claude Code, Cursor, Codex, Gemini CLI, OpenCode, Copilot, Windsurf, Aider und Kimi Code. Außerdem gibt es eine Desktop-App für macOS, Linux und Windows.

Sollte ich alle 300 Rollen installieren? Nein. Bei OpenCode geht es gar nicht, weil nur etwa 119 registriert und die übrigen ohne Warnung verworfen werden. Bei anderen Tools geht es, aber du wirst die meisten davon nicht nutzen. Installiere nach Division.

Machen Rollen einen Agent leistungsfähiger? Sie machen ihn besser gesteuert. Konsistenz und Ausgabeformat verbessern sich. Das Wissen über Fakten, die das Modell nie hatte, ändert sich nicht.

Ist das dasselbe wie ein Agent-Framework? Nein. Ein Framework bietet dir Runtime-Orchestrierung im Code. agency-agents bietet dir Markdown-Dateien, die das Verhalten eines bestehenden Agents verändern. Andere Ebene, keine Überschneidung.

Wie hängt das mit Sharkly Skills zusammen? Ein Skill ist eine Fähigkeit, die du an die Konfiguration eines Agents hängst. So wird sie mit diesem Agent wiederverwendet, statt auf jedem Rechner neu installiert zu werden. Die Rollendefinitionen aus diesem Repository sind gutes Ausgangsmaterial, um solche Skills zu schreiben.

Das Wichtigste in Kürze

agency-agents ist die derzeit beste Umsetzung einer Idee: Ein Agent arbeitet besser, wenn er weiß, welche Rolle er spielt. Installiere eine Division, lies die Dateien und bearbeite sie so, dass sie zu deinem Team passen.

Und sei dir dann über die Grenze im Klaren. Die Rollen kennen keine Fakten, die dein Modell nie bekommen hat, und sie bleiben nicht in irgendeiner Form bestehen, die ein Team sehen oder prüfen könnte. Eine Liste von Rollen ist ein guter Anfang. Sie ist keine Organisation. Sharkly übernimmt die andere Hälfte: Der Task ist das gemeinsame Protokoll, die Ausführung läuft auf Computern, die du über die Runtimes verbindest, für die du ohnehin bezahlst, und die Ergebnisse landen dort, wo ein Mensch sie prüfen und abnehmen kann.