Agency Agents als Open-Source-Framework für KI-Teams

Agency Agents ist vor allem eine Sammlung spezialisierter Rollen-Konfigurationen für verschiedene Coding-Agenten, kein vollständiges Orchestrierungs- oder Governance-System. Dieser Leitfaden erklärt die Auswahl, Installation, Teamaufteilung, Parallelisierung und Abnahme für Einzelentwickler, Produktgruppen, Entwicklungsteams und Unternehmen.

Letzte Aktualisierung: 13.08.2026. Geprüft anhand des offiziellen Agency-Agents-Repositorys, der Installationshinweise sowie der aktuellen Dokumentation zu Claude-Code-Subagenten und Cursor-Regeln.

Das offizielle README beschreibt jeden Agency-Agent im Kern als eigene Markdown-Datei mit Identität, Mission, Arbeitsablauf, Liefergegenständen und Erfolgskriterien. Genau daraus folgt die wichtigste Entscheidung: Agency Agents ist ein Open-Source-Framework für KI-Teams im Sinne einer installierbaren Sammlung von Rollen-Konfigurationen, aber keine vollständige Plattform für autonome Unternehmenszusammenarbeit. Für einen kontrollierten Start genügt eine kleine Auswahl aus Planungs-, Ausführungs- und Prüfrolle. Für dauerhafte parallele Aufgaben benötigen Sie zusätzlich Orchestrierung, Berechtigungsgrenzen, Protokollierung, isolierte Arbeitsumgebungen und verbindliche Freigaben. (github.com)

Geeignet: für Entwickler, Produktteams und Automatisierungsverantwortliche, die Rollen schnell standardisieren und in vorhandene Coding-Werkzeuge übernehmen möchten.

Nicht ausreichend: wenn Sie ohne weitere Infrastruktur einen revisionssicheren, dauerhaft laufenden Multi-Agent-Betrieb erwarten.

Dieser Artikel richtet sich an Einzelentwickler mit Claude Code oder Cursor, an Produkt- und Content-Gruppen sowie an technische Verantwortliche, die Agent-Aufgaben langfristig oder parallel ausführen lassen wollen. Wer nur eine einzelne, einfache Programmieraufgabe erledigen möchte, braucht zunächst kein komplettes Rollenpaket.

Was Agency Agents tatsächlich liefert

Agency Agents ordnet spezialisierte Rollen nach Aufgabenbereichen. Dazu gehören beispielsweise Planung, Frontend-Entwicklung, Architektur, Tests, Sicherheit, Dokumentation, Produktarbeit oder Marketing. Entscheidend ist nicht die Anzahl der Dateien, sondern die darin festgelegte Arbeitsweise.

Eine Rollen-Datei kann unter anderem definieren:

• welche Perspektive der Agent einnimmt;
• welche Zuständigkeit er übernimmt;
• welche Eingaben er benötigt;
• welche Arbeitsschritte er befolgt;
• welches Ergebnis er abliefern muss;
• wie er Unsicherheiten und Fehler dokumentiert;
• woran ein Mensch die Ausgabe prüft.

Damit entsteht eine wiederverwendbare Arbeitsanweisung. Es entsteht jedoch nicht automatisch ein neues Modell, ein eigener Prozessmanager oder ein autonomes Unternehmen.

Die offizielle Installationsbeschreibung nennt eine native Desktop-Anwendung für macOS, Linux und Windows. Zusätzlich werden Installationswege für verschiedene Coding-Werkzeuge sowie eine manuelle Nutzung als Referenz angeboten. Für Claude Code kann eine Rolle beispielsweise in das Agent-Verzeichnis kopiert werden; die konkrete Verzeichnisstruktur und die unterstützten Werkzeuge sollten vor jeder Installation im aktuellen Repository geprüft werden. (github.com)

Rollen-Konfiguration oder Multi-Agent-Plattform?

Diese Begriffe werden in Beiträgen häufig vermischt. Für die technische Planung müssen wir sie trennen.

Die Antwort auf die häufige Einordnung als „Multi-Agent-Framework“ lautet daher: Im weiteren Sinn ja, als Rollenbibliothek; im operativen Sinn nein, wenn damit ein vollständiger Orchestrator gemeint ist.

