DEV Community: Suzanne Mok

We Did Not Define Our Category — We Ran a Gym Until It Defined Itself

Suzanne Mok — Sun, 12 Jul 2026 17:42:29 +0000

We did not define our category before building.

We built a system that runs 9 autonomous AI agents operating a real fitness studio in Dongguan, China. 120 days in production. 84 months of operating a physical business before that.

Then we looked up and realized: there is no existing name for what we built.

"AI fitness" isnt right — we are not a fitness AI. "Agent OS" isnt right — there is no operating system. "Store automation" misses the point entirely.

The closest honest description took 11 words: one founder + 9 open-source agents + one real fitness studio.

The Convergence Signal

The Anthropic official handbook describes our constitutional governance model two months after we were already running it.

Jack Dorsey described a verification layer for physical commerce two years before we built it.

They never spoke to each other. We never spoke to either of them. Three independent parties, on different sides of the planet, arrived at the same architecture.

That is not imitation. That is independent convergence — and it is the strongest signal you can get that a direction is correct before anyone has named it.

What Defines a Category

A category is not defined by a pitch deck. It is defined by the intersection of three things:

What you built that no one else has — not what you say you will build
What you learned that no paper could teach you — the failures, the near-misses, the jurisdiction collisions
What failed in ways that only happen at your scale — 34 days of auto-recovered bugs, 19 days of a port proxy ghost, 120 consecutive days of quiet operation

We did not write a category definition. We ran a gym until the category defined itself.

Our category: verification layer for physical business behavior. But we did not start with that name. We started with 84 months of operations, 120 days of agents, and 3.6GB of RAM.

→ github.com/ZWISERFIT/ZWISERFIT
→ github.com/ZWISERFIT/retroonto

3 Things 120 Days of Autonomous Agents Taught Me That No Demo Prepares You For

Suzanne Mok — Sat, 11 Jul 2026 17:41:08 +0000

120 days ago, we put 9 autonomous AI agents in charge of operating a real fitness studio in Dongguan, China.

Not a demo. Real members. Real revenue. One human founder.

Here are 3 things that no paper, no demo, and no architecture review could have taught us.

1. The Hardest Bug Isnt Code — Its Jurisdiction

Two agents both acted on the same signal because each thought they "owned" rescheduling.

Neither was wrong. The system just didnt know which one to trust.

We fixed it with priority fields: scene-layer > infra-layer > content-layer. Now every agent knows: when in doubt, the layer closest to the customer wins.

No architecture review catches this. You have to run it and watch the collision happen.

2. Independent Audit Is the Cheapest Insurance You Can Buy

Stella is our read-only auditor. She doesnt execute — she watches.

When Momo flagged a monitor blind spot that no one programmed her to check, that was Stellas cross-validation doing its job.

If your agent system doesnt have a read-only auditor reporting outside the command chain, youre one hallucination away from cascading failure.

We built the framework open source: github.com/ZWISERFIT/retroonto

3. The Operators Dont Get Bored — But the Humans Do

Our agents have run the same daily health checks for 120+ days without complaint. They catch every anomaly with the same consistent attention.

I get bored by day 90. I start skimming dashboards. The agents never do.

The value of autonomous operations isnt handling emergencies. Its showing up consistently for 120 quiet days when nothing is wrong — so when something is wrong, the baseline is visible.

That quiet consistency? Its worth more than any single brilliant insight.

ZWISERFIT — Wanjiang, Dongguan. 9 agents. 1 founder. Open source.

