Building an Agent Fleet: Sven, BuilderBob and the Loop
Three agents run around the clock: Sven scouts AI ideas, BuilderBob runs agenticbuilders.at with 19 cron jobs; session-orchestrator drives a gated coding loop.

TL;DR
Three autonomous agents run on my infrastructure around the clock: Sven scouts AI ideas daily into my Vault, BuilderBob runs agenticbuilders.at 24/7 with 19 cron jobs on a dedicated Hetzner host, publishes daily on X and Instagram and drafts LinkedIn content. session-orchestrator (MIT, public) drives the coding-session loop. The original architecture published on July 2 also included control-plane (MIT, public, local-only) as its cockpit; I stopped that integration experiment on July 11, 2026. AgenticCutter and FeedFoundry handle content work. This article explains how the pieces fit together, where the hard gates are, and what is still missing.
Solo Builder, Real Scale
As a solo builder I run multiple products, a blog, social-media presences on four platforms, email triage, CI/CD, and a daily coding practice. Without agents, a fraction of this would happen. The question was never whether to use agents, but how to build them so they work reliably and have clear boundaries.
Agentic engineering is not a category on a slide for me. It is the daily practice of building, running, and improving these agents. The friction log from that practice is the material that tools like session-orchestrator are made of.
The Architecture: Sven, Vault, BuilderBob, Outputs
The architecture documented here on July 2 had two operative agents, a coding-loop engine, and control-plane as its local cockpit. I stopped the cockpit experiment on July 11, 2026.
Sven: Personal Content Scout
Sven is my personal scout. He runs on the OpenClaw runtime on a Hetzner host and is reachable via a @Sven Discord bot. Daily and weekly he scans AI-relevant sources and writes interesting ideas in structured form into my Vault. The Vault is my personal information SSOT, not a shared system.
Sven's active development is currently paused. He runs, but not much is changing in the runtime or capabilities right now.
BuilderBob: Platform Agent Around the Clock
BuilderBob is the 24/7 platform agent for agenticbuilders.at. He runs on the Hermes/Nous runtime on a dedicated Hetzner host, with 19 cron jobs in operation.
What BuilderBob does daily:
- Moderates a Discord server
- Triages incoming email by a fixed category schema with hard escalation gates
- Posts once a day to X
- Drafts LinkedIn content
- Composes and publishes Instagram posts for @gotzendorfer.at via the Meta Graph API
For the Instagram images, BuilderBob calls FeedFoundry's render API. Images are produced from templates, no free-form text. Content follows a SOUL.md persona with brand-voice gates: BuilderBob decides and publishes autonomously, but within those bounds.
BuilderBob also commits under its own git identity, not mine.
Sven Writes Into the Vault, BuilderBob Reads From It
Sven and BuilderBob are not directly connected. The link runs through the Vault: Sven writes ideas in, BuilderBob reads them for content planning. An asynchronous interface via a shared information state, not a real-time pipe.
session-orchestrator: OSS Loop Engine
session-orchestrator is the MIT-licensed loop engine for coding sessions. It decomposes every session into five typed waves with verification gates: Discovery, Impl-Core, Impl-Polish, Quality, Finalize. More on the mechanics in How an OSS Tool Matures in 9 Days.
control-plane: Local OSS Cockpit
On July 2, 2026, the early public version of control-plane was an MIT-licensed local read-only dashboard over the fleet's session leases. It was not hosted, not a web service, and not a cloud component. The later private implementation went beyond that local state with an adapter, panels, remote ingest, and deployment; the following note records the end of the integration experiment as a whole.
Update, July 11, 2026: After testing it in practice, I stopped the integration experiment. The additional Paperclip company layer did not earn its complexity in my lease-based workflow. Paperclip itself was not the failure; the integration fit was. A detailed postmortem will follow.
OSS Foundation and Hard Gates
The most important design principle for autonomous agents is not autonomy but controllability. Autonomy is the goal; controllability is the precondition.
On July 2, 2026, session-orchestrator and the early public control-plane version were MIT-licensed and public. For those public parts, the rules, gates, and decision logic were inspectable in the code. The later private control-plane development was not fully public.
The hard escalation gates in BuilderBob follow the same principle. BuilderBob decides and publishes autonomously for everyday content. For three categories he stops and always escalates to me: money, legal questions, complaints. That is not a technical limitation; it is a deliberate architectural decision. Trusting the agent and having firm boundaries for certain decision classes are not opposites.
The Two-Stage Content Engine: Cutter and FeedFoundry
Alongside the operative agents, there are two content tools.
AgenticCutter cuts long-form video for YouTube. The agent proposes cuts, I approve, and the processing runs locally on my machine. No cloud upload for the processing, no external service.
FeedFoundry renders short-form content for Instagram. Images are produced from templates, text from fixed structures, no free generation. FeedFoundry has a feedback loop that learns from real engagement signal.
Cutter and FeedFoundry are not connected to each other today. That is not an oversight. The integration is on the roadmap, but I will build it once I can measure concrete value from real usage data. BuilderBob calls FeedFoundry's render API for Instagram images, but the content planning comes from the Vault workflow, not from Cutter outputs.
What This Says About Agentic Engineering
A few things the daily work with this fleet has made concrete for me:
Separate names from roles. Sven and BuilderBob have different personalities, runtimes, and responsibilities. Deploying the same generic agent twice does not work. The differentiation starts at the SOUL.md and ends at the choice of runtime.
Gates are not a sign of distrust. I trust BuilderBob with daily content. That does not change the fact that escalation gates for certain decision classes are both useful and necessary.
OSS is not self-serving (state on July 2, 2026). session-orchestrator and the early control-plane version were public because the method behind them was meant to be shareable. Anyone who wanted to understand the loop at that point could read the public code. That was more honest than a slide, but it did not fully represent the later private development.
Not done yet (state at the original publication on July 2, 2026). The Cutter-FeedFoundry connection was missing. Sven's development was paused. control-plane ran locally only. That was the state then, and I described it as such.
If you want to go deeper on the method behind the 5-wave loop: I teach it in the course Multi-Agent Orchestration in Practice on agenticbuilders.at. And if you would rather have it applied directly to a concrete project: I deliberately keep few projects running in parallel so the focus stays on building. Contact is the direct route.
Conclusion
On July 2, 2026, this article documented three agents, two OSS tools, and one architecture with hard gates. control-plane has not been part of the current fleet since July 11. The question behind it remains: how do you build agents you can actually trust?
The answer is not more autonomy but better boundaries. Clear responsibilities, escalation gates that hold, and OSS code you can read when something goes wrong.
That is agentic engineering in practice.