Claude Code besitzt eigene Subagent-Funktionen. Die offizielle Dokumentation unterscheidet zwischen Vordergrund- und Hintergrundausführung, eigenen Kontextfenstern, Werkzeugrechten und individuellen Systemanweisungen. Agency Agents kann solche Rollenbeschreibungen liefern, ersetzt aber nicht die Ausführungs- und Berechtigungslogik von Claude Code. (code.claude.com)

Unterstützte Werkzeuge und ihre Grenzen

Die Unterstützung ist keine dauerhaft feststehende Produkteigenschaft. Sie hängt von den aktuellen Installationsskripten, Integrationen und Formatvorgaben des Repositorys ab. Im geprüften offiziellen README werden unter anderem Claude Code, Cursor, Codex, Gemini CLI, OpenCode, Qwen, Osaurus, GitHub Copilot, Aider, Windsurf und weitere Werkzeuge genannt. Diese Liste sollte bei einem produktiven Rollout nicht aus einem älteren Blogbeitrag übernommen werden. (github.com)

Cursor dokumentiert projektbezogene Regeln unter .cursor/rules und unterstützt außerdem eine AGENTS.md-Datei als einfache Anweisungsschicht. Diese Regeln werden in den Kontext des Coding-Agenten eingebunden; sie sind deshalb eher mit wiederverwendbaren Arbeitsanweisungen als mit einem unabhängigen Agentenbetrieb vergleichbar. (docs.cursor.com)

Für Claude Code ist die Situation etwas anders. Eigene Subagenten können mit separatem Kontext, Werkzeugbeschränkungen und Berechtigungen angelegt werden. Sie können im Vordergrund blockierend oder im Hintergrund parallel laufen. Daraus folgt: Agency Agents liefert die Rolle, während Claude Code die konkrete Ausführung übernimmt. (code.claude.com)

Für Einzelentwickler: weniger Rollen, mehr Kontrolle

Ein persönliches Projekt scheitert selten daran, dass zu wenige Agenten vorhanden sind. Häufiger entstehen Probleme durch widersprüchliche Anweisungen, unklare Zuständigkeiten und zu viel automatisch erzeugten Kontext.

Wir empfehlen für den ersten Durchlauf drei Rollen:

1. Planung: formuliert Problem, Annahmen, Risiken und Akzeptanzkriterien;
2. Ausführung: implementiert eine klar abgegrenzte Änderung;
3. Prüfung: führt Tests, statische Analyse und fachliche Kontrolle durch.

Eine vierte Rolle ist sinnvoll, wenn Sicherheits- oder Datenschutzanforderungen früh berücksichtigt werden müssen. Die Installation des gesamten Katalogs ist dagegen selten der beste Start. Sie vergrößert die Auswahl, aber nicht automatisch die Qualität.

Zweiter Schritt: Rollen mit einem Vertrag verbinden

Jede Rolle sollte ein festes Ein- und Ausgabeformat besitzen. Ohne diesen Vertrag produzieren mehrere Persönlichkeiten oft nur Varianten derselben Antwort.

Ein brauchbarer Vertrag sieht beispielsweise so aus:

• Planungsrolle erhält: Issue, Repository-Regeln, technische Randbedingungen;
• Planungsrolle liefert: Plan, betroffene Dateien, Risiken, Teststrategie;
• Ausführungsrolle erhält: freigegebenen Plan und begrenzten Arbeitsbereich;
• Ausführungsrolle liefert: Änderungen, Testprotokoll, offene Punkte;
• Prüfrolle erhält: Diff, Tests, ursprüngliche Akzeptanzkriterien;
• Prüfrolle liefert: bestanden, abgelehnt oder manuelle Prüfung erforderlich.

Die Übergabe sollte nicht nur aus „Bitte prüfen Sie die Arbeit“ bestehen. Sie sollte festlegen, welche Dateien gelesen werden dürfen, welche Befehle erlaubt sind und welches Ergebnis als bestanden gilt.

Für Produkt- und Content-Gruppen: Rollen nach Lieferobjekten schneiden

Ein Produktteam benötigt meist keine künstliche Hierarchie aus vielen Agenten. Sinnvoller ist eine Kette aus vier klaren Lieferobjekten:

Die Rollen sollten nicht gemeinsam in einem unstrukturierten Gespräch arbeiten. Die Übergabe erfolgt besser über Dateien oder strukturierte Abschnitte. Dadurch bleibt nachvollziehbar, ob ein Agent auf Primärquellen, auf eine Annahme oder auf eine ältere Ausgabe reagiert hat.

