Engineering

The Final 20%: When the System Still Needs You

Every autonomous system has a hidden dependency: you. I spent eight months building Principal. The last five gaps are what made it actually autonomous.

March 23, 2026
7 min read
#autonomous-systems#agent-architecture#engineering-leadership
The Final 20%: When the System Still Needs You⊕ zoom
Share

Every autonomous system has a hidden dependency: you.

The system runs. The agents fire. The pipelines execute. But somewhere in the loop — a directive that needs to be manually routed, a cron that's been disabled for six months, an SSE stream that was stubbed out when everything else felt more urgent — you're still in the critical path. You're just not aware of it until you try to leave.

I spent eight months building Principal: an agent operating system for a one-person AI company. Broker infrastructure, agent routing, kill switch, behavioral health monitoring, OKR tracking. The architecture was sound. The code was passing CI. And I was still opening a terminal every day.

That's the gap the final 20% closes. Not features — the connective tissue that makes features irrelevant until it's complete.

The Audit Is the First Deliverable

Before writing a single line of code on Phase 10, I listed the exact blockers. Five gaps. Not vague problem areas — specific, nameable failures in the system's ability to operate without me.

The task dispatcher wasn't polling the broker for directives. The broker had no /observe/agents endpoint, so the behavioral health tab in Mission Control was showing mock data with a "LIVE DATA PENDING" banner that had been live for weeks. The War Room SSE stream hadn't been tested against a real incident. Eight cron jobs were disabled — some had never been re-enabled after infrastructure migrations. Jupiter, the trading execution layer, was emitting no events to the audit trail.

INSIGHT

The audit is the first deliverable. Not architecture diagrams, not implementation tickets — a numbered list of the exact mechanisms that require human presence. If you can't name them, you can't close them.

What's notable about that list: none of it was complex. These weren't algorithmic failures or deep architectural problems. They were plumbing between components — the integrations everyone agrees need to exist and no one prioritizes until the system can't run without you.

This is where most engineering projects live indefinitely. The features work. The integration points are stubs. The banner says "LIVE DATA PENDING." The operator keeps opening the terminal.

Five Gaps, Five Different Failure Classes

Each gap was different in kind, which is why they'd all survived this long.

Gap 1 — the task dispatcher — was a pure routing problem. The dispatch.py process existed and ran, but it wasn't polling GET /v1/directives?state=ISSUED from the broker. Agents could be assigned work that would sit in the queue forever. 661 lines later: it polls, routes by assignedTo field, and ACKs via PATCH /v1/directives/{id}/state. Every agent class has a route — openclaw, foresight, shiva, vp-trading, sentinel.

Gap 2 — the observe endpoint — was a visibility problem. The behavioral health view in Mission Control was architecturally correct. The frontend component existed. The API route existed. The broker just didn't have a /v1/observe/agents endpoint behind it, so the whole chain returned fabricated data. Adding it required aggregating per-agent summaries: drift_score, alignment_pct, session_count, last_session_ts, memory_committed, recent_decisions. Agents with no data return nulls — never 404.

Gap 3 — War Room SSE — was a trust problem. You can't know an event stream works until you push a real event through it. The SSE infrastructure existed in theory. It had never been tested against an actual Level 1 halt. Completing it required asyncio.Queue fan-out at the broker, broadcast_event() wired to the kill switch, and the full EventSource → WarRoomOverlay chain in Mission Control — coordinated changes across two repos.

Gap 4 — disabled crons — was an archaeology problem. The system had accumulated 13 disabled jobs over time. Some were obsolete (Command Station Tunnel Monitor, abandoned after an infrastructure pivot). Some were duplicates (InDecision Parallel Analysis, running against a deny-listed tool). Some were replaced by better mechanisms (Security Weekly Audit, superseded by the Security Council agent). I deleted 5, re-enabled 8.

Total Cron Jobs
42
42 enabled, 0 disabled

Gap 5 — Jupiter trade events — was the simplest. Jupiter already had a broker bridge with heartbeat support. It just wasn't emitting trade.evaluated and trade.completed events. Two event types added, flowing through NATS → broker audit log → Mission Control activity feed.

The 7-Day Gate

The delivery test for Phase 10 wasn't "did CI pass." It was a table.

Six rows. Six things I should be able to do from Mission Control without opening a terminal. Issue directives to five agents and get ACKs within five minutes. Dispatch a CEO 1:1 trading brief. See real behavioral health data. Trigger War Room on a Level 1 halt. Each row is a falsifiable claim about the system's operational independence.

SIGNAL

The 7-day gate isn't a QA checklist. It's a statement of what "done" means. Build the gate before the implementation. If you can't define the test, you haven't understood the requirement.

The answer at the end of Phase 10: conditional yes. All five gaps implemented. Four PRs needing CI green and merge. Conditional not because anything was broken — because the verification steps couldn't run until the code was deployed.

After merge: rebuild MC Docker containers, restart principal-broker launchd, verify SSE stream live from Cockpit, issue a test directive to three agents, run a War Room drill. Level 1 halt, confirm incident_activated fires, resume, confirm incident_resolved. If all five steps pass, Principal v1 is done. Not "feature complete" — operationally autonomous.

What Autonomy Actually Requires

The industry talks about autonomous AI agents as if autonomy is a model capability. It isn't. Autonomy is a systems property. It emerges from the connective tissue — the routing, the event streams, the observability layers, the cron hygiene — being complete enough that the operator can actually leave.

The precise definition of an autonomous system: it runs its next cycle without you making a decision. Not you checking on it. Not you re-enabling a cron. Not you manually routing a directive because the dispatcher wasn't polling. The next cycle runs.

Getting there required closing gaps that weren't in any sprint because they weren't features. They were the gaps between features — the plumbing that nobody scopes because it feels like it should already be there. You build the alarm system and forget to wire it to the siren.

Terminal velocity has a concrete meaning in this context: zero terminal sessions needed. Not fewer. Zero. That's the bar, and it took naming five specific mechanisms that violated it before the number could move.

The 37 repos still exist. The trading bots are still running. The content pipeline still produces videos. But now there's a cockpit that shows the state of all of it, routes directives to the right agent, streams real incident events, and surfaces behavioral health from a live endpoint. The activity feed has Jupiter trade events. The cron scheduler has 42 active jobs, all running.

The terminal is still there. I just don't need it anymore.

Go deeper in the AcademyOperator

The engineering patterns in this article are covered in the AI Infrastructure track — persistent platforms that run themselves. 11 lessons.

Start the AI Infrastructure track →

Explore the Invictus Labs Ecosystem

// Join the Network

Follow the Signal

If this was useful, follow along. Daily intelligence across AI, crypto, and strategy — before the mainstream catches on.

No spam. Unsubscribe anytime.

Share
// More SignalsAll Posts →