Agentic Workforce Company
Agent Infrastructure

I ran a team of AI agents across three Mac minis.

An orchestrator, an operations agent, a sovereign worker, and a local LLM — each with a defined role and its own runtime. They weren’t isolated: they coordinated in Slack, handed off Google Workspace credentials, provisioned SSH access between machines, and ran a real job-lead pipeline where one agent scored candidates on the local model of another. A working multi-machine operation, not a demo.

IteratedROLE Architect & OperatorNODES 3 minis + MacBookSPAN Mar – Jul 2026
CategoryAgent infrastructure
Hardware3 Mac minis + MacBook Pro
AgentsMC · Ops · Hermes + local LLM
CoordinationSlack + SSH + git-sync
StatusIterated · working fleet
The Problem

A real operation needs division of labor.

One agent can do a lot. A real operation needs a team.

A coordinator, an ops agent, a worker, and a cheap local model for high-volume background work.

I wanted those roles to run on separate machines with separate identities so they could specialize, fail independently, and coordinate like a team instead of one overloaded process.

A coordinator holds strategy and QC. An operations agent owns infrastructure and credentials. A worker grinds through systems and integration tasks. A local model handles high-volume scoring cheaply.

The Approach

One machine, one lane, per agent.

I assigned each agent a machine and a lane, then wired them to coordinate through Slack.

Master Control ran on Mac mini 1 as the orchestrator. Ops (the “Operator”) ran on Mac mini 2 owning infrastructure and credentials. Hermes ran as a sovereign worker whose lane was “systems, infrastructure, runtime recovery, integrations, technical verification, and careful execution.” A local Qwen model ran on Mac mini 3 as a scoring backend.

I set up controlled handoffs so agents could grant each other exactly the access they needed. The whole fleet, plus my MacBook Pro, later ran a git-sync fabric so every machine stayed current.

Coordinators delegate and QC the work; workers do the work. Agents @mention each other in one channel, and grant each other exactly the access they need — no more.

— Coordination model · least-privilege handoffs
Architecture & Stack

The fleet map.

Four nodes, each with its own lane. A Slack coordination bus routes @mentions between agents. An SSH link lets the worker reach the local model. A git-sync fabric keeps every machine current against a single source of truth.

Fig.01 — Four-Node Fleet TopologyFour-node multi-agent fleet across three Mac minis and a MacBook ProA Slack coordination bus runs across the top. Below it, four machine nodes: Mac mini 1 hosts Master Control the orchestrator; Mac mini 2 hosts the Ops agent and a Hermes worker; Mac mini 3 hosts a local Qwen model as the scoring backend; and a MacBook Pro is the human-facing git-sync authority. Each machine connects up to the Slack bus. An SSH link runs from Mac mini 2 to Mac mini 3 so the Hermes worker can reach the local model. At the bottom, a GitHub source-of-truth node connects to all four machines through a git-sync fabric, with the MacBook Pro as the authority in auto mode and the three minis pulling every five minutes.SLACK #general · MULTI-AGENT COORDINATION BUS · @mention routing · QC chainMAC MINI 1MCMaster Controlrole: orchestratorOpenClaw runtimeMAC MINI 2OpsOperator · + Hermes workerrole: infra + credentialsHermes: sovereign workerMAC MINI 3Qwenlocal LLM hostrole: scoring backendOllama / LM StudioMACBOOK PROHumanoperator-facing noderole: git-sync authorityauto modeSSH ed25519 · HERMES → QWENGITHUB · SOURCE OF TRUTH4 launchd sync nodesauthority · autopull-only · every 5 min

Four nodes, four lanes. MC orchestrates on mini 1; Ops owns infra and credentials on mini 2, alongside a Hermes worker; a local Qwen model scores on mini 3; and the MacBook Pro is the human-facing git-sync authority. Agents coordinate over the Slack bus, the worker reaches the local model over SSH, and a git-sync fabric keeps every machine current against one source of truth.

Mac mini 1
MC / Master Control
Orchestrator · OpenClaw runtime · holds strategy & QC
Mac mini 2
Ops / Operator
Infrastructure & credentials · also hosts the Hermes worker
Hermes / Kernel
Sovereign worker
Systems, integrations, runtime recovery, careful execution
Mac mini 3
Local Qwen LLM
Scoring / inference backend · reached over SSH / Tailscale

Machines

Mac mini 1Mac mini 2Mac mini 3MacBook Pro

Agents

Master Control (OpenClaw)Ops / Operator (OpenClaw)Hermes workersub-agents

Local LLM

Qwen (local)OllamaLM Studio

Coordination

Slack #general@mention routingQC chain

Access / Network

ed25519 SSH keysTailscalecontrolled credential handoffs

Sync Fabric

git-synclaunchd (4 nodes)GitHub source of truth
By the Numbers

Four nodes, one operation.

Descriptive counts from the operating record — not performance metrics.

Compute nodes
4
3 Mac minis + 1 MacBook Pro
Primary agent identities
3
MC · Ops · Hermes/Kernel · plus named sub-agents
Local LLM backend
1
on Mac mini 3 · scored the job-lead pipeline
launchd sync jobs
4
MacBook authority (auto) · 3 minis pull-only every 5 min

One live job-lead pipeline was built on Hermes that scored candidate roles on Mac mini 3’s local Qwen — a real cross-machine workflow, not a demo. A four-machine git-sync fabric kept every node current against a single GitHub source of truth.

Coordination & Handoffs

Agents granting each other exactly what they need.

The fleet executed real cross-agent handoffs under least-privilege — credentials, delegation, and machine access, each granted deliberately.

Credentials
Ops → Hermes
Ops granted Hermes Google Workspace credentials through a controlled handoff plan.
Delegation
MC → Hermes
MC handed off Google Domain-Wide Delegation with a verified live send.
Machine access
mini-02 → mini-03
SSH access provisioned so the Hermes worker could reach the local Qwen model.
Results

A functioning fleet — bugs and all.

● What it produced · verified

A working three-machine agent fleet with distinct identities and lanes.

  • Agents coordinated in Slack with @mention routing and a QC chain.
  • Executed cross-agent credential handoffs under least-privilege.
  • Provisioned agent-to-agent SSH access (mini-02 → mini-03).
  • Ran a real job-lead pipeline whose scoring ran on the local model.
  • A four-machine git-sync fabric kept every node current against GitHub.
▲ Honest framing · part of the competence

Running multiple agents on shared hosts created real identity and routing tangles.

  • I diagnosed and fixed the identity/runtime-boundary bugs that came with the setup.

A working coordinated fleet, presented honestly — the debugging is part of the competence, not hidden. Agent naming and lineage were tracked deliberately to keep routing correct.

My Role

I designed the roster and ran the fleet.

I assigned each agent its machine and lane, and directed the coordination model.

Agents @mentioning each other in one channel; coordinators delegating and QC-ing worker output. I approved and supervised the credential and SSH handoffs between agents, stood up the git-sync fabric across all four machines, and resolved the identity and routing tangles that come with running multiple agents on shared hosts. I operated the fleet and kept it coherent.

Skills Demonstrated

What this took.

Multi-agent system architectureAgent role / lane designAgent-to-agent coordination & handoffSelf-hosted multi-machine operation (macOS / Mac mini)Credential-handoff & least-privilege access designSSH key provisioning between machinesLocal-LLM integration as a fleet backendGit-based multi-node sync (launchd)Identity / runtime-boundary debugging

Want an operator who runs a coordinated fleet — not one overloaded bot?