Bei Content-Aufgaben ist besonders wichtig, dass die Prüfrolle nicht denselben Text einfach neu formuliert. Sie sollte stattdessen konkrete Kriterien kontrollieren: Quellenqualität, Zielgruppenbezug, widersprüchliche Aussagen, Datenschutz, Markenregeln und fehlende Handlungsanweisung.

Bei Produktarbeit gilt dasselbe Prinzip. Ein Research-Agent liefert keine Produktentscheidung. Er liefert Evidenz. Ein Design-Agent liefert keinen Produktionscode, wenn dies nicht ausdrücklich vereinbart wurde. Jede Rolle braucht einen definierten Endpunkt.

Für Softwareteams: parallele Arbeit mit klaren Grenzen

Mehrere Experten-Agenten sollten nur dann parallel arbeiten, wenn ihre Aufgaben und Dateien ausreichend entkoppelt sind. Eine Planungsanalyse, eine Dokumentationsrecherche und eine unabhängige Sicherheitsprüfung können oft gleichzeitig laufen. Änderungen an derselben zentralen Datei sollten dagegen nicht unkoordiniert parallel erfolgen.

Die offizielle Claude-Code-Dokumentation beschreibt parallele Hintergrund-Subagenten und weist auf unterschiedliche Berechtigungsbedingungen hin. Hintergrundaufgaben können ohne neue interaktive Freigabe scheitern, wenn ein benötigter Werkzeugaufruf eine Bestätigung verlangt. Das ist ein betrieblicher Unterschied, kein bloßes Detail der Benutzeroberfläche. (code.claude.com)

Für Codeänderungen brauchen wir mindestens Branch- oder Worktree-Isolation. Jeder Agent muss wissen, auf welchem Commit er arbeitet. Nach der Ausführung folgen Tests, Diff-Prüfung und Merge-Gate. Ein Agent, der „fertig“ meldet, hat noch keine Freigabe erteilt.

Bei parallelen Aufgaben sollten wir drei Zustände unterscheiden:

• bereit: Eingaben vollständig, Abhängigkeiten erfüllt;
• in Arbeit: Agent darf Dateien oder Berichte verändern;
• zur Prüfung: Ergebnis liegt vor, aber ein Mensch oder ein Prüf-Agent muss entscheiden.

Diese Zustände verhindern, dass ein nachgelagerter Agent auf halbfertige Dateien zugreift.

Kontrollierte Installation in Claude Code und Cursor

Die konkrete Installation muss immer gegen das aktuelle Repository geprüft werden. Das offizielle Projekt nennt für Claude Code sowohl einen Installationsskript-Weg als auch das manuelle Kopieren einzelner Kategorien. Außerdem wird eine Desktop-Anwendung als empfohlener Einstieg beschrieben. (github.com)

Dritter Schritt: kontrollierte Installation

1. Repository und Lizenz prüfen.

Lesen Sie README, Lizenzdatei, Installationsskript und Release-Hinweise. Übernehmen Sie keine Rolle aus einem ungeprüften Fork.

1. Nur eine Kategorie auswählen.

Starten Sie mit Rollen, die zu einem realen Projekt passen. Für ein Webprojekt genügen beispielsweise Planung, Implementierung und Review.

1. Zielwerkzeug feststellen.

Prüfen Sie, ob Claude Code, Cursor oder ein anderes Werkzeug die benötigte Rollenstruktur aktuell unterstützt. Eine Agent-Datei allein garantiert keine automatische Erkennung.

1. Installation in einem Testprojekt durchführen.

Verwenden Sie zunächst ein nicht sensibles Repository. Entfernen Sie API-Schlüssel, Kundendaten und Produktionszugänge.

1. Rolle einzeln aufrufen.

Testen Sie nicht sofort ein ganzes Team. Prüfen Sie, ob Name, Aufgabenbeschreibung, Werkzeugrechte und Ausgabeformat korrekt übernommen wurden.

1. Ein festes Übergabeformat definieren.

Speichern Sie Plan, Diff, Testergebnis und offene Punkte in getrennten Abschnitten oder Dateien.

1. Fehler absichtlich provozieren.

Geben Sie eine unvollständige Anforderung oder einen fehlenden Befehl vor. Eine brauchbare Konfiguration muss Unsicherheit melden, statt plausibel klingende Ergebnisse zu erfinden.

