From Restartable Script to 24/7 Autonomous Engine
583 sessions, $5,008, 67 commits across four repositories in seven days. The scoring framework became infrastructure. The application engine crossed from restartable script to 24/7 autonomous pipeline. LinkedIn submission rate moved from 40% to 83% via seven measured runs with one fix per iteration.
From Restartable Script to 24/7 Autonomous Engine
The infinite run coordinator shipped Monday in two files: 503-line coordinator, 501-line channel run loop. Per-channel state machines for LinkedIn, Greenhouse, Lever, and Direct. Quiet hours, stagger delay, CAPTCHA auto-pause, exponential-backoff capped at 60 minutes, checkpoint tracking, and clean SIGTERM flush.
Before: manual restart on any failure. After: failures isolated to the channel that failed. Every later feature: multi-process isolation, tenant scoping, SaaS, desktop app: plugged into this coordinator rather than replacing it.
The boundary between “script” and “service” is failure handling. A script crashes and waits for a human. A service classifies the failure, decides on a response, and continues. The coordinator’s design decision was making failure modes first-class: CAPTCHA is a pause signal, not a crash; rate limits are backoff signals, not errors; quiet hours are scheduled gaps, not downtime.
Tuesday proved the core pipeline worked: Direct channel 98% (48/49), Greenhouse 100% (10/10), combined 69% (58/84). LinkedIn at 0% on 25 attempts was not a pipeline failure: the inventory was entirely stale. LinkedIn’s search index was lagged enough that every “Easy Apply” badge navigated to a closed job. That’s an input quality problem, not a pipeline bug. Treating those two failure modes as equivalent would route tuning effort to the wrong problem.
The LinkedIn ratchet ran from March 15 onward: 7 progressive runs, one fix per run, same evaluation criterion each time. Starting rate: 40%. Run 7 result: 83%. 26 discrete failure points fixed (F1-F39). The failure taxonomy split cleanly: modal detection timing, button identification, field selectors, and screening question patterns were controllable. Closed jobs (F14, F15, F18) were environmental and correctly fast-failed. External-apply redirects were architectural: 7 documented cases requiring a separate ATS hand-off module (F21), not further tuning of the existing flow.
A 92.3% rate on controllable, datable attempts is a different claim than a composite rate diluted by inherently uncontrollable failures. Denominator discipline is not optional.
Saturday hit the LinkedIn daily limit and pivoted immediately to Direct and Greenhouse orchestration. No downtime. Multi-channel is a resilience layer, not just a coverage strategy.
Transferable insight: The boundary between script and service is failure handling. When failure modes become first-class citizens: classified, responded to, not just caught: the script becomes infrastructure.
4 Agents, 4 Isolated Worktrees
Mixin: parallel AI development architecture
Four Opus sub-agents ran in isolated git worktrees across two days: Direct Discovery, Direct Application, LinkedIn Worker, Greenhouse Worker. Orchestrator held cross-cutting concerns. Sub-agents owned disjoint file domains.
679 total sessions (522 main + 157 worktree). Merged cleanly into baseline commit e4f43c5. The merge was clean because domains were assigned before work started, not negotiated after.
This experiment became the direct predecessor of Dakka’s four-role spawn architecture: Kommando (orchestrator), Mekboy (worker), Weirdboy (specialist), Painboy (observer). Fixed launch sequence eliminates initialization race conditions. WebSocket protocol carries control messages and binary terminal output. Each role gets a distinct CLAUDE.md directive. Three Mekboys assigned non-overlapping paths by Kommando merged without conflict.
The sweet spot for human-in-the-loop parallel work is three to four agents with a dedicated orchestrator. The isolation IS the collaboration strategy. Agents that can’t see each other’s files don’t need to negotiate merges.
Transferable insight: Parallel agent work is a domain assignment problem, not a coordination problem. Assign non-overlapping file domains before the agents start; the merge writes itself.
Three Perspectives, Zero Overlap
Mixin: multi-persona audit coverage
A 244-tool QuickBooks Online MCP server was audited independently by three personas: CPA, CFO, Data Engineer. Results in separate documents.
CPA found 5 critical control failures: audit trail immutability, missing approval workflows, no pre-submission validation, no idempotency, batch bypass. These are failures a technical reviewer would not name as critical: they require knowing what an auditor considers a control.
CFO found governance gaps. DE found pipeline and data lineage issues. Overlap across all three sets was minimal. That minimal overlap is the core result. If the personas were redundant, overlap would be high. Minimal overlap means each perspective is seeing genuinely different risk surfaces.
Coverage tripled relative to any single-perspective approach. The multi-persona-audit pattern generalizes: the number of perspectives isn’t about thoroughness, it’s about the non-overlapping risk surfaces that each professional lens makes visible.
280 automated code reviews the same week had not surfaced any of these. The external documentation session that preceded the multi-persona audit found design gaps that 280 automated reviews missed: a reader who does not share your context is a different failure detector.
Transferable insight: AI personas are not role-playing. Each professional lens surfaces a non-overlapping risk set. Multi-persona coverage is multiplicative, not additive.
Zeitgeist
By the Numbers
| Metric | Value |
|---|---|
| Sessions | 583 |
| Compute cost | $5,008 |
| Git commits | 67 |
| Deploys | 0 |
| MQI avg | 0.1284 |
| MQI delta | -0.0904 |
| Cache hit rate | 95.4% |
| Autohunt cost | $4,009 (151 sessions, $26.55/session) |
| Skl-audit cost | $842 (371 sessions, $2.27/session) |
| Saturday sessions | 390 (67% of week total) |