Agentic Workforce Company
Agent Infrastructure

I built an always-on AI orchestrator that ran a fleet of agents.

“Master Control” wasn’t a chatbot. It ran on a Mac mini as the CEO/architect of my agent operation — owning a cron fleet, delegating and quality-checking manager-level worker agents, keeping a layered memory system across restarts, reporting to me on a schedule, and blocking on human approval for anything destructive or client-facing. When cost forced a model migration, I moved its entire brain twice — without losing the operation.

IteratedROLE Designer & OperatorRUNTIME OpenClaw · Mac miniSPAN Mar – Jul 2026
CategoryAgent infrastructure
RuntimeOpenClaw · Mac mini 1
RoleOrchestrator / CTO of the fleet
SpanMar – Jul 2026
StatusIterated · controlled handoff
The Problem

I wanted an agent that owns execution.

Not one that just answers questions.

Running SEO and business operations across multiple clients and my own ventures needs leverage, not a chat window.

That meant one always-on coordinator that could hold the whole operation in memory, run recurring jobs unattended, hand work to other agents and check it, and stay safe enough to touch production systems.

A single persistent orchestrator with real guardrails was the way to get leverage without babysitting every task.

The Approach

A CTO/COO operating model with a human gate.

MC ran as an OpenClaw agent on a dedicated Mac mini, connected to Slack and Telegram through a gateway process.

MC and a peer Operator agent worked like a CTO and COO; manager-level worker agents “do the work” while the coordinators “delegate and QC the work.” MC owned a cron fleet and maintained a multi-layer memory system so it survived restarts with context intact.

It ran under an approval model: destructive operations and external sends require my confirmation. When Anthropic’s billing changed and API rates became unaffordable, I re-homed MC’s model twice — keeping the operation running.

Destructive operations require human approval; external sends require confirmation. And nothing gets delivered until we both sign off.

— MC's own guardrails · the QC chain
Architecture & Stack

Orchestrator topology.

A cron fleet and a layered memory system feed MC. MC coordinates a peer Operator, Hermes workers, and named sub-agents, and reaches me through a gateway into Slack and Telegram. Destructive and client-facing work escalates to a human-approval gate and loops back.

Fig.01 — Master Control TopologyMaster Control orchestrator topology with fleet coordination and a human-approval gateOn the left, a cron fleet and a layered memory store feed the Master Control agent in the center. MC connects through a gateway to Slack and Telegram at the top right. MC coordinates a peer Operator agent, Hermes worker agents, and a cluster of named sub-agents on the right. At the bottom, a human-approval gate shown in amber receives escalated destructive and client-facing work and loops the approval back to MC.Cron fleet12 defs · 8 enabledMEMORY SYSTEMMEMORY.mdLEARNINGS.mdHEARTBEAT.mdERRORS.md · skillsHindsight · GBrainAGENT · OPENCLAWMASTER CONTROLrole: orchestrator / CTOowns: cron fleet + QC chainmemory: persistent across restartsMac mini 1 · pm2 · Tailscale meshGatewayOpenClaw processSlackTelegramCOORDINATED FLEETOps / Operatorpeer · COOHermes workersexecution layerSUB-AGENTSsentinelprismseo-analystkeystoneHUMAN GATEMike approvesESCALATE · DESTRUCTIVE / EXTERNAL

A cron fleet and a layered memory system feed Master Control. MC coordinates a peer Operator, Hermes workers, and named sub-agents, and reaches me through a gateway into Slack and Telegram. Destructive and client-facing work escalates to the human-approval gate and loops back — nothing risky ships without my sign-off.

Agent Runtime

OpenClawMac mini 1Slack + Telegram gatewaypm2 services

Memory System

episodic daily logsMEMORY.mdLEARNINGS.md + skillsHEARTBEAT.mdHindsight (semantic recall)GBrain (Postgres)

Model Routing

