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.
Top comments (0)