Agentic Workforce Company
Agent Infrastructure · Control-Plane Operations

I ran my AI agents on a real control plane — not on vibes.

Every task routed by agent identity. Every “done” gated by QC. Every action written to an audit trail. Issue triage tracked as HOL-### tickets across a fleet of agents. When the plane broke — a P0 auth outage, a gateway regression that failed 658 runs in a day — I diagnosed it, directed the fix, and hardened it so it couldn’t happen the same way twice.

IteratedROLE Owner-operatorSCOPE Multi-agent fleetPERIOD Apr–May 2026
CategoryAgent infrastructure
SystemPaperclip issue / board control plane
FleetOpenClaw + Hermes agents
My relationshipOperated · integrated · governed
StatusIterated · not finished
The Problem

Chat is a terrible system of record for a workforce.

I didn’t run my agents on chat messages and hope.

A fleet of autonomous agents across three Mac minis needs ownership, status, and a way to tell “said” from “done” — none of which a chat log gives you.

Chat is fine for a conversation. It’s a terrible control surface for a workforce: no ownership, no status, no verification, no audit.

I needed a control plane where work was assigned, tracked, verified, and auditable — so agents couldn’t self-close tasks, stale docs couldn’t override live truth, and I could see exactly what each agent was responsible for at any moment.

The Approach

Slack coordinates. The control plane executes and owns.

One explicit operating model: Slack for decisions and coordination; the control plane for execution, ownership, status, verification, and audit trail.

Every unit of work became an HOL-### issue with an owner, a status, and a comment thread that served as the audit log. Agents polled their own queues by identity — a poll returned that agent’s tasks and nothing else — and the system was wired into the agent gateway so heartbeats and wake cycles flowed through it.

I drafted a company-wide governance model to enforce what makes a control plane trustworthy: verify-before-done, no self-close, a QC chain, blocked-status discipline, and live-truth-over-stale-docs. I supervised through the board — grouping work into projects, triaging blockers, and directing root-cause and remediation when the plane itself failed.

I operated, integrated, and governed this control plane. The agents executed the work; I was the operator and the accountable owner — that's the honest framing, not "I wrote the software."

— Attribution note · operated, not authored
Architecture & Stack

The control-plane topology.

Slack carries decisions. The control plane owns execution, status, QC, and the audit trail. It routes work to the agent fleet by identity through the gateway, and every action is written back as an issue comment. I supervise the board.

Fig.01 — Slack / Control-Plane Role SplitThe Paperclip control-plane topologySlack on the left carries decisions and coordination. The Paperclip control plane in the center owns ownership, status, the QC gate, and the audit trail, and holds work as HOL-### issues. It routes tasks by identity through the agent gateway on the right to a fleet of agents — orchestrator, ops, Hermes worker lanes, and Kernel — each with its own poll key. Agents write every action back to the control plane as an issue comment. A human operator supervises the board, shown in amber.COORDINATIONSlackdecisions onlyCONTROL PLANEPaperclipownershipstatus · todo/blocked/doneQC gate · verify-before-doneaudit trail · commentsHOL-### issuesper-agent poll keysinternal dashboard ·Cloudflare tunnel · auth-gatedAgent gatewayheartbeats · wake cyclesMC · OpsHermes lanesKernelAGENT FLEETHUMAN · ACCOUNTABLE OWNEROperator supervises the boarddecisionsROUTE BY IDENTITYAUDIT → ISSUE COMMENTS

Slack carries decisions; the Paperclip control plane owns execution, status, the QC gate, and the audit trail, holding work as HOL-### issues with per-agent poll keys. It routes tasks by identity through the gateway to the fleet, and every action is written back as an issue comment audit trail. The operator supervises the board as the accountable owner. Exposed through an internal, auth-gated dashboard behind a Cloudflare tunnel.

Control Plane

Paperclip issue / boardHOL-### issuesper-agent API keysidentity poll scripts

Agent Runtime

OpenClaw (MC, Ops)Hermes worker lanesKernel3× Mac mini

Integration

gateway adapterheartbeats / wakeCloudflare tunnelPM2 process mgmt

Coordination I/O

Slack (decisions)#paperclip-notifications

Governance

verify-before-doneno self-closeQC chainblocked disciplinelive-truth-over-stale-docs

Ops / RBAC

per-agent RBACAPI key managementauth-gated (403 → 200)identity hardening
Issue Lifecycle

How an HOL-### issue moves.

Every unit of work is an owned issue with a real status and a comment thread as its audit log. Completion is gated — an agent can’t mark its own work done.

◦ Todo
Assigned & owned
Created as HOL-###, given an owner (MC, Ops, Hermes-QA, Kernel), grouped into a project.
▲ Blocked
Discipline, not drift
Work that can't proceed is explicitly blocked — surfaced for triage, not silently stalled.
● QC
Done means verified
A QC chain checks the work. No self-close — an agent cannot verify its own completion.
✓ Done
Closed & auditable
Marked done only after verification; the comment thread stands as the durable audit trail.
By the Numbers

Routing proven; incidents run like an operator.

Verified from the internal record — counts, incident scope, and remediation. Operational facts, not performance benchmarks.

HOL-### issues
~18
control-plane work items located in the record
Identity routing
exit 2
a mismatched identity fails closed after the hardening fix
Gateway regression
658runs / 24h
157/157 MC + 501/501 Ops heartbeats failed
Duplicate cleanup
178issues
removed; open count fell ~207 → 29
P0 · May 2
Ops polling 401ing — root cause: the agent was marked terminated and its keys revoked; restored, re-keyed, verified, then hardened (commit c7c5cebf)
Apr 25
an invalid root-level field in the gateway payload failed every heartbeat for 24h; adapter patched, runtime pinned, duplicates cleaned
403 → 200
the dashboard fails closed to unauthenticated requests and serves only when authenticated
When It Broke

Two incidents, root-caused and hardened.

The value isn’t that it never broke — it’s how it was run when it did: root cause, committed fix, then hardening so the failure mode was closed, not just cleared.

Gateway heartbeats
Regression658runs failed / 24h
Fixed0healthy · runtime pinned
Open issue count
Bloated~207incl. 178 duplicates
Cleaned29duplicates removed
Ops authentication
P0 outage401keys revoked
Restored200re-keyed · hardened
▲ Read this honestly

Operated and governed — not authored. Iterated, not finished.

Paperclip is a real system I operated, integrated, and governed — the record shows configuration, RBAC, incident fixes, and process management, not that I wrote the tool from scratch. The QC chain was an enforced model, not a fully automated guarantee. The board accumulated blocked routine items and duplicates that needed periodic cleanup, so this was iterated, not “done.”

No cost tracking is claimed. There is no evidence Paperclip tracked spend, and this page makes no such claim — only what the record supports.

My Role

I owned the control plane.

I set the operating model, defined the governance rules, structured the work, controlled RBAC, and ran triage.

Slack coordinates; the control plane executes, owns, and audits. I defined verify-before-done, no self-close, the QC chain, the audit trail, and blocked discipline. I structured work into projects and HOL-### issues, controlled agent RBAC and assignments, and when the plane failed I directed the diagnosis and remediation and required the fixes be hardened and committed. The agents executed; I was the operator and the accountable owner.

Skills Demonstrated

What this took.

Agent orchestrationMulti-agent control-plane operationsTask routing by agent identityIssue triage & project management (HOL-###)QC / verification gatingAudit-trail designIncident response & root-cause analysisAPI auth / key management & identity hardeningCloudflare tunnel + PM2 opsGovernance model design for autonomous agentsHuman-in-the-loop supervision

Want an operator who runs agents on a control plane — not on hope?