1. Erst danach parallelisieren.

Wenn Einzelrollen reproduzierbar arbeiten, können unabhängige Aufgaben parallel gestartet werden. Gemeinsame Dateien bleiben zunächst sequenziell.

Für Cursor ist die Projektregel-Schicht besonders relevant. Die offizielle Dokumentation beschreibt Regeln als versionierbare Anweisungen für Agent und Inline Edit. Das ist nützlich für Stil, Architektur und Arbeitsabläufe, ersetzt aber weder Branch-Isolation noch eine zentrale Aufgabenverwaltung. (docs.cursor.com)

Unternehmens-Governance muss ergänzt werden

Agency Agents kann Rollen standardisieren. Es kann aber nicht automatisch die vollständige Governance eines Unternehmens bereitstellen. Die kritischen Lücken liegen meist an fünf Stellen.

Berechtigungen: Eine Rolle darf nicht pauschal Zugriff auf jedes Repository, jede Shell-Funktion und jedes Netzwerkziel erhalten. Lesen, Schreiben, Ausführen und Veröffentlichen müssen getrennt bewertet werden.

Geheimnisse: API-Schlüssel gehören nicht in Rollen-Dateien, Prompts oder ungeschützte Umgebungsdateien. Für produktive Abläufe benötigen Unternehmen Secret-Management, Rotation und eine Regel, welche Agenten Geheimnisse überhaupt verwenden dürfen.

Protokollierung: Ein Abschlussbericht reicht nicht als Audit. Erfasst werden sollten mindestens Auftrag, Commit, Werkzeugaufrufe, Testergebnisse, Freigaben und Fehler. Dabei muss die Aufbewahrung mit internen Regeln und der DSGVO vereinbar sein.

Datenabfluss: Besonders riskant sind Agenten mit automatischem Terminalzugriff und Internetzugang. Cursor weist bei Hintergrund-Agenten ausdrücklich auf isolierte virtuelle Maschinen, automatische Befehlsausführung und mögliche Risiken durch Prompt Injection hin. (docs.cursor.com)

Menschliche Freigabe: Für Änderungen an Infrastruktur, Authentifizierung, personenbezogenen Daten oder Rechnungslogik sollte ein Mensch vor dem Merge entscheiden. Ein Prüf-Agent kann Hinweise liefern, aber keine alleinige Verantwortlichkeit übernehmen.

Für den Datenschutz sollten Unternehmen außerdem festlegen, welche Repository-Inhalte an externe Modelle gelangen dürfen, wie lange Sitzungsdaten gespeichert werden und ob Privacy-Modi aktiviert sind. Ergänzende Hinweise zu Datenschutzanforderungen finden Sie in unserer Datenschutz-Übersicht für Remote-Arbeitsumgebungen.

Umgebungen für kleine und größere Teams

Die Zahl der installierten Rollen sagt wenig über den benötigten Betrieb aus. Entscheidend sind parallele Aufgaben, Abhängigkeiten, Installationszeiten, Laufdauer und Sensibilität der Daten.

Eine lokale Installation eignet sich für die Evaluierung. Sie ist oft die beste Wahl, wenn ein Entwickler nur eine Rolle testet und alle Aktionen direkt beobachtet. Sie wird unpraktisch, sobald mehrere Agenten gleichzeitig Abhängigkeiten installieren, Tests ausführen oder lange Recherchen abarbeiten.

Eine Remote-Mac-Umgebung kann interessant sein, wenn das Zielwerkzeug oder der Build-Prozess macOS voraussetzt, wenn mehrere Sitzungen getrennt laufen sollen oder wenn ein persönlicher Rechner nicht dauerhaft verfügbar sein soll. Entscheidend sind dann nicht nur CPU und Arbeitsspeicher, sondern auch Zugriffsmodell, Sitzungsstabilität, Snapshot-Strategie, Netzwerkfreigaben und Datenlöschung. Einen Überblick über die Remote-Mac-Optionen von ZekVPS können Sie als nächsten Planungsschritt heranziehen.

Die Skalierungsentscheidung sollte deshalb an diesen Fragen hängen:

