Eine Agenten-Flotte: Sven, BuilderBob und ihr Loop
Drei Agenten: Sven scoutet AI-Ideen, BuilderBob betreibt agenticbuilders.at mit 19 Cron-Jobs, session-orchestrator steuert den Coding-Loop mit harten Gates.
TL;DR
Auf meiner Infrastruktur laufen heute drei autonome Agenten: Sven scoutet täglich AI-Ideen in meinen Vault, BuilderBob betreibt agenticbuilders.at rund um die Uhr mit 19 Cron-Jobs auf einem dedizierten Hetzner-Host, veröffentlicht täglich auf X und Instagram und entwirft LinkedIn-Beiträge. Als Loop-Motor für Coding-Sessions läuft session-orchestrator (MIT, öffentlich). Zur ursprünglichen Architektur vom 2. Juli gehörte außerdem control-plane (MIT, öffentlich, nur lokal) als Cockpit; dieses Integrations-Experiment ist seit dem 11. Juli 2026 eingestellt. Für Content-Arbeit sind AgenticCutter und FeedFoundry im Einsatz. Dieser Artikel erklärt, wie die Teile zusammenhängen, wo harte Grenzen gesetzt sind und was noch fehlt.
Solo-Builder, echter Maßstab
Als Einzelperson betreibe ich heute mehrere Produkte, einen Blog, Social-Media-Präsenzen auf vier Plattformen, E-Mail-Triage, CI/CD und eine tägliche Coding-Praxis. Ohne Agenten liefe davon ein Bruchteil. Die Frage war nie "ob Agenten", sondern "wie man sie so aufbaut, dass sie verlässlich funktionieren und klare Grenzen haben".
Agentic Engineering ist für mich keine Kategorie auf einer Folie. Es ist die tägliche Praxis des Bauens, Betreibens und Verbesserns dieser Agenten. Das Reibungsprotokoll daraus ist das Material, aus dem Werkzeuge wie session-orchestrator entstehen.
Die Architektur: Sven, Vault, BuilderBob, Outputs
Die hier dokumentierte Architektur vom 2. Juli hatte zwei operative Agenten, einen Coding-Loop-Motor und mit control-plane ein lokales Cockpit. Seit dem 11. Juli 2026 ist das Cockpit-Experiment eingestellt.
Sven: persönlicher Content-Scout
Sven ist mein persönlicher Scout. Er läuft auf der OpenClaw-Runtime auf einem Hetzner-Host und ist über einen @Sven Discord-Bot erreichbar. Täglich und wöchentlich durchsucht er AI-relevante Quellen und schreibt interessante Ideen strukturiert in meinen Vault. Der Vault ist mein persönlicher Informations-SSOT, kein gemeinsam genutztes System.
Svens aktive Entwicklung ist derzeit pausiert. Er läuft, aber an der Runtime und den Fähigkeiten wird gerade wenig verändert.
BuilderBob: Plattform-Agent rund um die Uhr
BuilderBob ist der 24/7-Plattform-Agent für agenticbuilders.at. Er läuft auf der Hermes/Nous-Runtime auf einem dedizierten Hetzner-Host, mit 19 Cron-Jobs im Betrieb.
Was BuilderBob täglich macht:
- Moderiert einen Discord-Server
- Triagiert eingehende E-Mails nach einem festen Kategorien-Schema mit harten Eskalations-Gates
- Postet einmal täglich auf X
- Entwirft LinkedIn-Beiträge
- Komponiert und veröffentlicht Instagram-Posts für @gotzendorfer.at über die Meta Graph API
Für die Instagram-Bilder ruft BuilderBob FeedFoundrys Render-API auf. Die Bilder entstehen template-basiert, kein freier Text. Den Inhalt bestimmt eine SOUL.md-Persona mit Brand-Voice-Gates: BuilderBob entscheidet und veröffentlicht autonom, aber innerhalb dieser Grenzen.
BuilderBob commitet auch unter seiner eigenen Git-Identität, nicht meiner.
Sven schreibt in den Vault, BuilderBob liest daraus
Sven und BuilderBob sind nicht direkt verbunden. Die Verbindung läuft über den Vault: Sven trägt Ideen ein, BuilderBob liest daraus für seine Content-Planung. Eine asynchrone Schnittstelle über einen gemeinsamen Informationsstand, keine Echtzeit-Pipe.
session-orchestrator: OSS-Loop-Motor
session-orchestrator ist der MIT-lizenzierte Loop-Motor für Coding-Sessions. Er zerlegt jede Session in fünf typisierte Wellen mit Verifikations-Gates: Discovery, Implementierungs-Core, Implementierungs-Polish, Quality, Finalize. Mehr zur Mechanik dahinter in Wie ein OSS-Tool in 9 Tagen reift.
control-plane: lokales OSS-Cockpit
Am 2. Juli 2026 war die frühe öffentliche Version von control-plane ein MIT-lizenziertes, lokales Read-only-Dashboard über die Session-Leases der Flotte. Sie war nicht gehostet, kein Web-Dienst und keine Cloud-Komponente. Die spätere private Umsetzung ging mit Adapter, Panels, Remote-Ingest und Deployment über diesen lokalen Stand hinaus; der folgende Hinweis ordnet das Ende des gesamten Integrations-Experiments ein.
Update vom 11. Juli 2026: Nach praktischer Erprobung habe ich das Integrations-Experiment eingestellt. Die zusätzliche Company-Schicht aus Paperclip rechtfertigte ihre Komplexität in meinem lease-basierten Arbeitsablauf nicht. Paperclip selbst war nicht das Problem; gescheitert ist die Passung dieses Integrationsansatzes. Eine ausführliche Aufarbeitung folgt.
OSS-Fundament und harte Gates
Das wichtigste Gestaltungsprinzip bei autonomen Agenten ist nicht Autonomie, sondern Kontrollierbarkeit. Autonomie ist das Ziel, Kontrollierbarkeit ist die Voraussetzung.
Am 2. Juli 2026 waren session-orchestrator und die frühe öffentliche control-plane-Version MIT-lizenziert und öffentlich. Für diese öffentlichen Teile waren Regeln, Gates und Entscheidungslogik im Code prüfbar. Die spätere private Weiterentwicklung von control-plane war nicht vollständig öffentlich einsehbar.
Die harten Eskalations-Gates bei BuilderBob folgen demselben Prinzip. BuilderBob entscheidet und veröffentlicht beim alltäglichen Content autonom. Bei drei Kategorien stoppt er und eskaliert immer zu mir: Geld, Rechtsfragen, Beschwerden. Das ist keine technische Einschränkung, sondern eine bewusste Architektur-Entscheidung. Vertrauen in den Agenten und feste Grenzen für bestimmte Entscheidungsklassen schließen sich nicht aus.
Die zweistufige Content-Engine: Cutter und FeedFoundry
Neben den operativen Agenten gibt es zwei Content-Werkzeuge.
AgenticCutter schneidet Langform-Video für YouTube. Der Agent schlägt Schnitte vor, ich genehmige, die Verarbeitung läuft lokal auf meiner Maschine. Kein Cloud-Upload für die Verarbeitung, kein externer Dienst.
FeedFoundry rendert Kurzform-Content für Instagram. Bilder entstehen template-basiert, Text aus vorgegebenen Strukturen, kein freies Generieren. FeedFoundry hat eine Feedback-Schleife, die aus echtem Engagement-Signal lernt.
Cutter und FeedFoundry sind heute nicht miteinander verbunden. Das ist kein Versehen. Die Integration ist auf der Roadmap, aber ich baue sie erst, wenn ich den konkreten Mehrwert an echten Nutzungsdaten messen kann. BuilderBob ruft FeedFoundrys Render-API für Instagram auf, aber die inhaltliche Planung kommt aus dem Vault-Workflow, nicht aus Cutter-Outputs.
Was das über Agentic Engineering sagt
Einige Dinge, die ich in der täglichen Arbeit mit dieser Flotte gelernt habe:
Namen und Rollen trennen. Sven und BuilderBob haben unterschiedliche Persönlichkeiten, Runtimes und Zuständigkeiten. Denselben generischen Agenten zweimal zu deployen funktioniert nicht. Die Differenzierung beginnt bei der SOUL.md und endet bei der Wahl der Runtime.
Gates sind kein Zeichen von Misstrauen. Ich vertraue BuilderBob beim täglichen Content. Das ändert nichts daran, dass Eskalations-Gates für bestimmte Entscheidungsklassen sinnvoll und notwendig sind.
OSS ist kein Selbstzweck (Stand 2. Juli 2026). session-orchestrator und die frühe control-plane-Version waren öffentlich, weil die Methode dahinter teilbar sein sollte. Wer den damaligen Loop verstehen wollte, konnte den öffentlichen Code lesen. Das war ehrlicher als eine Folie, bildete die spätere private Weiterentwicklung aber nicht vollständig ab.
Noch nicht fertig (Stand der ursprünglichen Veröffentlichung am 2. Juli 2026). Die Cutter-FeedFoundry-Verbindung fehlte. Svens Entwicklung war pausiert. control-plane lief nur lokal. Das war der damalige Stand, und ich beschrieb ihn so.
Wer die Methode hinter dem 5-Wellen-Loop tiefer verstehen möchte: Ich lehre sie im Kurs Multi-Agent-Orchestrierung in der Praxis auf agenticbuilders.at. Und wer das direkt auf ein konkretes Vorhaben anwenden lassen möchte: Ich arbeite bewusst nur mit ein bis zwei Kunden gleichzeitig. Kontakt ist der direkte Weg.
Fazit
Am 2. Juli 2026 dokumentierte dieser Artikel drei Agenten, zwei OSS-Werkzeuge und eine Architektur mit harten Gates. control-plane gehört seit dem 11. Juli nicht mehr zur aktuellen Flotte. Die Frage dahinter bleibt: Wie baut man Agenten so, dass man ihnen tatsächlich vertrauen kann?
Die Antwort ist nicht mehr Autonomie, sondern bessere Grenzen. Klare Verantwortlichkeiten, Eskalations-Gates die greifen, und OSS-Code den man lesen kann, wenn etwas schiefläuft.
Das ist Agentic Engineering in der Praxis.