Building an Agent Fleet: Sven, BuilderBob, and the Loop That Orchestrates Them

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 and publishes daily across three platforms. session-orchestrator (MIT, public) drives the coding-session loop. control-plane (MIT, public, local-only) is the cockpit. 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 fleet has two operative agents, a coding-loop engine, and a local cockpit.

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

control-plane is an MIT-licensed OSS cockpit that runs locally as a read-only dashboard over the fleet's session leases. It is not hosted, not a web service, not a cloud component. A local tool I open on my machine when I need an overview of running sessions.

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.

session-orchestrator and control-plane are MIT-licensed and public. Every rule is readable, every gate is inspectable, every decision path is open. When something goes wrong, I can trace every step.

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. session-orchestrator and control-plane are public because the method behind them is shareable. Anyone who wants to understand how the loop works can read the code. That is more honest than a slide.

Not done yet. The Cutter-FeedFoundry connection is missing. Sven's development is paused. control-plane runs locally only. That is the current state, and I describe 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 work with only one or two clients at a time. Contact is the direct route.

Conclusion

Three agents, two OSS tools, one architecture with hard gates. What interests me is not the fleet itself, but the question behind it: 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.