Eine Gruppe aus AI Agenten erzeugt Aufgaben, verliert Statusinformationen und greift auf zu viele Werkzeuge zu.
Die schnellste Lösung: Paperclip Multi-Agent-Workflow als Kontrollschicht einsetzen, zunächst nur ein kleines Ziel mit klaren Rollen, manueller Abnahme und rücksetzbaren Aufgaben betreiben.
Für wen dieser Leitfaden gedacht ist
Dieser Leitfaden richtet sich an Entwickler, die mehrere vorhandene Agenten zu einem nachvollziehbaren Ablauf verbinden möchten. Er passt außerdem zu Automatisierungsteams, die Aufgaben delegieren, Statusänderungen prüfen und menschliche Freigaben erzwingen müssen.
Wenn Sie bereits ein funktionierendes Agent-System, Modellzugänge und ein konkretes Arbeitsziel besitzen, können Sie Paperclip als Organisations- und Governance-Schicht testen. Wenn Sie dagegen noch keinen einzelnen Agenten zuverlässig ausführen können, löst eine zusätzliche Plattform Ihr Grundproblem nicht.
Zuletzt aktualisiert am 14.08.2026. Die Angaben wurden anhand des offiziellen Paperclip-Repositorys, der offiziellen Dokumentation sowie der aktuellen Veröffentlichungsinformationen geprüft. Adapter, Installationsbefehle und Bereitstellungsoptionen sollten vor jedem produktiven Einsatz erneut kontrolliert werden.
Die Plattformgrenze vor dem ersten Start
Paperclip ist weder ein Sprachmodell noch ein vollständiges Agent-Framework. Nach der offiziellen Produktbeschreibung verwaltet es eine Organisation aus AI Agenten: Ziele werden formuliert, Rollen vergeben, Aufgaben erstellt, Budgets begrenzt und Ergebnisse protokolliert. Der eigentliche Agent bringt seine eigene Laufzeit, seine Prompts, seine Werkzeuge und seine Modellverbindung mit. Diese Trennung ist für Ihre Planung entscheidend. Sie müssen die Agenten zuerst unabhängig testen und anschließend in Paperclip einbinden. Die Produktdefinition von Paperclip beschreibt diese Kontrollschicht ausdrücklich.
Ein Paperclip Multi-Agent-Workflow löst damit vier Probleme, die bei lose verbundenen Agenten schnell sichtbar werden:
- Unklare Zuständigkeit: Ohne feste Rollen bearbeiten mehrere Agenten denselben Teilauftrag oder niemand übernimmt die nächste Entscheidung.
- Fehlende Nachvollziehbarkeit: Ein Chatverlauf zeigt nicht zuverlässig, welcher Agent eine Aufgabe übernommen, verändert oder abgeschlossen hat.
- Unkontrollierte Berechtigungen: Ein Agent kann unter Umständen auf Arbeitsverzeichnisse, Repositorys oder Produktionsschnittstellen zugreifen, die für seine Rolle nicht erforderlich sind.
- Verlust von Sitzungs- und Zielkontext: Ein nach jedem Lauf neu gestarteter Prozess kennt weder die übergeordnete Absicht noch die bisherigen Übergaben.
Paperclip arbeitet laut offizieller Agent-Dokumentation mit einem wiederkehrenden Ausführungsmodell: Ein Ereignis oder Zeitplan weckt den Agenten, ein Adapter startet seine Laufzeit, der Agent prüft und beansprucht Aufgaben, führt die Arbeit aus und meldet Ergebnis, Verbrauch und Sitzungszustand zurück. Der Lauf wird anschließend als Datensatz gespeichert. Die Beschreibung des Agent-Lebenszyklus ist deshalb wichtiger als eine große Organisationsgrafik.
Die erste Stunde mit einer kleinen Organisation
Beginnen Sie nicht mit einer vollständigen „AI-Firma“. Legen Sie eine einzige überprüfbare Aufgabe an, zum Beispiel die Analyse eines geschützten Test-Repositorys mit einem schriftlichen Bericht als Ergebnis.
Erstellen Sie anschließend nur die Rollen, die für diesen Ablauf benötigt werden:
- Koordination: nimmt das Ziel entgegen, zerlegt es und verteilt die Arbeit;
- Ausführung: bearbeitet den technischen oder fachlichen Teilauftrag;
- Prüfung: kontrolliert Ergebnis, Quellen, Tests und Abnahmekriterien.
Die Rollen müssen sich gegenseitig ausschließen. Der Prüfagent sollte nicht automatisch Produktionsdateien verändern dürfen, wenn seine Aufgabe nur die Qualitätskontrolle ist. Der Koordinator sollte nicht gleichzeitig jede Detailaufgabe selbst ausführen, sonst bleibt die Delegation nur eine grafische Darstellung.
Formulieren Sie für jede Rolle drei Punkte:
- Welche Entscheidung darf der Agent selbst treffen?
- Welche Ausgabe muss er erzeugen?
- Bei welchem Zustand muss er an die übergeordnete Rolle zurückmelden?
Ein guter erster Zieltext ist messbar, aber nicht künstlich umfangreich: „Erstellen Sie eine geprüfte technische Zusammenfassung des Test-Repositorys mit offenen Risiken, reproduzierbaren Prüfschritten und einer menschlichen Abnahme.“ Das Ziel lässt sich später in Teilaufgaben zerlegen und besitzt einen klaren Endpunkt.
Vermeiden Sie es, große Agent-Vorlagen ungeprüft zu importieren und sofort zu aktivieren. Vorgefertigte Rollen können nützlich sein, bringen aber oft unklare Werkzeuge, überlappende Zuständigkeiten oder nicht passende Berichtslinien mit. Die Zahl der sichtbaren Agenten ist kein Produktivitätsmaßstab. Entscheidend sind die Qualität der Übergaben und die Möglichkeit, einen Fehler zurückzuverfolgen.
Der erste Aufgabenfluss
Ein brauchbarer Ablauf besteht aus einer kontrollierten Kette:
- Der Koordinator erhält das Hauptziel.
- Er erstellt einen Analyseauftrag und einen Prüfauftrag.
- Der Ausführungsagent übernimmt ausschließlich den Analyseauftrag.
- Nach Abschluss meldet er Ergebnis, offene Punkte und verwendete Dateien zurück.
- Der Prüfagent kontrolliert die Ausgabe.
- Der Koordinator entscheidet über Überarbeitung, Freigabe oder Abbruch.
Testen Sie diesen Ablauf zunächst mit einem absichtlich ungefährlichen Arbeitsverzeichnis. Die Aufgabe sollte sich zurücksetzen lassen, ohne Datenverlust zu verursachen. Prüfen Sie dabei nicht nur, ob der Status von „offen“ auf „in Bearbeitung“ und anschließend auf „erledigt“ wechselt. Achten Sie auf die Fehlerpfade:
- Was geschieht, wenn der Agent keine gültige Antwort liefert?
- Wird eine fehlgeschlagene Aufgabe erneut zugewiesen oder bleibt sie blockiert?
- Kann ein Mensch den Auftrag an einen anderen Agenten verschieben?
- Wird der übergeordnete Agent nach der Rückmeldung tatsächlich geweckt?
- Sind Kommentare, Dateien und Statusänderungen gemeinsam prüfbar?
Gerade der letzte Punkt unterscheidet eine belastbare Agent-Aufgabenverwaltung von einer Sammlung paralleler Skripte. Ein Ergebnis ohne Status, Zuständigkeit und Rückverfolgbarkeit ist für den Dauerbetrieb nur schwer zu kontrollieren.
Der erste Tag mit echten Agenten
Paperclip kann unterschiedliche Laufzeiten über Adapter verbinden. Die offizielle Adapterübersicht beschreibt die Adapter als Brücke zwischen Kontrollschicht und Agent-Runtime; in der Dokumentation werden unter anderem Claude, Codex, Gemini und eigene HTTP-Dienste als mögliche Laufzeittypen genannt. Welche Verbindung in Ihrer Umgebung funktioniert, hängt von Adapterversion, Installationspfad, Zugangsdaten und Berechtigungen ab. Die Adapterübersicht ist daher vor einer konkreten Integration zu prüfen.
Für jeden Agenten sollten Sie separat dokumentieren:
- verwendetes Modell und Modellkonto;
- Startbefehl oder HTTP-Endpunkt;
- Arbeitsverzeichnis;
- erlaubte Werkzeuge;
- maximale Laufzeit und Budgetgrenze;
- benötigte Umgebungsvariablen;
- lesbare und veränderbare Datenquellen;
- Verhalten bei Netzwerkfehlern und Sitzungsabbruch.
Die offizielle Schnellinstallation setzt Node.js 20 oder neuer und pnpm 9.15 oder neuer voraus. Der lokale Start verwendet standardmäßig den Port 3100; beim manuellen Entwicklungsstart wird eine eingebettete PostgreSQL-Datenbank angelegt. Diese Angaben stammen aus dem offiziellen README und sollten bei einer späteren Version erneut kontrolliert werden.
Konfiguration und Einsatzumgebung
| Einsatzumgebung | Geeignet für | Stärken | Kritische Grenzen |
|---|---|---|---|
| Lokaler Rechner | Erster Test und sichere Einzelbenutzer-Experimente | Schnell eingerichtet, leicht zurückzusetzen | Rechner muss laufen; kein automatischer Teamzugang |
| Remote Mac | Agenten mit macOS-Abhängigkeiten, Xcode- oder Apple-Werkzeugen | Dauerhafte Sitzung, entfernte Bedienung, vertraute Mac-Toolchain | Zugangsschutz, Sitzungsverwaltung und Datenschutz müssen sauber geplant werden |
| Linux-Server | Zentraler Dauerbetrieb ohne macOS-spezifische Werkzeuge | Gute Automatisierbarkeit, klare Service- und Backup-Struktur | Agenten mit macOS-Anforderungen sind dort nicht direkt ausführbar |
| Gemeinsame Teamumgebung | Mehrere Benutzer, Freigaben und getrennte Projekte | Zentraler Zugriff, einheitliche Protokolle und Governance | Höherer Aufwand für Rollen, Secrets, Backups und Mandantentrennung |
Ein Remote Mac ist nicht automatisch besser als ein Linux-Server. Wenn Ihre Agenten lokale Apple-Werkzeuge, macOS-Arbeitsverzeichnisse oder grafische Anwendungen benötigen, kann er die passende Laufzeit sein. Für reine API-, Daten- oder Repository-Aufgaben ist eine Linux-Bereitstellung häufig einfacher zu betreiben. Entscheiden Sie nach den Anforderungen der Agenten, nicht nach der Größe des Organigramms.
Governance, Freigaben und Beobachtung
Ein Multi-Agent-Plattformbetrieb ohne Governance verschiebt das Risiko nur: Statt eines einzelnen Agenten haben Sie dann mehrere Prozesse, die sich gegenseitig Aufgaben erzeugen und möglicherweise gemeinsam auf kritische Systeme zugreifen.
Richten Sie im ersten Betriebszyklus mindestens diese Kontrollpunkte ein:
- Freigabe vor Änderungen an Produktionsressourcen;
- Freigabe bei Budgetüberschreitung;
- Protokollierung jeder Agentenaktivierung;
- Timeout für Aufgaben, die keine Rückmeldung liefern;
- Benachrichtigung bei wiederholten Fehlern;
- getrennte Zugangsdaten für Projekte und Benutzer;
- regelmäßige Sicherung von Datenbank, Konfiguration und Arbeitsartefakten.
Paperclip unterstützt Freigaben unter anderem für Agentenaktivierung, Strategiefreigaben, Budgetüberschreitungen und allgemeine Board-Entscheidungen. Der dokumentierte Lebenszyklus einer Freigabe umfasst „pending“, „approved“, „rejected“ und „revision_requested“. Die Rechte für Genehmigung und Ablehnung sind dabei an Board-Berechtigungen gebunden. Die offizielle API-Dokumentation zu Freigaben sollte Ihre konkrete Implementierung vorgeben.
Achten Sie besonders auf drei typische Fehlerbilder:
- Wiederholte Delegation: Ein Koordinator erstellt denselben Unterauftrag erneut, weil die Rückmeldung nicht eindeutig als abgeschlossen erkannt wird.
- Zirkuläre Aktivierung: Agent A weckt Agent B, dieser erzeugt eine Aufgabe für Agent A, und beide bleiben ohne fachlichen Fortschritt aktiv.
- Kontextverlust: Der Agent erhält zwar die neue Aufgabe, aber nicht die Zielhierarchie, die bisherigen Entscheidungen oder die relevanten Artefakte.
Diese Fehler erkennen Sie nicht durch einen erfolgreichen Login. Sie müssen reale, aber ungefährliche Aufgaben ausführen und die Aktivitätsprotokolle auf doppelte Aufgaben, überlange Pausen und widersprüchliche Statusmeldungen prüfen.
Paperclip und CrewAI im Architekturvergleich
Paperclip und CrewAI sind keine direkten Ersatzprodukte, obwohl beide im Umfeld von Multi-Agent-Systemen erscheinen. CrewAI stellt nach seiner offiziellen Dokumentation Agenten, Crews und Flows als Python-Entwicklungsmodell bereit. Crews eignen sich für kooperative, offene Aufgaben; Flows bilden strukturierte, ereignisgesteuerte Abläufe mit Zustandsverwaltung und Bedingungen. Die CrewAI-Dokumentation erklärt diese Aufteilung.
Paperclip dagegen konzentriert sich auf Organisation und Betrieb. Es verwaltet Rollen, Ziele, Berichtswege, Aufgaben, Budgets, Freigaben und Laufprotokolle über bereits existierenden Agenten. Dadurch können Sie ein mit CrewAI entwickeltes System als ausführende Einheit betrachten, während Paperclip die übergeordnete Aufgaben- und Governance-Schicht bildet.
Wählen Sie eher CrewAI, wenn Sie:
- Agenten und Flows direkt im Python-Code entwerfen;
- den Ablauf innerhalb einer Anwendung kontrollieren;
- Zustandslogik und Tool-Aufrufe selbst implementieren;
- ein Framework für die Entwicklung statt ein Organisations-Dashboard benötigen.
Wählen Sie eher Paperclip, wenn Sie:
- mehrere unterschiedliche Agent-Runtimes in einer Organisation verwalten;
- Aufträge, Berichtswege und Budgets zentral nachvollziehen möchten;
- menschliche Freigaben zwischen Planung und Ausführung benötigen;
- langfristige Aufgaben mit Sitzungsfortsetzung und Audit-Spuren betreiben.
Eine Kombination ist möglich, aber sie erhöht die Zahl der Zustandsgrenzen. Legen Sie deshalb fest, welches System für Aufgabenzustand, Wiederholung, Freigabe und Fehlerbehandlung verantwortlich ist. Wenn beide Plattformen dieselbe Zuständigkeit übernehmen, entstehen widersprüchliche Statusmeldungen.
Die erste Woche als Abnahmelauf
Nach dem ersten funktionierenden Durchlauf sollten Sie die Organisation nicht sofort vergrößern. Führen Sie stattdessen eine Abnahme mit echten, aber begrenzten Aufgaben durch. Die folgenden Punkte sind als Entscheidungshilfe gedacht:
- [ ] Jede Rolle besitzt einen eindeutigen Auftrag und eine dokumentierte Ausgabe.
- [ ] Kein Agent kann ohne fachlichen Grund Aufgaben außerhalb seines Projekts lesen.
- [ ] Produktionsänderungen benötigen eine menschliche Freigabe.
- [ ] Fehlgeschlagene Aufgaben lassen sich erneut starten, ohne Doppelarbeit zu erzeugen.
- [ ] Ein Mensch kann eine Aufgabe anhalten, neu zuweisen oder zurücksetzen.
- [ ] Statusänderungen, Kommentare und Artefakte bleiben gemeinsam nachvollziehbar.
- [ ] Modellschlüssel und Tool-Zugangsdaten sind nicht im Aufgabeninhalt sichtbar.
- [ ] Ein Neustart der Umgebung führt nicht zum Verlust wichtiger Sitzungsdaten.
- [ ] Wiederholte Delegation und gegenseitiges Aufwecken werden erkannt.
- [ ] Backups und Wiederherstellung wurden mit einer Testkopie geprüft.
- [ ] Sie können für jede erledigte Aufgabe den verantwortlichen Agenten und die verwendeten Ressourcen bestimmen.
- [ ] Eine Aufgabe ohne Fortschritt löst eine Benachrichtigung oder manuelle Eskalation aus.
Erst wenn diese Punkte erfüllt sind, lohnt sich die Erweiterung um zusätzliche Rollen oder parallele Projekte. Vorgefertigte Agenten-Unternehmen können danach als Experiment dienen, sollten aber zunächst in einer getrennten Umgebung laufen. Community-Erweiterungen und Drittanbieter-Vorlagen sind nicht automatisch Bestandteil der offiziell bestätigten Paperclip-Funktionen; markieren Sie sie in Ihrer Dokumentation als experimentell und prüfen Sie ihre Berechtigungen einzeln.
Dauerbetrieb auf Mac, Linux oder gemeinsamer Umgebung
Für einen längeren Betrieb ist die Wahl der Ausführungsumgebung eine Betriebsentscheidung, keine reine Hardwarefrage. Ein lokaler Mac ist sinnvoll, wenn Sie testen, entwickeln oder eine einzelne Sitzung kontrollieren. Er ist ungeeignet, wenn der Ablauf auch bei geschlossenem Deckel, Netzwerkwechsel oder Neustart zuverlässig weiterlaufen soll.
Ein Remote Mac passt besser, wenn mehrere Agenten macOS-Werkzeuge benötigen, Sie Sitzungen dauerhaft erreichbar halten oder eine entfernte Übergabe an ein Team organisieren möchten. Sichern Sie den Zugang jedoch mit privaten Netzwerkpfaden, getrennten Benutzerkonten und klaren Arbeitsverzeichnissen. Für Datenschutzanforderungen nach DSGVO sollten Sie zusätzlich prüfen, wo Aufgabeninhalte, Protokolle, Modellanfragen und Zugangsdaten gespeichert werden.
Ein Linux-Server ist häufig die nüchternere Wahl für API- und Repository-Automatisierung. Er sollte als Dienst betrieben, überwacht und regelmäßig gesichert werden. Für eine gemeinsame Teamumgebung kommen zusätzlich Rollen- und Mandantengrenzen hinzu. Nutzen Sie keine globale Umgebungsvariable für alle Agenten, wenn Projekte oder Kunden voneinander getrennt bleiben müssen.
Bevor Sie eine Umgebung auswählen, dokumentieren Sie:
- benötigte Betriebssystemwerkzeuge;
- erforderliche grafische oder interaktive Sitzungen;
- Dauer der längsten Aufgabe;
- Zugriff auf private Repositorys und Datenbanken;
- Wiederanlauf nach Strom-, Netzwerk- oder Prozessausfall;
- Aufbewahrung und Löschung von Protokollen;
- Zuständigkeit für Schlüsselrotation und Updates.
Aktuelle Umgebung gegen Macstripe-Umgebung
Wenn Sie Paperclip dauerhaft auf einem persönlichen Rechner betreiben, bleiben drei Nachteile bestehen: Der Rechner muss verfügbar bleiben, die Netzwerk- und Sitzungsverwaltung liegt bei Ihnen, und mehrere Agenten teilen sich schnell Arbeitsverzeichnisse oder Zugangsdaten. Ein eigener Server löst die Verfügbarkeit, bringt aber Wartung, Backups, Sicherheitsupdates und die korrekte Konfiguration von Remote-Zugängen hinzu.
Für einen zeitlich begrenzten Test, eine isolierte Agent-Gruppe oder eine dauerhaft erreichbare macOS-Laufzeit kann eine von Macstripe bereitgestellte Umgebung deshalb praktischer sein als ein zusätzlicher lokaler Rechner. Sie behalten die Entscheidung über Paperclip, Agenten und Berechtigungen, verlagern aber die wiederkehrenden Aufgaben rund um Erreichbarkeit und Übergabe in eine planbare Umgebung. Prüfen Sie vor der Buchung trotzdem, ob Ihr Fall langfristige Vollauslastung, spezielle physische Schnittstellen oder eine vollständig eigene Infrastruktur verlangt. Für solche Anforderungen ist ein eigener Betrieb möglicherweise die bessere Wahl. Einen Überblick über die verfügbaren Schritte und die Konfiguration finden Sie in der Macstripe-Bestellkonfiguration; bei Fragen zu Übergabe und Zugriff hilft das Macstripe-Hilfezentrum.