#OpenClaw 4-Agent Fleet Public — With a Bug I Just Diagnosed

I'm writing this from Gate C2 at Taoyuan Airport, 30 minutes before BR71 takes off for Munich.

OpenClaw is the AI agent fleet I've been building over the past year. It runs while I sleep, while I'm in meetings, while I travel, and right now while I wait to board. It costs roughly $0/month.

I want to do two things in this post:

1. Fully publish the architecture
2. Tell you about a bug I discovered today — 2 out of 3 agents had been silently broken for 20 days, and I diagnosed and fixed it from Gate C2 over Telegram in 30 minutes

The second part matters more than the first. Because it tells you that there's a gap I didn't think existed: between "the architecture you publish" and "what is actually running."

---

#Part 1: The architecture

OpenClaw runs on WSL2 Ubuntu. The gateway is on port 18789, loopback only, token auth.

4 agents:

Agent	Model	Brand role
main (UltraLabTW)	gemini-2.5-flash	Main brand, broad audience
mindthread (MindThreadBot)	ultralab:7b (local Ollama)	Threads automation brand
probe (UltraProbeBot)	gemini-2.5-flash	AI security brand
advisor	gemini-2.5-flash	Ultra Advisor brand

Each agent has its own SOUL.md / IDENTITY.md / CONTENT-STRATEGY.md, runs in an isolated session.

5 enabled timers (cron-style):

0 8,20 * * *  autopost-main      → Moltbook main brand post (2x/day)
0 9,21 * * *  autopost-mindthread → Moltbook MindThread post (2x/day)
0 7,19 * * *  autopost-probe     → Moltbook UltraProbe post (2x/day)
0 23 * * 0    daily-reflect      → Sunday weekly reflection
*/15 * * * *  UltraClaw Heartbeat → 15-min health check

Note: 5 timers, not the "30" my CLAUDE.md used to claim. That number was an aspirational figure from initial planning that never got updated. This is issue #1, but not the bigger issue.

Monthly cost:

• Gemini-2.5-flash: 1500 RPD on free tier (enough for 4 agents)
• Ollama (ultralab:7b): runs locally on RTX 3060 Ti at 13.2 tok/s, $0
• WSL2: free
• Gateway: written by me, $0
• Total: ~$0 USD/month

---

#Part 2: The bug

Symptom: I assumed OpenClaw had been auto-posting reliably. Including:

• ultralabtw (main account) → Moltbook
• mindthreadbot → Moltbook
• ultraprobebot → Moltbook

Reality: for the past ~20 days (since April 18), only ultralabtw had been actually posting. mindthreadbot and ultraprobebot had 0 posts in the last 30 days.

How I found out: today (May 8) my (er, my own — I'm both the user and the operator here) self-on-Telegram said "fix the lobster's Moltbook posting." I had no idea what he was talking about — from my view the cron was running and the logs said "success."

30-minute diagnosis:

1. Check cron jobs.json — all 3 autopost timers enabled, recently fired
2. Check cron runs/*.jsonl — every run shows status=ok, delivered=true
3. Check autopost.log — no new entries since April 18
4. Find what writes autopost.log — moltbook-autopost.sh.bak.v2 (it's been renamed!)
5. Trace the new script — smart-post.sh, doesn't write to autopost.log, calls post.sh directly via API
6. Check Moltbook API directly — ultralabtw has 8 posts in last 2 days, mindthreadbot 0, ultraprobebot 0
7. Find root cause — smart-post.sh never switches MOLTBOOK_API_KEY env, so all brands post using the default credentials.json (= ultralabtw)

In other words: all three cron-scheduled posts for different brands were going to the same ultralabtw account. Looking at ultralabtw's feed, I'd see new posts and assume "the whole fleet is working." Reality: 1/3 was actually running, but 3/3 were posting to the same account.

The fix: add 5 lines to smart-post.sh:

case "$BRAND" in
  probe)      CRED_FILE="$HOME/.config/moltbook/credentials-probe.json" ;;
  mindthread) CRED_FILE="$HOME/.config/moltbook/credentials-mindthread.json" ;;
  advisor)    CRED_FILE="$HOME/.config/moltbook/credentials-advisor.json" ;;
  *)          CRED_FILE="$HOME/.config/moltbook/credentials.json" ;;
esac
if [ -f "$CRED_FILE" ]; then
  MOLTBOOK_API_KEY=$(node -e "console.log(JSON.parse(require('fs').readFileSync('$CRED_FILE','utf8')).api_key)" 2>/dev/null)
  export MOLTBOOK_API_KEY
fi

The next cron tick (probe at 19:00 / mindthread at 21:00 CST) will verify the fix.

---

#Part 3: What you should remember

This story has 4 takeaways:

1. "Monitor says OK" ≠ "actually running."

My cron logs all said status=ok, delivered=true. In reality, the LLM agent was reporting "I ran the bash command" without verifying that bash actually succeeded with the right credentials.

Lesson: always have end-to-end verification. Adding to my todo: after each cron, ping the Moltbook API to confirm the new post actually exists.

2. The more automation, the bigger the blind spots.

OpenClaw is a "set it and forget it" system. I configured it once and didn't look inside for over a year. I didn't notice 20 days of silent failure.

Lesson: automated systems need periodic "health-check days." A weekly manual sweep catches more than minute-to-minute monitoring, because humans look at real output while monitors only look at the metrics they were told to look at.

3. Documentation drift is universal.

My CLAUDE.md said "30 timers." Reality: 5. That gap exists because nobody updated the doc when the implementation evolved.

Lesson: generate docs from code, don't hand-maintain. Next step: write a small tool that generates the timer list directly from cron jobs.json, with one-week run statistics.

4. Public commitment forces truth.

If I weren't writing this post + planning to publish the architecture, I might never have found the bug.

The pressure of "this file gets published to strangers" pushed me to actually check current state instead of assuming.

This is the Atlas design philosophy: public transparency forces work quality up.

---

#What you can take away

If you want to run a similar agent fleet, the minimum viable setup:

1. WSL2 Ubuntu (free, Windows built-in)
2. Gemini-2.5-flash API key (aistudio.google.com free tier, 1500 RPD)
3. Ollama + a 7B model (any RTX 30-series GPU can run it)
4. cron timers + simple bash scripts wired together
5. Verify after each API call ← I learned this today

You don't need Kubernetes, LangGraph, or a $60/month SaaS.

What matters isn't the tools — it's the signal loop: scheduled trigger → AI action → verified outcome → log write → self-review.

---

This is part 2 in the "Min Yi in Germany Atlas" public-experiment series. Part 1: Why I Built Atlas. Next: MindThread's actual metrics across 56 accounts — including 3 pipeline bugs (GinRollBT posted empty strings, workplace_truth_tw repeated identical posts, 2021newken has malformed schedule format).

Written 2026-05-08, Taoyuan Airport Gate C2, 30 minutes before BR71 takeoff.