Eine Agenten-Flotte bauen: Sven, BuilderBob und der Loop, der sie orchestriert

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 und veröffentlicht täglich auf drei Plattformen. Als Loop-Motor für Coding-Sessions läuft session-orchestrator (MIT, öffentlich). Als lokales Cockpit gibt es control-plane (MIT, öffentlich, nur lokal). 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 Flotte hat zwei operative Agenten, einen Coding-Loop-Motor und ein lokales Cockpit.

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

control-plane ist ein MIT-lizenziertes OSS-Cockpit, das lokal als Read-only-Dashboard über die Session-Leases der Flotte läuft. Es ist nicht gehostet, kein Web-Dienst, keine Cloud-Komponente. Ein lokales Werkzeug, das ich auf meiner Maschine öffne, wenn ich den Überblick über laufende Sessions brauche.

OSS-Fundament und harte Gates

Das wichtigste Gestaltungsprinzip bei autonomen Agenten ist nicht Autonomie, sondern Kontrollierbarkeit. Autonomie ist das Ziel, Kontrollierbarkeit ist die Voraussetzung.

session-orchestrator und control-plane sind MIT-lizenziert und öffentlich. Jede Regel ist lesbar, jedes Gate ist prüfbar, jede Entscheidungslogik liegt offen. Wenn etwas schiefläuft, kann ich jeden Schritt nachvollziehen.

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. session-orchestrator und control-plane sind öffentlich, weil die Methode dahinter teilbar ist. Wer verstehen möchte, wie der Loop funktioniert, kann den Code lesen. Das ist ehrlicher als eine Folie.

Noch nicht fertig. Die Cutter-FeedFoundry-Verbindung fehlt. Svens Entwicklung ist pausiert. control-plane läuft nur lokal. Das ist der aktuelle Stand, und ich beschreibe 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

Drei Agenten, zwei OSS-Werkzeuge, eine Architektur mit harten Gates. Was mich dabei interessiert, ist nicht die Flotte an sich, sondern die Frage dahinter: 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.