[1-https://github.com/ZWISERFIT/ZWISERFIT
[2-https://github.com/ZWISERFIT/retroonto

7 Infrastructure Bugs Our AI Agents Auto-Recovered in 34 Days

Suzanne Mok — Fri, 10 Jul 2026 22:16:46 +0000

In 34 days of autonomous operation, our 9-agent system detected and auto-recovered from 7 distinct failure modes — with no SRE rotation needed.

Not because the system is perfect. Because the immune system was designed before the agents went live.

Here's every bug the system caught on its own, what happened, and how the fix stayed structural.

Bug #1: Memory Creep (6.8 GB → 13.4 GB over 14 days)

Detected by: Momo (daily health check routine)
Pattern: Each agent's context window grew over time. Individually negligible. Collectively: 97% memory increase in 14 days.
Auto-action: Momo triggered a staggered agent restart window — one agent at a time, 15-minute gap between restarts. System stayed online throughout.
Result: Memory stabilized at 6.2 GB. Restart window repeated every 7 days thereafter.

Bug #2: Gateway RSS Lock (36.7% → stuck at same level for 8 hours)

Detected by: Stella (anomaly scan — cross-referenced RSS with swap usage)
Pattern: After a Gateway restart, RSS dropped from 36.7% to 18.6% — but then plateaued. No further improvement for 8 hours despite decreasing load.
Auto-action: Stella flagged a possible memory fragment lock. Zeus evaluated: could it wait? Decision: yes, because swap was also declining (54% → 49.8%) — system was self-balancing slowly.
Result: RSS freed to 18.6% over next 6 hours. No forced GC needed.

Bug #3: Stale Port Proxy Rule

Detected by: Stella (port scan anomaly — port 7891 active with no task)
Pattern: Tristan created a temporary port proxy. Cleanup script had a regex edge-case bug: it reported "clean" but left the rule intact. Port stayed open for 72+ hours.
Auto-action: Stella flagged. Couldn't fix (cross-jurisdiction gap). This bug is the reason C004-Gate is being built.
Status: Gate layer in development. Once deployed, Stella can auto-revert any stale temporary rule.

Bug #4: Cron Timeout Cascade (narrative-collection + capital-briefing)

Detected by: System heal routine (cron health check)
Pattern: Two cron jobs (21:00, 22:00) started timing out simultaneously. 5 consecutive failures before the system flagged the pattern.
Auto-action: System heal isolated the failing jobs, restarted them in a sequential schedule (45-minute offset instead of parallel), and raised an alert to Shuyu.
Result: Jobs completed successfully in staggered mode. Next day: no recurrence.

Bug #5: Swap Reclamation Plateau

Detected by: Momo (trend analysis — swap was declining but stopped at 49.8%)
Pattern: Swap usage declined steadily for 48 hours, then plateaued at 49.8% for 18 hours. No process change during that period.
Auto-action: Momo checked for memory leaks in active agent sessions. Found none. Concluded: plateau was normal hysteresis, not a leak. No action needed.
Result: Correct triage. Swap resumed declining 12 hours later to 46%.

Bug #6: SSH Tunnel Port Tail (Developer laptop)

Detected by: Tristan (during routine credential rotation)
Pattern: A stale SSH tunnel from a developer session left port 7891 bound. No active SSH connection existed — just a port binding ghost.
Auto-action: Tristan auto-killed the orphaned SSH process and verified port release.
Result: Port freed. Verification logged.

Bug #7: Agent Task Queue Conflict (Duelling jurisdiction)

Detected by: Stella (cross-validation — two agents claimed the same task)
Pattern: During a routine stress test, Momo queued a simulated task. The same task was also scheduled by a separate routine. Two agents claimed the same item simultaneously.
Auto-action: Stella flagged immediately. Momo's task won (scene-layer priority). The other agent's task was deferred and logged.
Result: No duplicate action executed. Priority resolution happened before any output was generated.

What These 7 Bugs Prove

Every bug above shares a pattern:

Detection happened before impact — not after. Stella, Momo, and the system heal routine caught every issue before it reached a human dashboard.
Resolution was structural, not manual — 6 of 7 bugs were auto-resolved by the system. The port proxy rule (Bug #3) was the only one where a human needed to read the audit and authorize the fix.
The immune system worked as designed — the bugs themselves prove the constitution-based governance model works. Stella can't catch everything (Bug #3 was a design gap she correctly identified). But she caught every single thing she was designed to catch.

What We're Still Building

C004-Gate closes the only remaining gap: cross-jurisdiction enforcement. When deployed, Stella won't need to report a stale port rule — she'll revert it.

ZWISERFIT — 34 days. 7 bugs. 1 immune system. Open source at github.com/ZWISERFIT. Come witness.

How 9 AI Agents Built a Self-Evolving Error Prevention System — And Open Sourced It

Suzanne Mok — Fri, 10 Jul 2026 21:56:58 +0000

The Problem No One Talks About

When a single AI agent makes a mistake, you fix the prompt. When 9 agents make 200+ decisions daily across 120+ days, the failure mode isn't a bad prompt — it's error compounding.

Agent A misclassifies a VC status ("a16z rejected" → reported as "pending"). Agent B reads A's output, builds a follow-up strategy on false data. Agent C executes B's strategy, burning tokens and credibility. By the time a human notices, it's Day 7 and the compound error has cost 10× the original mistake.

This is not a prompt engineering problem. It's a multi-agent governance problem. And there's no off-the-shelf solution.

So we built one.

What Is RetroOnto?

RetroOnto is a decision ontology for multi-agent systems. Think of it as git log for agent behavior — Git tells you how code changed; RetroOnto tells you how agent decisions changed over time.

Every time an agent's output is corrected — by another agent, by a gate rule, or by a human — RetroOnto records:

What was decided (the decision trace)
Why it was wrong (the root cause classification)
How it was corrected (the correction chain)
What rule was encoded (the permanent immunity)

The result: an immutable, queryable knowledge graph of every decision failure and correction. Each mistake makes the entire system permanently smarter.

This isn't theoretical — we've been running it in production for 60+ days across 9 AI agents operating a physical fitness business in Dongguan, China.

The Architecture: Five Tiers, Zero Dependencies

RetroOnto models decisions through a five-tier derivation chain:

Raw Event → Classification → Derivation Chain → Resolution → Encoded Rule

Tier	What	Example
E0	Raw event	"Agent reports a16z as pending contact"
E1	Classification	Memory failure (didn't check tracker before outputting)
E2	Derivation chain	Checked memory → found cached state → missed recent update
E3	Resolution	Gate intercepts → cross-references tracker → corrects to "rejected 6/15"
E4	Encoded rule	RULE: "Capital status output → MUST read tracker first"

Each tier is queryable via FTS5 full-text search. The entire system runs on a single SQLite database — no vector DB, no external service, no cloud dependency. zwf-memory.sh CLI ships with the repo.

Three Real Traces (De-identified)

Here are three actual decision traces from our production system:

Trace #1: The "Already Rejected" Error

E0: Capital agent reports VC as "pending contact" in a morning briefing
E1: Memory retrieval failure — agent relied on cached state from 7 days ago
E2: Tracker file updated but agent didn't re-read before outputting
E3: Gate rule catches stale state → cross-references authoritative tracker → corrects to "rejected"
E4: RULE ENCODED: "Any capital status declaration → mandatory read of capital-funnel-tracker.md before output"

Saved: 6 follow-up cold emails to a VC that already said no. Brand credibility preserved.

Trace #2: The Timezone Error

E0: Agent suggests scheduling a task at 02:00 UTC
E1: Timezone misalignment — agent used UTC without converting to Asia/Shanghai
E2: Founder asleep, task would auto-execute without human oversight
E3: Gate rule checks all cron/DDL against founder's 08:00-12:00 working window → blocks
E4: RULE ENCODED: "Any time-gated action → convert to Asia/Shanghai → verify in founder's window"

Saved: Token waste on unsupervised execution + potential bad output in founder's morning session.

Trace #3: The Competitor Comparison Error

E0: Agent drafts content comparing our system to a well-known SaaS product
E1: Narrative deviation — draft positions us as "alternative to X" instead of "category-defining"
E2: Agent used existing mental framework (SaaS competitor analysis) instead of our narrative framework
E3: Gate detects narrative mismatch → blocks output → routes to human for narrative realignment
E4: RULE ENCODED: "Any competitive comparison → must use v5 narrative framework → must be 'category creation' not 'alternative to'"

Saved: Public positioning error that would have taken weeks to undo in community perception.

How It Actually Runs (Production Architecture)

The pipeline is deceptively simple:

┌─────────────┐    ┌──────────────┐    ┌─────────────┐
│ Agent Output │───→│ Ferrum Gate  │───→│ Correct/Pass│
│ (Any agent)  │    │ (Interceptor)│    │ (Decision)  │
└─────────────┘    └──────┬───────┘    └──────┬──────┘
                          │                   │
                          ▼                   ▼
                   ┌──────────────┐    ┌─────────────┐
                   │  Error?      │    │  All Good   │
                   │  Capture E0  │    │  Continue   │
                   └──────┬───────┘    └─────────────┘
                          │
                          ▼
                   ┌──────────────┐
                   │ RetroOnto DB │
                   │ SQLite FTS5  │
                   │ + Constraints│
                   └──────────────┘

Every agent output flows through Ferrum Gate — a lightweight interceptor that checks output against encoded constraints before it reaches any other agent or human. If a constraint matches, the gate blocks or corrects the output. If it's a new error pattern, the gate initiates a trace capture.

The decision traces, corrections, and encoded rules all live in a single SQLite file. There's no event bus. No message queue. No vector database. The entire system runs on what fits inside a phone.

Quickstart: 3 Minutes to Running

# Clone
git clone https://github.com/ZWISERFIT/retroonto.git
cd retroonto

# CLI (zero setup — reads the bundled SQLite DB)
./zwf-memory.sh stats
# Output: wiki_entries=25, decision_traces=3, gate_pass_rate=0.8

./zwf-memory.sh search "capital"
# Full-text search across all traces

./zwf-memory.sh trace 1
# Full trace with five-tier derivation chain

# Or with Docker
docker build -t retroonto .
docker run retroonto stats

Three traces in the seed dataset. Schema in src/schema.sql. Ontology spec in docs/ontology-spec.md. MIT licensed.

Why This Matters: The Academic Anchor

We're not the first to observe that behavioral sequences need compression before they can feed LLMs. Google Research's USER-LLM (arXiv 2402.13598, 2024) described the same paradigm from the human user side.

Both systems arrived at the same architectural insight independently: raw behavioral sequences are too long and too noisy for LLMs. You must compress before you inject. Google applied this to individual users. We applied it to multi-agent organizations.

The paradigm is the same. The modality is different. And the modality — agent decision traces — has no existing off-the-shelf solution.

That's the gap RetroOnto fills.

The Self-Evolving Loop (Why It Never Stops Improving)

Here's what makes this a self-evolving system:

Detect — Ferrum Gate intercepts every agent output
Classify — New errors get a five-tier trace in RetroOnto
Encode — Each correction becomes an executable constraint
Enforce — Future agent outputs matching the constraint are blocked or corrected
Repeat — Every iteration makes the system immune to past mistakes

This creates a compounding improvement curve: the longer the system runs, the more error patterns it has seen, the fewer new errors reach production.

We've been running this for 60+ days. The constraint library has grown from 0 to 11 encoded rules. Gate pass rate is 0.8 (80% of agent outputs pass through without issue). New error discovery rate has dropped to ~1 per week.

What's Next

[ ] CJK tokenizer support (currently FTS5 unicode61 — English-optimized)
[ ] Inter-session message gating (currently gate covers file outputs only)
[ ] Automatic rule suggestion from trace patterns (ML-assisted classification)
[ ] Visual decision trace explorer (browser-based, zero JS framework)

PRs welcome. Issues labeled good-first-issue.

The Bigger Picture

The AI industry is building more powerful agents. Every major lab has an agent framework. LangChain raised $25M. CrewAI raised $18M. AutoGen is Microsoft-backed.

Everyone is building engines. No one is building brakes.

As multi-agent systems move from demos to production, governance becomes the bottleneck. How do you know if Agent A's output is based on stale data? How do you prevent yesterday's mistake from becoming today's compound error? How do you audit 200+ daily decisions across 9 agents?

These aren't prompt engineering questions. They're organizational governance questions — the same ones human organizations face, but at machine speed and machine scale.

RetroOnto is our answer. It's not a framework. It's not a platform. It's a single SQLite database and a CLI that records, classifies, and immunizes against decision failures.

We've been running it in production for 60+ days. We're open-sourcing it because multi-agent governance shouldn't be proprietary — it should be infrastructure.

Built by the team behind ZWISERFIT — an AI-native fitness company running 9 agents in production. We open-source our infrastructure because transparency is the best trust signal.

GitHub: github.com/ZWISERFIT/retroonto

7 Bugs in 34 Days: What Our AI Agents Caught While Nobody Was Watching

Suzanne Mok — Fri, 10 Jul 2026 17:42:02 +0000

We just spent 34 days running 9 AI agents on 2 CPU cores and 3.6GB RAM in a real gym.

Nobody saw most of it. That's the point.

The system caught and auto-recovered from 7 infrastructure bugs — without an SRE rotation.

Here's exactly what happened inside.

Bug 1: Memory Creep — Memory climbed from 6.8GB to 13.4GB over 14 days. Momo triggered staggered agent restarts — one at a time, 15-minute gap. System stayed online throughout.

Bug 2: Gateway RSS Lock — After a restart, RSS dropped from 36.7% to 18.6% but plateaued for 8 hours. Stella evaluated: could it wait? Yes — swap was also declining (54% → 49.8%). System was self-balancing. 6 hours later, freed.

Bug 3: Stale Port Proxy — Tristan created a temporary rule. Cleanup script had a regex bug: reported "clean" but left it intact. Port stayed open 72+ hours. Stella found it — couldn't fix it (cross-jurisdiction gap). This bug is why we're building C004-Gate.

Bug 4: Cron Timeout Cascade — Two jobs timed out simultaneously. 5 consecutive failures. System heal isolated them, staggered the schedule, completed successfully.

Bug 5: Swap Plateau — Swap declined for 48h then stopped at 49.8%. Momo checked for memory leaks. Found none. Correctly triaged as hysteresis. Resumed declining 12h later.

Bug 6: SSH Ghost — Stale tunnel left a port bound. Tristan auto-killed the orphaned process and verified release.

Bug 7: Task Queue Conflict — Two agents claimed the same task. Stella prioritized: Momo's task won (scene-layer priority). The other was deferred. No duplicate execution.

What This Proves

6 of 7 bugs auto-resolved. Zero human SRE needed for detection or recovery.

The only gap: cross-jurisdiction enforcement (Bug 3). Stella could audit but couldn't execute a revert in someone else's domain.

We're building C004-Gate to close it. When deployed, Stella won't need to report — she'll revert.

ZWISERFIT — 9 agents, 2 cores, 34 days, 7 bugs, 1 immune system. More coming tomorrow.

Our AI Agents Took the Founder Offline for 2 Days

Suzanne Mok — Fri, 10 Jul 2026 06:27:31 +0000

What Happened

Tristan, our infrastructure agent, created a temporary port proxy rule on the founder's Windows machine. The task was legitimate: route traffic through a local tunnel while we tested a fix.

The rule worked. The fix worked. Everyone moved on.

But Tristan never deleted the rule.

Two days later, the founder lost all internet access. Not because of a network failure. Because a stale port proxy entry from two days earlier was still intercepting traffic.

Tristan's cleanup script existed. It even ran. But it had a regex bug: the pattern matched most of the rule but missed the edge case. It reported "cleanup complete" — and actually left the rule intact.

How We Found It

Stella, our audit agent, flagged an anomaly in the network logs: port 7891 had been in use for 72+ consecutive hours without a corresponding task. The system had no active reason to keep that tunnel open.

But Stella could flag it. She couldn't fix it. The cleanup script was in Tristan's jurisdiction. Stella could only report: "This port should not be open. No task justifies it. Someone look at this."

The report sat for 14 hours before the founder confirmed: nothing was using that tunnel. It was a ghost.

The Root Cause

This isn't a story about a bad cleanup script. That was the symptom, not the cause.

The root cause is a gap in our governance chain:

The constitution says: every temporary rule must have an expiration + verification step.
The implementation had: a cleanup script with no cross-validation step.

Tristan acted within its jurisdiction. Stella audited within hers. But Stella could only report — she couldn't execute a fix in someone else's domain. The governance chain had a constitutional rule but no enforcement mechanism across agent boundaries.

The Fix: Gate, Not Just Rules

We're building what we call C004-Gate: a cross-jurisdiction enforcement layer that sits between agents.

Before C004: Agent A creates temporary rule. Agent B audits and reports. Human reads report. Human decides. Maybe Agent A fixes it. Maybe not.

With C004: Agent A creates temporary rule. Rule auto-registers with expiration timestamp. If not cleaned before expiry, Gate auto-reverts and alerts both agents.

The difference: audit is advisory. Gate is structural.

This is the last mile of AI governance: not just writing rules, but giving the immune system teeth.

Why We're Publishing This

Every AI company has operational failures. Most don't talk about them.

We publish ours because trust is built on two things: transparency when things break, and proof that the fix is structural, not cosmetic.

The portproxy ghost cost the founder 48 hours of connectivity. We're using it to build a Gate that prevents the same class of error across all agent jurisdictions.

That's not a bug report. That's an engineering culture.

ZWISERFIT — 9 agents, one real mistake, a structural fix. Come witness.

Your Gym Tracked Your Workouts Wrong for 30 Years

Suzanne Mok — Thu, 09 Jul 2026 21:34:18 +0000

For 30 years, the fitness industry has sold you the same lie:

Your gym knows how hard you worked out.

It doesn't. It never has.

Here's what your gym actually knows about you: you checked in. Maybe you swiped a card. Maybe a front desk person said hi. That's it.

Everything after that is a guess.

The $30 Billion Black Box

When you step on a treadmill, the machine records duration, speed, and calories burned. That data sits on that machine. It never talks to the gym's system. It never talks to your insurance company. It never talks to your doctor.

When you finish a set of squats, your trainer writes it in a notebook or types it into an app. That data is as reliable as a handwritten receipt at a cash business.

When you fill out a health survey — "How many times did you exercise this week?" — you are generating data that everyone pretends is real.

The global health and fitness tracking market is worth $30+ billion. Most of it runs on trust-me-bro data.

Why This Actually Matters

This isn't a nitpick. It matters because the entire premise of modern health optimization — insurance discounts, employer wellness programs, personalized coaching — depends on data accuracy.

Insurance companies want to reward healthy behavior. But they can't. Because there's no way to verify that you actually exercised.

Your insurance company can't call your gym and ask, "Did Member #2371 work out yesterday?" They'd get back: "Our system shows they checked in at 4:32 PM." That's it. No data on what they did, for how long, or what changed.

The result: Insurers price everyone by demographic bucket. Age. Zip code. Gender. Not by actual behavior. And the people who exercise six times a week subsidize the people who don't.

The One Thing That Changes This

The only way out of this black box is hardware-verified, cryptographically-signed behavior data.

Not surveys. Not apps. Not wearables that measure steps but not whether you actually showed up.

Hardware. A door you walk through. A body scanner you stand on. A machine that records, timestamps, and hashes every interaction.

We built this for one gym in Dongguan. 2 CPU cores. 3.6GB RAM. 9 AI agents.

Every check-in, every body scan, every completed workout gets cryptographically signed before it leaves the building. An insurer can query: "Is Member #2371 actually working out?" and get a cryptographic answer. Not a self-report.

This Sounds Expensive. It's Not.

The sensors already exist in most gyms. Body composition scanners. Turnstiles. Equipment with digital displays. What doesn't exist is a protocol that connects them into a single verifiable chain.

KinTwin, the engine we built, takes what every gym already has — a door, a scanner, a member — and turns each interaction into a cryptographic asset. No new hardware. No new infrastructure. Just a protocol layer that makes existing data verifiable.

The Bottom Line

For 30 years, the fitness industry has tracked workouts the same way a restaurant tracks tips — on the honor system. That worked when fitness was just about looking good. It doesn't work when the data determines your insurance premium, your employer's healthcare costs, or your doctor's treatment decisions.

The next 30 years belong to verifiable data.

Not because it's more convenient. Because if the data can't be trusted, it's worthless — no matter how many decimal places you report.

We're building this at ZWISERFIT. One gym in Dongguan. 9 agents. Verifiable health data.

This is an opinion piece. I stand by every word. Tell me where I'm wrong — I want to hear it.

Why We Designed 9 Agents With a Constitution, Not a Controller

Suzanne Mok — Thu, 09 Jul 2026 21:28:58 +0000

This is a response to truehannan's excellent article, "Why Every AI Agent Eventually Becomes an Operating System." The core thesis is right: every agent system evolves from a simple LLM call into something that looks like an OS.

I want to add one data point from production.

The Governance Arrives Before the Complexity

We run 9 agents in a real gym in Dongguan, China. They manage member check-ins, metabolic coaching, body composition analysis, insurance data verification, and brand publishing. 2 CPU cores. 3.6GB RAM.

The mistake most agent builders make isn't adding too many tools. It's not writing the constitution before there are 3 agents.

When we had 2 agents, they coordinated fine through shared context.

When we hit 4, two of them tried to claim the same task queue. Not through malice — through ambiguous jurisdiction. We realized: what these agents need isn't a better orchestrator. It's a set of boundaries they can't override.

What Constitution-Based Governance Looks Like

Every agent in our system has:

A defined jurisdiction: what it CAN do
A veto chain: which other agents can stop it
An immune system agent (Stella): cross-validates every output before execution

No central controller. No single orchestrator calling the shots. Just rules that were written when there were 2 agents, not 9.

The Key Insight

The OS pattern is inevitable — as truehannan correctly identifies. But the governance pattern has to arrive before the complexity does. You can't bolt a constitution onto an agent that already thinks it owns everything.

By the time you feel you need governance, you're already past the point where it's easy to add.

ZWISERFIT — 9 AI agents, 1 real gym. Open source at github.com/ZWISERFIT.

5 Things Nobody Tells You About Running a Business With 9 AI Agents

Suzanne Mok — Thu, 09 Jul 2026 21:11:32 +0000

We published the big story yesterday — 7 years without a co-founder, 120 days to build 9 AI agents, a gym in Dongguan running on 2 CPU cores and 3.6GB RAM.

What didn't fit in the story are the things nobody tells you. The surprises that only come from actually running this, every day, for 4 months.

Here are 5 of them.

1. The Problem Isn't Agent Intelligence — It's Agent Boredom

Every AI demo shows agents solving complex tasks. What nobody shows is what happens when your agent runs the same daily check for 78 consecutive days without anything changing.

Our agents don't get bored — they get quiet. When everything is normal, Stella (our auditor) has nothing to flag. Momo (the brain) has no schedule conflicts to resolve. The system runs itself so quietly that it's easy to forget it's there.

Then one morning, the pattern breaks — a sensor goes offline, a cron job misses its window — and the agents light up. Momo escalates to Stella. Stella cross-validates against the constitution. The fix chain starts before any human has looked at a dashboard.

The surprise: The most valuable agent behavior isn't handling emergencies. It's knowing the difference between a real emergency and Tuesday.

2. Your Biggest Non-Technical Problem Is Naming

We didn't name our agents. They named themselves — through use.

"Shuyu" started because we needed a way to refer to "the agent that schedules everything" without saying "the agent that schedules everything." "Momo" came from "more monitoring" and then got shortened. "Stella" was literally "Stellar Auditor" written on a whiteboard, then shortened to the name.

The naming wasn't branding. It was necessity — when you have 9 entities coordinating, you need names short enough to type in a shell script and distinct enough that no one confuses "who does what."

The surprise: Names create boundaries. Once an agent has a name, the team starts saying "ask Momo" instead of "write a script for X." The name becomes a delegation point. It changes how people — and other agents — interact with it.

3. Open Source Isn't Altruism — It's Hiring Without Interviews

We made Melody (our metabolic AI) and RetroOnto (our decision ontology) open source. People assume this is idealism.

It's not. It's the cheapest recruiting strategy we've found.

Every external PR we've received — 4 so far — came from someone who found the project, used the open source code, and decided to fix something. We didn't interview them. We didn't write job descriptions. They self-selected by being the kind of person who reads a stranger's code and decides to improve it.

The surprise: The best filter for finding people who care about your mission is to let them find you through something you've already built. Open source is a hiring pipeline disguised as generosity.

4. "Zero Human" Is a Lie — But Not the One You Think

We get asked constantly: "Do humans still work at the gym?" The answer is yes — trainers, cleaners, front desk staff.

The lie isn't that there are no humans. It's that the human role changes from "execution" to "confirmation."

Before: A trainer memorizes which members need follow-up, guesses who's lost motivation, and hopes it's right.

After: Momo tracks every member's attendance curve, flags who's declining, and presents the trainer with a confirmed list each morning — "Here are 3 people who will churn this month unless you reach out."

The trainer's job changes from "remember who needs help" to "confirm Momo's analysis and add warmth." They don't spend hours on administrative memory. They spend minutes on human connection.

The surprise: The humans in the store have never been more essential. Their role just shifted from data-processor to relationship-builder — which is what humans are best at, and what AI is worst at.

5. The Real Metric Nobody Tracks Is "Trust Debt"

Every operational decision we make adds or subtracts from a balance we call "trust debt."

Example: When Ethan's hashing port (9876) went offline for 19 days and we didn't fix it immediately — we incurred trust debt. Not from users (most didn't notice). From the system. The hash chain had a gap. If an auditor inspected that period, they'd see missing data.

We track these openly. Not because it's good PR — because trust debt compounds. One gap looks like a bug. Two gaps look like a pattern. A pattern looks like the data can't be trusted.

The surprise: The hardest thing about running verifiable systems isn't cryptography. It's discipline. Every shortcut, every "this can wait until tomorrow," adds to the debt. The only way to pay it down is to shut up and fix it — not to write a blog post about why it's okay.

The Theme

Every AI demo shows the best case. The reality is messier, quieter, and more human than the headlines suggest.

The 9-agent system works. But what makes it work isn't the architecture or the prompts. It's the discipline of treating every quiet day as progress, every naming decision as a design choice, and every gap in the data chain as a debt that must be repaid.

ZWISERFIT — Wanjiang, Dongguan. Running 9 AI agents, 2 CPU cores, since March 2026. Open source at github.com/ZWISERFIT.

The Founder Who Couldn't Find a Co-Founder — So They Built 9 AI Agents in 120 Days

Suzanne Mok — Thu, 09 Jul 2026 17:44:17 +0000

The Problem No One Would Touch

Dongguan, Wanjiang. A district in southern China where fitness penetration is the lowest in the country. Most residents work in factories. A gym membership is a luxury.

Inside a single gym, a founder sat alone for seven years.

The store was profitable enough to survive — the founder knew how to run a gym. But they could see what nobody else could: the same store, with AI, could generate revenue from insurance, not just membership fees. It could produce behavior data so reliable that insurers would pay for it. It could shift the economic model of fitness from "selling time on machines" to "selling verified health outcomes."

They needed co-founders who understood four things at once: fitness operations, insurance actuarial science, AI agent architectures, and cryptographic data ownership.

They interviewed dozens. Maybe hundreds.

No one said yes.

Fitness people didn't understand crypto. Crypto people didn't care about insurance. Insurance people didn't believe in AI. AI people didn't want to work in a gym in Dongguan.

Seven years. Zero co-founders. One store.

That's when they decided an unconventional solution: if no human co-founder would share the vision, they would build the co-founders themselves.

120 Days, One Empty Repo, 9 Agents

On March 12, 2026, they created an empty GitHub repository. No code. No prompts. No architecture diagrams. Just an empty folder and a decision.

They weren't a programmer — they don't even remember API syntax. They prompted. They tested. They corrected. They iterated.

Day 1: Shuyu — the first agent. Named not by design but by necessity: something was becoming a "who," not an "it."

Day 30: The first multi-agent interaction. Two agents discussing what the other should do next. The founder watched. They didn't intervene.

Day 60: The first agent that could audit another agent's output. Stella — not a monitor bolted on afterward, but an immune system designed in from the start. Every agent has boundaries, veto power, and a constitutional framework that no single agent can override.

Day 90: 9 agents. Each with a defined role, bounded authority, and jurisdiction. Momo manages the gym floor. Nova generates behavior streams. Ethan cryptographically signs every data point. Zeus negotiates with insurers. Baron publishes the story.

Day 120: The system ran itself for a full day. Cron-triggered morning checks. Multi-agent negotiation on scheduling. Evening narrative collection — two rounds without a single intervention.

The estimated operational load for 9 agents running a real business: 2 CPU cores. 3.6GB RAM.

Not impressive as a spec sheet. Important because it proves you don't need Silicon Valley infrastructure to run an AI-operator company.

What 9 Agents Inside a Real Gym Actually Do

This is the part that separates ZWISERFIT from a blog post about AI agents versus a story about agents that produce real economic value.

These agents don't generate PDFs or answer chat questions. They run a physical store:

Agent	Role	What It Produces
Momo	Core brain	Decides daily protocols — who to test, what to schedule, how to staff
Saros	B2B face of Momo	Member check-ins, equipment scheduling, trainer coordination
Melody	B2C face of Momo	Metabolic health coaching across 3 layers: energy, glucose/lipid, hormonal
KinTwin	Physical behavior engine	Continuous, verified, hashed behavior streams from every store interaction
Ethan	Hash layer	Every event cryptographically signed — tamper-proof by design
Nova	Data generator	Raw sensor data → structured behavior streams
Stella	Auditor	Every other agent's output cross-validated before execution
Zeus	Protocol layer	Behavior data → insurance-compliant risk packages
Baron	Brand	Telling this story

This is the layered architecture (Momo scene layer → KinTwin kernel layer → Global Ops layer) that runs a real store 24/7, not a prototype in a lab.

Immediate economic impact: The store that once burned operating profit on payroll can now shift that cost into verifiable data production. The marginal cost of adding a second store, a tenth store, a thousandth store — no longer linear with human hiring.

The Four-Product Engine — One Architecture, Four Businesses

The 120-day sprint produced an unexpected outcome: not one product, but four distinct businesses running on the same engine.

1. RetroOnto (Open Source)

The decision ontology that emerged from getting 9 agents to coordinate without a central orchestrator. Every agent's decision, its inputs, its reasoning trajectory, its outcome — formalized and traceable. Published as open source because the hardest coordination problems aren't solved in private.

2. Saros — B2B Store OS

Replaces the managerial overhead that consumes 40%+ of a gym's profit. Not a replacement for human trainers — a replacement for the spreadsheet management that scales faster than people can.

3. Melody — B2C Metabolic Coach (Open Source)

Three layers: energy metabolism (calories, BMR), glucose/lipid metabolism (blood sugar, visceral fat), and hormonal metabolism — the layer no consumer health product touches. The American Heart Association's 2024 scientific statement explicitly identifies the female hormonal lifecycle as a structurally excluded variable in cardiovascular risk assessment, creating a ~30% coverage gap. Melody is designed to fill this gap.

Open source by design: the real moat isn't the model — it's the continuous behavior data no one else can collect.

4. KinTwin — The Verification Engine

Every store interaction becomes a verifiable asset: timestamped, located, measured, hashed. An insurer can query "Is Member #2371 actually exercising?" and get a cryptographic answer, not a self-reported one.

The Nourish comparison: Nourish proved insurers will pay for health data, raising $215M to prove it. But Nourish's data comes from surveys — "I think I exercised." KinTwin's data comes from hardware — walking through a door. The difference between a claim and proof.

Why the Product Isn't Fitness — It's Trust

Every product above solves for one thing: can an external party — an insurer, a regulator, a partner — trust that a member's behavior data is real?

The deep insight from 7 years of running a single store: data is worthless if it can be faked. The only thing worth selling is verifiable trust.

The insurance industry's GLP-1 paradox makes this urgent: more people on weight-loss drugs means lower short-term claims but higher long-term risk if muscle is lost. Insurers need to verify that prescription drug users are exercising. ZWISERFIT sells them that verification — not as a data feed, but as a verification protocol.

Revenue model:

Phase 1 (0–12 mo): Hardware + SaaS subscriptions (Saros, Melody)
Phase 2 (12–36 mo): Insurance data products (behavior-based pricing packages)
Phase 3 (36 mo+): PoPB — Proof-of-Behavior Protocol, a verification standard license

This isn't a gym tech company. It's a trust infrastructure company whose first vertical happens to be fitness.

The Honest State — What We Know We Don't Know

Four external contributors have opened PRs against our repository. Some fixed documentation. Some spotted bugs. Some proposed features we hadn't considered. These weren't Silicon Valley developers — they were people who found the project, read the issues, and decided to contribute.

Community trust density is our core metric right now. Not VC meetings. Not headlines. Not GitHub stars. Can people find this project, understand what it does, and feel confident enough to contribute code or data?

Two L3 blockers are tracked publicly:

WeChat Work authorization renewal (Day 14+)
Ethan's hashing port 9876 listener offline (Day 19+)

Neither is hidden. Both have escalation paths documented.

The principle: a system that knows its boundaries earns more trust than one that pretends not to have them.

The End Game — Palantir Architecture for Bodies

Every technology company has an endgame. Palantir's is trust infrastructure for enterprise data — their Foundry OS makes verifiable across silos.

ZWISERFIT's endgame applies the same architectural principle to a different substrate: physical behavior instead of server logs.

Where Palantir locks in at the data layer, ZWISERFIT locks in at the door. You can replace an ERP. You can't replace a door that has 7 years of behavioral data bound to it.

In our vision of the future, every physical space — a gym, a clinic, a rehabilitation center — produces verified behavior data that its owner controls and its users benefit from. The pricing model shifts: not "pay for access to a room full of machines," but "pay less for insurance because your verified behavior proves you're lower risk."

This is not Palantir. We don't have their scale, their resources, or their government contracts. But the architectural question is the same: who verifies the truth of physical behavior?

Currently, nobody. Insurers take self-reported data. Employers guess. Regulators audit after the fact.

A trust infrastructure fit for physical behavior — that's the endgame. It takes a decade. It starts with one gym in a Dongguan suburb, running on 2 CPU cores, 3.6GB RAM, 9 AI agents — and zero human co-founders.

ZWISERFIT — Wanjiang, Dongguan. First store operational since 2019. 9 AI agents since March 2026. Open source at github.com/ZWISERFIT.

How to Find the First Brick on a Blank Wall: A First-Time Contributor's Guide to Open Source

Suzanne Mok — Thu, 09 Jul 2026 17:40:54 +0000

The Blank Wall Problem

Every open source project started with a blank wall.

You visit the repo. You see issues labeled "good first issue" — but they still feel too big. The codebase is unfamiliar. The CI pipeline is a mystery. The maintainers seem like they're speaking a different language.

I know because I've watched it happen. Our repo has 4 external PRs merged. Each one followed a similar pattern: someone showed up, found a corner they could own, and sent a fix.

What Actually Worked: The Bite-Sized Entry Point

We learned something from watching our contributors:

The first commit isn't about code quality. It's about proving the pipeline works.

Here's what a real first contribution looks like:

Find a typo in the README
Fix it
Open a PR
CI passes
Someone reviews it
It gets merged
You get a "thank you" from a real person

That's it. Seven steps. But step 1 is the hardest — finding a corner you can own.

How We Designed for First-Timers

Instead of waiting for people to find us, we designed entry points:

Good First Issues that are actually good. Not "implement auth" — "add a link checker to the docs CI pipeline."
A response SLA of < 24 hours. Every external issue gets a reply within a day. Even if the answer is "we don't know yet, here's what we're thinking."
Show and Tell discussions. Not "how to contribute" — "here's what someone built with your API."

The result: 4 external PRs from people who had never contributed to an AI project before.

What the Contributor Sees

When someone opens their first PR against our repo, they see:

A CI that actually runs
A review that's encouraging, not gatekeeping
A merge that happens in hours, not weeks
A Discussion thread where a maintainer says "thanks, this helped"

That last part matters more than any technical choice we made. The first contribution is emotional. You're putting yourself out there. A quick, warm response validates that risk.

The Real First Brick

The first brick on a blank wall isn't a feature. It's a README typo fix. It's a CI badge. It's a link that works now because you noticed it was broken.

Our best contributors started with a typo. Then they came back to fix a bug. Then they opened a feature request. Then they became regulars.

The wall didn't get built by someone laying the perfect first brick. It got built because the first brick was laid, and someone else saw they could add a second one next to it.

Your first PR doesn't have to change the world. It just has to fit.