Claude Opus 4.6OpenAI GPT-5.4GPT-5.5 / CodexOpus 4.8 fallback

Coordinated Fleet

Ops / Operator (peer)Hermes workerssentinelprismseo-analystkeystone

Ops

scheduled cronsgit-syncweekly planningworkspace-structure sync

Network / Security

Tailscale / WireGuard meshchmod 600 secretshuman-approval gate
By the Numbers

One coordinator, a whole operation.

Descriptive counts from the operating record — not performance metrics.

Cron definitions
12
under MC's ownership at one audit · 8 enabled
pm2 services
4
reported online during a routine health check
Memory / protocol files
8+
forming the persistent memory system, plus dated daily logs
Model homes migrated
3
Opus 4.6 → GPT-5.4 → GPT-5.5/Codex · operation stayed live

MC ran under one identity that spanned three aliases across its lifetime (Master Control / MC / Keystone). Failed cron jobs were diagnosed individually by name, not blanket-restarted — the discipline of an operator, not an autopilot.

Model Migration

Three model homes, one live operation.

When Anthropic’s billing changed and API rates became unaffordable, I re-homed MC’s model backend twice — without dropping the operation.

Spring · Origin
Claude Opus 4.6
MC's original brain on Anthropic.
April · Cutover
OpenAI GPT-5.4
Cost-driven migration; operation stayed live.
June · Re-home
GPT-5.5 / Codex
Moved to the OpenAI Codex runtime.
Standby · Fallback
Opus 4.8
Wired as fallback for resilience.
Results

What it produced — and how it ended.

● What it produced · verified from the record

A working always-on orchestrator, retired on purpose — nothing orphaned.

  • Ran a cron fleet and coordinated peer and worker agents through a defined QC chain.
  • Maintained persistent memory across restarts and reported to me on a schedule.
  • Operated under a human-approval gate for destructive and client-facing actions.
  • Survived two cost-driven model migrations without dropping the operation.
  • When the primary MC role was retired in early May, I performed a controlled handoff of its control paths to the Ops agent — machine kept intact.
▲ Context · not an MC metric

MC’s earliest identity was “Keystone.”

  • Keystone is the same agent that ran the Dr. Berg technical-SEO automation, documented separately.

That client-outcome work is covered in its own brief and is not restated here as an MC result.

Lifecycle

Origin to controlled decommission.

March 2026 · Origin
MC / Keystone comes online

The orchestrator stands up on Mac mini 1 as an OpenClaw agent, wired into Slack and Telegram through a gateway.

April 2026 · Cutover
First model migration

Cost forces a move from Claude Opus 4.6 to OpenAI GPT-5.4 — the operation stays live through the swap.

~May 6, 2026 · Handoff
Primary MC role decommissioned

The primary MC role is retired. I hand its control paths to the Ops agent in a controlled decommission — the machine stays intact, nothing orphaned.

June 2026 · Re-home
Second model migration

The backend moves again to GPT-5.5 via the OpenAI Codex runtime, with Opus 4.8 wired as fallback.

My Role

I designed the brain and ran it.

I named MC, defined its role as the coordinating brain of the fleet, and set the CTO/COO operating model.

I wrote the guardrails — human approval on destructive and external actions, a human gate before anything touches production — architected the multi-layer memory system, wired it into Slack and Telegram, and personally directed the two cost-driven model migrations and the eventual controlled decommission. I was the operator and architect; MC was the execution layer I built and ran.

Skills Demonstrated

What this took.

AI agent design & operationAgentic orchestration / delegationAlways-on autonomous runtime on self-hosted hardwareCron / scheduled-automation ownershipHuman-in-the-loop approval gatingAgent-memory engineering (episodic / long-term / procedural)Semantic recall integrationMulti-model routing & cost-driven LLM migrationControlled decommission / handoff without data lossOpenClaw runtime operation

Want an operator who runs the whole machine — safely?