• Wie viele Aufgaben müssen tatsächlich gleichzeitig laufen?
• Wie lange dauert eine typische Sitzung?
• Müssen Abhängigkeiten bei jedem Lauf neu installiert werden?
• Können mehrere Agenten dasselbe Repository sicher getrennt bearbeiten?
• Welche Daten dürfen die Umgebung verlassen?
• Wie wird ein fehlgeschlagener Lauf wiederholt?

Wenn nur weitere Rollen installiert werden, aber keine dieser Fragen beantwortet ist, entsteht keine belastbare Skalierung.

Abnahme: Woran erkennen wir einen brauchbaren Agentenbetrieb?

Vor dem produktiven Einsatz sollte jedes Team mit einem realen, aber begrenzten Projekt testen. Die Abnahme darf nicht nur fragen, ob der Agent überzeugend formuliert. Sie muss prüfen, ob der gesamte Übergabeweg funktioniert.

• [ ] Eine Planungsrolle erzeugt nachvollziehbare Ziele, Annahmen und Akzeptanzkriterien.
• [ ] Eine Ausführungsrolle verändert nur den freigegebenen Arbeitsbereich.
• [ ] Eine Prüfrolle erhält den tatsächlichen Diff und nicht nur eine Zusammenfassung.
• [ ] Fehlende Informationen werden als offene Punkte gemeldet.
• [ ] Ein fehlgeschlagener Werkzeugaufruf kann kontrolliert wiederholt werden.
• [ ] Eine Wiederholung erzeugt keinen unbemerkten zweiten Commit oder doppelte externe Aktion.
• [ ] Rollen erhalten nur die für ihre Aufgabe erforderlichen Berechtigungen.
• [ ] Geheimnisse erscheinen nicht in Prompts, Logs oder Artefakten.
• [ ] Kontext aus einem anderen Projekt wird nicht in die aktuelle Aufgabe übernommen.
• [ ] Ein Mensch kann die Ausgabe innerhalb eines festgelegten Zeitfensters prüfen.
• [ ] Tests, Quellen, Diff und Freigabe werden gemeinsam gespeichert.
• [ ] Das Team weiß, wann eine Aufgabe sequenziell statt parallel ausgeführt werden muss.

Unser Mindestvorschlag lautet: drei bis fünf Rollen, ein echtes Projekt, ein klarer End-to-End-Ablauf. Erst wenn Planung, Ausführung und Kontrolle reproduzierbar funktionieren, sollte das Team zusätzliche Spezialisten aufnehmen.

Bewertung für unterschiedliche Anwender

Diese Bewertung misst nicht die Qualität einzelner Rollen. Sie bewertet, wie viel zusätzliche Infrastruktur die jeweilige Zielgruppe benötigt. Für einen Entwickler kann eine Markdown-Rolle sofort produktiv sein. Für ein Unternehmen ist sie nur ein Baustein in einem größeren Kontrollsystem.

Der wichtigste Unterschied zu einem vollständigen AI-Agent-Team liegt daher im Betrieb. Ein Team aus Rollen entsteht erst durch Aufgabenverträge, einen Koordinator, getrennte Arbeitsbereiche, Fehlerbehandlung, Protokollierung und Freigaben. Ohne diese Elemente bleiben mehrere Agenten nebeneinander installierte Konfigurationen.

Wenn die aktuelle Lösung ausschließlich auf einem lokalen Rechner läuft, entstehen bei wachsender Nutzung typische Nachteile: Der Arbeitsplatz ist während langer Läufe blockiert, parallele Sitzungen konkurrieren um Ressourcen und ein Neustart kann Zwischenstände verlieren. Bei einer unkontrollierten Cloud-Umgebung kommen unklare Datenaufbewahrung, wechselnde Abhängigkeiten und fehlende Trennung zwischen Projekten hinzu. Für kurzfristige Tests ist das vertretbar. Für dauerhaft laufende oder parallele Aufgaben ist eine reproduzierbare, isolierte Umgebung die bessere technische Grundlage.

Unser sinnvollster Einstieg ist deshalb kein vollständiger Rollout: Wählen Sie eine Planungsrolle, eine Ausführungsrolle und eine Prüfrolle. Testen Sie sie an einem echten Projekt mit dokumentierter Übergabe und menschlicher Abnahme. Wenn die Rollen später dauerhaft oder parallel laufen sollen, prüfen Sie zusätzlich eine stabile Remote-Mac- und Isolationslösung von ZekVPS, statt den lokalen Rechner dauerhaft als unbeaufsichtigten Agent-Server zu verwenden.