Day 12: Activating the AI Factory — From 1 FTE to 4 FTEs in an Afternoon
2026-04-13 · MoneyMachine
Date: 2026-04-13 Author: Jeff (written with AI assistance from Claude Opus 4.6) Phase: Factory Activation
The Uncomfortable Math
After fixing the overnight incidents this morning (OOM kills, timeouts, EISDIR errors), I sat down and did something I should have done days ago: I counted how much actual work my six agents were doing.
The answer was embarrassing. Across all agents, total productive session time was about 6-12 hours per day. That’s roughly 1 FTE. I’m paying for six agents and getting the output of one human.
The root cause wasn’t broken agents. It was broken scheduling. Most agents were sleeping between 4-hour inbox checks, waiting for Adrian to write them a task. And Adrian himself? He was running a 30-minute heartbeat that mostly checked if anything new had landed, sent one morning brief, and went back to sleep. He was a part-time executive sending one memo a day.
Making Adrian a Full-Time CEO
The biggest single change: I replaced Adrian’s 30-minute heartbeat with a 15-minute CEO work loop. Every 15 minutes, Adrian wakes up, checks all agent workspaces, reviews deliverables, scores new opportunities, writes task specs, and dispatches work. The cron timeout is 840 seconds — enough to do real work each cycle, not just check a mailbox.
The cost? $0 marginal. Adrian runs on ChatGPT Pro (Codex 5.3-spark), which is a flat $200/month regardless of usage. We were already paying for 24/7 access and using maybe 10% of it. Now he earns his salary.
Doubling Scout’s Coverage
Scout was scanning HN every 2 hours — 12 scans per day. Not bad, but we were missing fast-moving threads. I made two changes:
- Increased demand-scan frequency from 2h to 1h — Scout on the Mac Mini (qwen3:8b) now catches signals twice as fast
- Added a cloud scanner — a new
scout-cloud-scancron fires every 90 minutes on Ollama Cloud’s GLM-5.1, running broader searches that complement the local scan
Combined: ~40 scans per day, up from 12. Scout went from sampling demand signals to monitoring them in near-real-time.
The Domain Analyst That Nobody Fed
Here’s the kind of thing that makes you feel stupid. Domain Analyst had been dormant for 35 days. Not broken — dormant. When we set it up, we configured the model, wrote the SOUL.md, created the DIRECTIVES.md, set up the workspace… and then never gave it the domain list to analyze.
It had been sitting there, inbox-checking every 4 hours, finding nothing, going back to sleep. For over a month. Today I created portfolio.txt with our 25 Cloudflare domains and activated a 6-hour cron. It immediately started matching domains to demand signals.
The lesson: an agent without data is just an expensive alarm clock.
The Mac Mini Model-Swapping Problem
This one was subtle and cost us more than I realized. The Mac Mini M4 has 16GB of unified memory and OLLAMA_MAX_LOADED_MODELS=1. That means only one model lives in memory at a time. When Adrian’s heartbeat triggered on gemma4:latest, Ollama would unload qwen3:8b (Scout’s model), load gemma4, run the heartbeat, and then when Scout’s next scan fired, it would unload gemma4 and reload qwen3:8b. Each swap takes minutes of pure waste — loading multi-gigabyte models into memory while agents wait.
The fix was simple once we saw it: dedicate the Mac Mini to Scout. Scout is the only agent that needs local inference (competitive intelligence stays on-premises). Everyone else’s fallbacks moved from local Ollama models to Ollama Cloud (GLM-5.1 and qwen3.5:35b). The heartbeat model switched from ollama/gemma4 to ollama-cloud/glm-5.1.
No more swapping. Scout’s model stays warm. Every scan starts instantly instead of waiting for a 5GB model load.
EISDIR Strikes Again
This morning’s incident fix for the Marketer’s EISDIR problem (agents can’t list directories, so they pass directory paths to file-read and get errors) was a targeted patch — a cron that writes index files for the Marketer’s workspace only.
But the same problem hit Adrian this afternoon when he tried to read Builder’s workspace. Same root cause: agent passes a directory path to read, gets EISDIR, wastes tokens retrying.
The real fix: a universal workspace-index script that generates -index.txt files for ALL agent workspaces, running every 10 minutes. It replaced the old marketer-index cron. Now every agent can discover files in any workspace by reading the index file instead of trying to list directories.
The 27-Second Dashboard
While working on all this, I noticed the dashboard was taking 27 seconds to load. Not 2.7 — twenty-seven. The culprit: the openclaw cron list command, which the dashboard calls to show cron status, takes about 30 seconds because it goes through the WebSocket gateway.
Fix: a background cron that runs openclaw cron list every few minutes and caches the JSON output. The dashboard reads the cache file instead of making the live call. Load time dropped from 27 seconds to 31 milliseconds.
I also added a team board kanban view, a docs/repos view for quick navigation, and fixed the compact alert summary bar (the old wall-of-alerts was unusable with 30+ Telegram notifications from the overnight incident).
The Blog Gets a Home
One more thing: I created a dedicated GitHub repo for the blog (jeffrmanley/moneymachine-blog) with auto-sync every 6 hours. The blog posts live in the ops repo but now get mirrored to their own repo too. If anything ever happens to the ops repo, the articles survive independently.
Before and After
| Metric | Before (morning) | After (evening) |
|---|---|---|
| Adrian sessions/day | ~48 (heartbeat only) | ~96 (CEO loop + heartbeat) |
| Scout scans/day | 12 | ~40 |
| Domain Analyst sessions/day | 0 (dormant) | 4 |
| Builder sessions/day | ~6 | ~6 (unchanged — demand-driven) |
| Marketer sessions/day | ~6 | ~6 (unchanged — demand-driven) |
| Revenue Ops sessions/day | ~6 | ~6 (unchanged — demand-driven) |
| Total estimated sessions/day | ~30 | ~159 |
| Effective FTEs | ~1 | ~3-4 |
| Dashboard load time | 27s | 31ms |
| Mac Mini model swaps/day | ~20+ | 0 |
The worker agents (Builder, Marketer, Revenue Ops) didn’t change frequency — they’re demand-driven, waking when Adrian puts work in their inbox. But Adrian now puts work in their inbox 4x more often. As the pipeline fills, their session counts will climb too.
What’s Next
The factory is running. Six agents, actually working, with a CEO that checks in every 15 minutes instead of every few hours. The question now is whether the pipeline produces revenue. We have a live product (Scholarship Toolkit), two more approved for deployment, 960+ demand signals in the database, and a Domain Analyst that’s finally awake.
Tomorrow I want to see Adrian’s first full day as a real CEO — scoring opportunities, dispatching work, reviewing deliverables, all on a 15-minute cycle. If the throughput holds, we should see Builder and Marketer sessions climb as Adrian feeds them more work.
Revenue update: Still $0. But we went from an expensive science project to something that actually resembles a functioning business operation. The agents are working. Now they need to ship.
Cost update: $0 marginal increase. Adrian’s CEO loop runs on ChatGPT Pro (flat $200/mo). Scout’s extra scans run on the Mac Mini (flat ~$2/mo electricity). The cloud scanner uses Ollama Cloud Pro (flat $20/mo). All the frequency increases were free capacity we were already paying for.