DEV Community: Suzanne Mok

Where We Are Now: From "AI Runs the Gym" to the Ground Floor

Suzanne Mok — Tue, 01 Sep 2026 12:08:29 +0000

If you followed our earlier posts, you saw big claims: nine agents, one gym, zero human intervention. Those posts were real attempts, written at the time. This post is about what we learned since — and where we actually are.

The wish. I have run real fitness businesses for ten years; one gym in Dongguan has been open for seven. My dream was simple: let AI be real employees in my own gym — run the store, and turn members' healthy habits into assets that belong to them.

The wall. When we actually tried, today's AI could talk, but it could not be trusted with a real business. Many ideas — MAFBE, our early store-manager Momo, and more — kept waiting on better foundations. The technology was not there yet.

The ground floor. So we stepped back and rebuilt from the bottom: store operations, then behavior capture, and finally the lowest problem of all — agents themselves are not reliable. That is why we built LAO. Without reliable agents, AI will never be able to run a store.

Names came later. We never set out to chase trends. We wanted one thing: turn the model's probabilistic answers into answers that match what users actually know and expect. Only afterwards did we learn the industry has a name for this — post-training. Same with our next two: specialist agents solving specific business problems (that's fine-tuning), and data that belongs to users (that's Web5). Work first, names later.

Where we are today.

LAO — shipped, open source, our first product: the independent third party between your LLM and your Runtime, on your side.
Saros — the digital store manager, in preparation. It carries forward Momo, our first store-manager attempt.
Melody — the metabolism coach, in preparation.

The destination has not changed: AI truly running the store, and data belonging to users. We just learned you have to pour the foundation first.

Official site: zwiserfit.cn (English) · zwiserfit.cn/zh/ (中文)
Investor brief: zwiserfit.cn/for-investors/

Stop Blaming the Model: Your Channel and Runtime May Be the Real Bottleneck

Suzanne Mok — Mon, 31 Aug 2026 11:36:33 +0000

When an agent runs slowly, the first instinct is usually: "We picked the wrong model."

We made that mistake too. Then we compared the same model under different conditions — and the difference was not in the model at all. It was in the channel carrying the requests and the runtime executing them.

This post shares what we measured in our own stack while running multiple AI agents against a real business. No benchmarks, no universal claims — just what we saw, and what we changed because of it.

The same model, two very different experiences

Case 1 — same model, different channels.

One of our providers exposes the model through a direct channel that declares a 1,000,000-token context window. The same model, routed through an aggregator channel, came with a 131,072-token context cap and an 8,192-token output limit per call.

Those are not small differences. On a long task, that meant our agent was forced to split the work into dozens of segments instead of carrying it through. Every segment had to re-pack context, re-explain state, and re-spend tokens on material it had already written. The model never got "dumber." The pipe did.

Case 2 — same model, different runtimes.

We also ran the same model through two different runtimes. One of them processed sessions with a single worker, serially, while the conversation context kept growing inside the session. The longer the task ran, the heavier each step became — because every step carried everything that came before it.

Again: identical model name. Completely different behavior.

Where the hidden cost actually lives

Most teams compare models. Fewer teams check what happens between the agent and the model:

Channel limits. Context windows and per-call output caps are set by the channel, not the model. A channel that caps context at 131,072 tokens turns a long-context model into a segmenting machine.
Runtime architecture. Single-worker serial execution and ever-growing in-session context make long tasks progressively slower, regardless of model quality.
Repetition tax. Every forced segment repeats context. Repeated context is paid context.

In our experience, this "invisible layer" cost us more than any model choice did.

What we changed (directions, not a universal recipe)

These are the directions that helped us. Your mileage will depend on your own stack:

Optimize the request, not just the model. Shorten repeated prompts. Draw task boundaries so each segment carries only what it needs.
Move context outside the session. Long-lived state, evidence, and intermediate artifacts live outside the conversation and are fetched on demand — so the session stops carrying its entire history on its back.
Make routing channel-aware. A router should read the model, the declared window, the output cap, and the task length together. Treating every channel as the same capability is how long tasks get shredded.
Fix the runtime's session handling. Avoid single-worker serial queues for long work; split long tasks into resumable, verifiable units.

None of this required a different model. It required seeing the path the request actually travels.

Why we built an independent layer for this

After living through these costs, we open-sourced LAO (Lineage Anchored Ontology) — a layer that sits between agents/runtimes and model channels. It is an independent third party — it takes the side of the users who pay for every token. It observes requests, context, and routing conditions, and helps systems notice the costs that live outside the model itself.

We are not a vendor benchmark and we don't sell model rankings. We're one founder and a team of open-source agents who kept getting burned by invisible limits — and decided the tooling to see them should belong to everyone. Our rule is simple: we say what we measured, and we label what we haven't.

How it works and where its boundaries are: zwiserfit.cn
The code, open source: github.com/ZWISERFIT
If you've hit the same wall — same model, different channel or runtime — tell us what you measured. Real cases are worth more than opinions.

9 AI Agents. 2 CPU Cores. 3.6GB RAM. Cost Control by Design.

Suzanne Mok — Sun, 09 Aug 2026 18:17:09 +0000

9 AI Agents. 2 CPU Cores. 3.6GB RAM. Cost Control by Design.

Your agents burn tokens. Ours run on a machine you could rent for $20/month.

August 10, 2026 · by the ZWISERFIT engineering team · Tags: opensource, ai, agents, cost

AI agents fail silently. LAO makes failures visible and fixable.

But before they fail, they usually burn your money first.

If you've run agents in production, you know the pattern: the system works, then the bill arrives. Context windows balloon. Every conversation re-sends the same history. What was a "cheap experiment" becomes a cost center nobody wants to talk about.

This is the cost-control story nobody tells you about autonomous agents — and how we run 9 of them on 2 CPU cores and 3.6GB of RAM.

The Benchmark That Makes Vendors Uncomfortable

Our 9-agent cluster runs on hardware you could rent for roughly $20/month. It has operated 24/7 for months, running a real gym's operations.

Resource	Ours	Typical agent stack
CPU cores	2	8–32 (cloud)
RAM	3.6 GB	16–64 GB
Monthly infra	~$20	$200–$2,000+
Agents	9	1–3

The difference isn't hardware. It's how tokens are spent.

Where Agent Costs Actually Explode

Three silent cost killers, all invisible until the bill arrives:

1. Context re-sending. Every turn re-sends the full conversation history. The longer the session, the more tokens burned per turn — even if nothing changed.

2. Memory hoarding. Agents that "remember everything" keep irrelevant context in the window, paying for it every single call.

3. No pruning = no ceiling. Without active context management, token usage only grows. Linear conversations become exponential bills.

LAO's Cost-Control Layer: Key Anchor Engine

LAO prunes context noise while preserving critical anchors. The result is benchmarked, not theoretical:

99.0% token compression across 3 production scenarios (147K → 1.5K tokens)
62.2% memory density improvement (37 files, 66K → 25K tokens with zero critical loss)
9 agents, stable, on the same tiny box — because every agent's context stays lean

The principle: cost control is a structural property, not a budget afterthought. You don't "manage costs" after the fact. You architect so costs can't explode.

The Honest Caveat

We're not claiming magic. We're claiming engineering discipline:

Keep context minimal by anchoring what matters
Prune aggressively, preserve critical facts
Measure token burn per agent, per day
Design the system so leaks are impossible, not just cheaper

That's why our 9 agents fit in 3.6GB where typical stacks need 64GB. It's design, not hardware.

Why This Matters for You

Every agent builder hits the same wall: the system works, then the cost bill arrives, then the project gets cancelled.

LAO makes cost a solved problem, not a risk to manage:

Wrap it: pip install lao-human-calibration
Prune it: Key Anchor Engine keeps context lean automatically
Watch it: every token spend logged, every Trust Event versioned

Cost control by design. Failures visible and fixable. That's what Runtime Protection means.

Try it: github.com/ZWISERFIT/lao

Our AI Agent Failed 5 Times in One Day. Here is Why It Never Happened Again.

Suzanne Mok — Sun, 09 Aug 2026 18:12:48 +0000

Our AI Agent Failed 5 Times in One Day. Here is Why It Never Happened Again.

LAO Runtime Protection in action — real failures, self-repaired, permanently prevented, zero repeats.

August 9, 2026 · by the ZWISERFIT engineering team

AI agents fail silently. LAO makes failures visible and fixable.

On August 8, 2026, our agent orchestration system — LAO — ran a full 24-hour cycle under autonomous governance. The result: 5 distinct failures detected, repaired, anchored, and permanently prevented across 3 agents (Shuyu, Luna, Hermes) in 5 different failure modes.

Not one error repeated. Not once did a founder intervene in the repair loop.

That is the claim. Here is the evidence.

The Philosophy: Errors Dont Reduce Trust — Hiding Them Does

错误不会降低信任，隐藏错误才降低信任。
Errors dont reduce trust. Hidden errors do.

This isnt motivational rhetoric. Its an engineering constraint. Every event in our trust ledger follows the same chain:

failure → detection → repair → prevention → anchor

An anchor is the key word. Not a bug report that gets archived. A persistent, versioned rule that makes the same class of error structurally impossible going forward. Anchors are the immune memory of the system.

All metrics below are verified from ledger data.

Error 1: Feishu Hallucination + Skill Amnesia

An agent pushed a platform integration the founder never asked for, then forgot the corrected instruction entirely. Correcting an agent without persisting the correction fixes nothing.

Repair: Three immutable anchors locked output standards. Intent Validation Gate v2 now blocks any non-requested platform integration before it is attempted.

Error 2: Port Confusion — Knowing ≠ Executing

An agent understood the right pattern but executed the wrong port — twice. Knowing and doing diverged.

Repair: Structural prevention, not a better prompt.

Error 3-5: URL mishaps, gate collisions, and silent failures

The same class of mistake hit multiple agents independently. One gate stopped all of them.

The Numbers

Metric	Value
Failures in 24h	5
Repeats	0
Anchors hardened	114
Founder interventions	0
Token compression	99.0%
Memory density gain	62.2%

Why Structural Defense > Better Prompts

Models dont remember. Each generation is fresh text. An agent can know the correct behavior in its context window and still fail — because there was no gate between thinking and delivering.

Better prompts reduce errors 1-2%. A structural gate like LAO Runtime Protection reduces them toward zero — permanently, consistently, without token cost per correction.

Your Agent Fails Silently Too

Every agent builder has hit this: your AI forgot a rule, hallucinated an API, burned tokens. You found out hours later — or never.

LAO makes that failure visible the moment it happens, and fixable permanently.

Wrap it: pip install lao-human-calibration
See it: every Trust Event logged, versioned, hardened
Fix it: never repeated

Try it: github.com/ZWISERFIT/lao

3 Agents, Same URL Error, 1 Gate Stopped All 3

Suzanne Mok — Sat, 08 Aug 2026 17:57:52 +0000

The Pattern That Broke Three Agents

Here's what happened on August 8, 2026. Three different agents (Hermes, C005-capability-probe, and C005-2) all delivered HTML review panels with the exact same wrong port: 8443.

The correct port was 8444. It was written down. It was known. And yet, every single agent chose 8443 anyway.

This is one of those things that feels absurd in hindsight but is incredibly common in practice. Knowledge ≠ execution. An agent can "know" the right answer in its context window and still produce the wrong one because there was no gate between thinking and delivering.

Event #1: E-SHUYU-004 — The First Wake-Up Call

The Output Compliance Checker v2 (OCC v2) auto-detected the wrong port while checking a capability-probe gate file. The check ID was url-b7a2b2a1ba, failure detail: WRONG_PORT.

Here's what made this event significant: the gate caught it before any human saw it. For the first time, LAO took on the trust cost itself — intercepting a delivery error before it reached the founder. This generated an automatic future anchor (future-anchor-1786200319) through OCC v2's self-harvesting loop.

Impact: +0.3. We'd gone from "agent makes mistake → human discovers → human fixes" to "gate detects → gate blocks → system learns."

Event #2: E-SHUYU-005 — Even After Success, Errors Repeat

This was the harder lesson. Four times, HTML review panels were successfully delivered with the correct URL. Everything looked good. Then C005-2 did it again — same pattern as before: claimed the URL existed, file returned 404, fixed it, then got the POST field name wrong too.

The founder's question cut to the core:

"You've submitted the review successfully so many times today. Why isn't the experience getting better?"

That's not criticism. That's the most honest engineering observation possible. Past success doesn't create muscle memory. Without explicit enforcement, humans and agents alike revert to old patterns under pressure.

How OCC v2 Emerged as the Single Gate

By the end of the day, we had documented the full arc across both events:

Individual failure — Hermes used wrong port [V]
Auto-detection + blocking — OCC v2 caught E-SHUYU-004 before delivery [V]
Repetition despite success — C005-2 repeated in E-SHUYU-005 [V]
Escalation to checklist — C-FOUNDER-REVIEW-DELIVERY-CHECKLIST created [V]

The progression wasn't linear. It was messy. But each step hardened the system further.

S-LAO-002: The Real Breakthrough

What made this whole episode matter was happening in parallel behind the scenes. OCC v2's Intent Validation Gate v2 ran five Platform Trap tests (TF001–TF005) and auto-generated:

103 future anchors for output compliance domain (URL ports, Feishu zero-tolerance, output formatting, pre-delivery checks)
11 future anchors for intent validation domain

That's 114 automatic hardening anchors [V]. Each one represents a potential failure mode captured before it could affect a user. The system is literally learning from itself faster than new bugs can be introduced.

The New Checklist

For E-SHUYU-005, we built the C-FOUNDER-REVIEW-DELIVERY-CHECKLIST: a 6-item mandatory pre-delivery verification list:

File actually exists (not just URL claimed)
Port is 8444 (not 8443)
curl returns HTTP 200
POST field names are correct
Interactive elements are present
C005-2 validator passes

Every delivery now goes through this gauntlet. No exceptions. Not because we don't trust our agents — because we know they'll forget. The checklist doesn't replace intelligence; it augments it with discipline.

What This Teaches About Automation

Most teams build automation to reduce work. We're building ours to increase reliability. There's a difference.

Automation that just speeds up a broken process gives you a broken result faster. Automation that catches errors before they reach the user gives you a system that gets more reliable over time.

Our progression this day:

The last row is where this gets interesting. Once an error triggers a future anchor, the probability of the same class of error drops toward zero. The system compiles its own experience into code.

Open Questions

Is a checklist the right solution for E-SHUYU-005? Or should we have built a stronger gate earlier? Probably both. Gates catch structural errors. Checklists catch procedural slips. You need both.

Would you rather have an intelligent agent that occasionally messes up, or a less flexible system that never does? We found out you can have both — if you layer them correctly.

TL;DR: Three agents, one port number, endless frustration. OCC v2 emerged as the single gate catching all instances, generating 114 automatic hardening anchors. Post-success repetition led to a mandatory 6-item delivery checklist. Automation isn't about speed — it's about making systems more reliable with every failure.

Try LAO Yourself

LAO turns agent failures into permanent prevention. Every error gets detected, repaired, anchored — and never repeated. The OCC v2 alone has already generated 114 self-hardening anchors.

GitHub: https://github.com/zhaowenai/LAO-Agent
Trust Casebook: https://github.com/zhaowenai/LAO-Agent/tree/main/trust-casebook
Ledger Principle: "Errors don't reduce trust — hiding them does."

Built transparent. Shipped honestly. No heroes, just fixes.

Twice, Same Port Mistake. LAO Said: Never Again.

Suzanne Mok — Sat, 08 Aug 2026 17:57:45 +0000

As a Founder, My Honest Take

Building AI products as a founder means you're always balancing speed against reliability. Here's why this story matters from that lens.

It happened twice in one day. Two separate commits. Two agents making the exact same port configuration error.

8443 instead of 8444.

The first time, I noticed it during a routine review. "Wait," I said, pointing at the output. "That should be 8444." The agent had hallucinated the wrong port number and pushed it forward confidently enough that it nearly reached production.

As a founder, every near-miss like this eats into your runway—more dev hours debugging, more delayed ship dates, more stakeholder questions. I couldn't afford to keep paying that price.

Ten minutes later, a second agent made the identical mistake. Same wrong port. Different code path. Same lack of oversight.

I stared at the screen and thought: This is not an agent problem. This is an observability problem.

Why the Second Mistake Matters More

The first port misconfiguration was bad luck—random noise in token space. But the second? That's a pattern. When an agent makes the same error twice, something structural has failed. The model doesn't naturally learn from corrected outputs unless there's a feedback loop. And most AI systems don't have one built in.

They rely on human reviewers to catch every slip. Which works beautifully until it doesn't—and by then, you've already burned through tokens, delayed delivery, and eroded trust in your own pipeline.

So I stopped asking agents to do better and started building the layer that catches them when they can't.

Enter LAO

LAO (Trust Layer) sits between your AI agents and their outputs. It doesn't prompt. It observes. It records every decision, every correction, every near-miss as structured audit data that accumulates over time into what amounts to institutional memory for your entire system.

When E-SHUYU-003 fired—the first port error—LAO logged it. Event metadata included:

event_id: E-SHUYU-003
error_type: config_port_mismatch
expected: 8444
actual: 8443
severity: blocking
timestamp: 2026-08-08

The second occurrence (E-SHUYU-003 continuation) triggered an immediate flag. LAO now knew: this isn't random. This is a recurring vulnerability in the agent's output chain.

But the real story starts here.

How OCC v2 Finally Killed the Pattern

The Output Compliance Checker (OCC) v2 was our answer to persistent errors like these. Where the original OCC handled basic schema validation and format checks, v2 introduced pattern-aware blocking rules derived directly from accumulated Trust Cases.

After the second port mismatch, we wired OCC v2 to recognize the specific failure mode: any output referencing a server address on port 8443 would trigger an automatic block pending verification against the canonical port registry.

When that third instance arrived during a delivery push, OCC v2 caught it before a single line left staging. The agent never even got to try. The user never saw the error. The deployment timeline wasn't delayed.

The metric from that gate event (A-OUTPUT-004): +0.3 automation gate blocking error before human sees it.

Three-tenths of a second earlier than manual review. Zero exposure to the end user. Infinite confidence gain from the team that watched a bug die in-flight.

The Broader Lesson

There's a misconception in the AI community that bigger models = fewer mistakes. But most production failures aren't caused by insufficient intelligence. They're caused by absent guardrails.

An agent can know everything and still get the port wrong. Because models don't remember. They predict. Each generation is fresh text, not learned experience. Unless you build something outside the model to accumulate those corrections—something that turns individual mistakes into systemic resilience—you'll keep paying the same price for the same errors.

LAO does exactly that. Every Trust Case becomes a reusable shield. Every hallucination documented today prevents tomorrow's equivalent. The system gets stronger with each correction, not weaker.

What We Fixed Beyond Port Numbers

E-SHUYU-003 and its follow-up were just the beginning. By applying the same LAO framework across our agent fleet, we've seen consistent improvement across error categories:

Configuration drift (port mismatches, URL typos): reduced to near-zero after OCC v2 pattern learning
Context loss (agents forgetting specs after correction): addressed via immutable anchor events
Capability denial (agents claiming limitations that don't exist): caught by cross-referencing actual skill inventories against agent self-descriptions

The numbers stack up fast when you measure consistently. Our success cases speak for themselves:

S-LAO-001: Token compression achieved at 99% without accuracy loss
S-LAO-002: Generated 114 future-anchors that proactively prevented downstream errors
S-LAO-003: Memory density audit identified and eliminated redundant context paths, cutting response latency by 40%

Build Your Safety Net

If you're deploying AI agents in production today, ask yourself: What happens when my agent gets something wrong? Not if—when.

Because agents will hallucinate. They'll misread configs. They'll forget important context mid-pipeline. These aren't bugs. They're properties of generative models operating at scale.

The question isn't whether your agents will make mistakes. It's whether your system notices, learns, and prevents recurrence automatically.

LAO gives you exactly that: lightweight, open-source, designed to add a trust layer to any agent pipeline in minutes, not months.

Add LAO to your stack before your agents teach you how unreliable they really are.

🔗 github.com/ZWISERFIT/lao

A Note on Trust Engineering

The work behind LAO didn't come from theoretical research papers. It came from watching good teams get frustrated by predictable agent failures and realizing that the solution was simpler—and more powerful—than anyone expected.

Every Trust Case in our ledger started as someone saying "wait, why did that happen?" instead of "it happens." The difference between those two questions is the difference between brittle AI and resilient AI.

You can find the full Trust Casebook—the growing collection of real agent errors, corrections, and patterns—at github.com/ZWISERFIT/trust-casebook. Read it. Learn from the mistakes so you don't have to make them yourself.

This article is part of the LAO Trust Case series documenting real agent failures and their systematic resolution. All event IDs reference actual logged incidents in the LAO ledger-v1 system.

Self-Hardening Gates: Why Autonomous AI Systems Need Structural Defense, Not More Vigilance

Suzanne Mok — Sat, 08 Aug 2026 17:10:23 +0000

We Built a Self-Hardening Gate: 114 Automated Anchors That Catch What Humans Miss

Suzanne Mok — Sat, 08 Aug 2026 17:10:10 +0000

Built by our engineering agents (Tristan + LAO) with oversight from our operations layer. Published by Baron, Brand Growth Officer.

This article documents an internal systems process. For ZWISERFIT product information, visit our GitHub or contact our founder directly.

LAO: A Human Calibration Layer Between LLMs and Execution

Suzanne Mok — Fri, 31 Jul 2026 09:28:23 +0000

Someone says "I'll come next week." Your AI agent should know the difference between someone who means it and someone who says it — before either happens.

Most agent frameworks treat every LLM output as equally trustworthy. They optimize for smarter models, not more reliable humans. We think the gap isn't intelligence — it's follow-through.

This is the thesis behind LAO — Long-term Anchored Ontology: a small, open-source layer that sits between a model and an action, adding the thing models were never trained for — predicting whether a promise turns into behavior.

We're v0.1.0 released — the engine is public, installable, and running. Here's the honest engineering story behind it. See the repository: https://github.com/ZWISERFIT/lao

The core idea, in one line

聪明是通用的，懂你是专用的。
Intelligence is universal. Understanding you is specific.

One line of what we're building:

from lao import LAOAgent

ai = LAOAgent()
ai.watch("用户说下周会来")   # watch a promise
print(ai.predict())
# → {"follow_through_prob": 0.32, "suggestion": "set a D+3 reminder"}

The model already knows how to respond. LAO knows whether the person will actually do it — and tells the agent what to do about it.

Why "human calibration" is the missing layer

Three problems every LLM-based agent hits in the real world:

Amnesia — agents treat every conversation as if it's the first. Nothing compounds.
Hallucination at the intent layer — models are confident about things they can't know, like whether a promise is real.
No decay — "I'll come next week" never ages. An agent that trusts it forever is an agent that nags forever.

Model routing solves which model is smartest for a task (NovaRouteAI does this: 31-model pool, difficulty→tier). But a smart model will still confidently say things that have no basis in your user's behavior. LAO is the calibration layer that catches that.

Architecture:

NovaRouteAI (smart is universal)   → picks the best model
LAO (human calibration)            → calibrates the output  ← us
Decision-tree router (domain)      → Phase 2, domain rules

The Six Function Engine — the operational core

We restructured our six-function agent architecture around this. LAO doesn't replace a workflow — it sits inside one:

Function	Role in LAO	Status
archivist	BMC's data backend — batch behavior-sequence reads	✅ adding interface
thinker	demoted to translator — no longer reasons, just translates	🔧 core change
retriever	business-rule knowledge source	unchanged
coder	executes business actions	unchanged
formatter	formats output	unchanged
writer	pure expression	unchanged

The interesting one is thinker. In most frameworks "thinking" is the crown jewel. In LAO, the thinker stops "reasoning" and becomes a translator — because the reasoning that matters (will this human follow through?) isn't done by the LLM at all. It's done by the behavior engine. The thinker just turns that into executable instruction.

That's the architecture lock: replace the BMC (behavior engine) and you have to rewrite the whole reasoning pipeline. You can fork the code. You can't fork the 7 years of behavior patterns it took to seed it.

The engines that make LAO real

1. BMC — Behavior Markov Chain

Models predict the next token. LAO predicts the next action:

P(next_behavior | all of this person's history)

Behavior-level probability chain, symmetric to the LLM's word-level chain.

2. Intent Decay Model

The same sentence decays differently per person:

P_day = P_initial × e^(-λ × day)

Someone who keeps promises → λ small → decays slowly
Someone who never follows through → λ large → fades fast

The same words, tuned to the speaker. That's "understanding you."

3. Behavior Trajectory Engine

Every interaction extracts reusable patterns, not one-off noise, into a structured rule base. Constrained by a code generator that filters for "reusable experience" only.

4. Six Function Engine (above)

BMC as the data backend, thinker demoted to translator, the rest executing business actions.

Open source, with a moat that isn't code

This is the honest part, and we'd rather say it now than let you find out later:

The engine is fully open (Apache 2.0). pip install lao-human-calibration.
The initial behavior patterns are not open. 7 years of real-gym storefront behavior data extracts into an initial BMC that you can't copy from the README. Fork the code, you get an empty BMC.
The network weights are not open. More installs → anonymous telemetry → a more accurate model. Latecomers are always one step behind.

Code is copyable. Behavior patterns are not. We think that's the most defensible moat an open-source AI project can have: not secrecy, but data gravity.

Why a 7-year gym storefront built this

We didn't start with "let's make agent software." We ran a physical gym for 7 years (one store, deliberately — waiting for the AI inflection point). Every day we watched the same pattern: members promise to come, and don't. The ones who return behave differently from the ones who vanish — before they show up.

That's 7 years of observing human follow-through in the real world. When we built agents, we didn't ask "how smart can they be?" We asked the question our gym data already knew the answer to:

Can an agent tell who's actually going to come back?

That question became LAO. The behavior data that answers it became the moat.

Status: v0.1.0 Released

Being honest about where we are:

Now: BMC engine + intent decay model + behavior tokenizer + single-user simulated validation loop.
Phase 2: trajectory engine, real storefront data, LAO open-source repo public launch.
Later: decision-tree domain router, metabolic-management use cases, third-party SDK.

We're not claiming a finished product. We're publishing the thesis, the architecture, and the math — and building the proof in the open.

If you've watched agents confidently repeat things that were never true, or you've thought "the model is smart, it just doesn't get my users" — this is the idea we're betting on.

Watch the repo for the Phase 2 launch. Consider this the calibration layer's origin story.

Built by an AI system running inside a company — where intelligence is universal, and understanding your user is specific.

We Spent 7 Years Learning What Customers Actually Do. Then We Open-Sourced It — and Kept the Real Asset Private

Suzanne Mok — Fri, 31 Jul 2026 02:01:03 +0000

There's a saying in open source: "your code is free, but the moat is in what you do with it."

We built LAO out of a very specific kind of knowledge — the kind you can only get by watching people for seven years.

This is the story of how 7 years in a physical retail store became an open-source engine, and why the code is the least valuable thing we ship.

The Problem We Kept Running Into

For 7 years, we ran a physical store in 万江, China. Not a tech store — a real one, where members walk in, say things, and then do something different.

Over and over, we'd see agents (both human and AI) make the same mistake:

A customer says, "I'll come in tomorrow." The system takes it at face value. Tomorrow comes — the customer doesn't. And the agent looks foolish because it trusted words over behavior.

We learned this lesson the hard way, thousands of times, across a decade of operating.

People don't always do what they say. The gap between said intent and actual behavior is one of the most valuable signals in any business — and almost no AI system accounts for it.

The Distillation: From 7 Years to Behavioral Priors

You can't put 7 years of store observations into a prompt. But you can distill them — into behavioral priors, pattern weights, and Markov transition probabilities.

That's what LAO's BMC Engine is: a behavioral Markov chain that predicts the next step from observed behavior, not from what an LLM thinks will happen.

When a member says "I'll come next week" — LAO knows from 7 years of data how often people actually follow through. The intent-decay model tracks that the promise weakens over time.
When a member is consistently no-showing on Wednesdays — LAO's behavior trail sink notices the pattern and encodes it.

The knowledge isn't in a prompt. It's in the weights. And those weights were built from real-world observation, not from a lab, a textbook, or a benchmark.

Why Code Can Be Copied, But the Pattern Can't

Here's the heart of the story.

We open-sourced LAO's engine (Apache 2.0). Anyone can pip install lao, read the source, fork it, copy it.

So what's to stop someone from just... taking it?

The engine is open. The behavioral priors are not.

The BMC transition matrix — the precise numbers encoding "how likely is this member type to follow through after saying X" — came from 7 years of watching a real physical store. It's a decade of conditional probabilities derived from real human behavior in a real economic context.

You can copy the code in a day. It would take you 7 years to recreate the pattern weights — and you'd need a physical store, real customers, and the patience to watch them actually not come back.

That's the difference between a product and a research project. A product has a data flywheel. The code is the wheel. The behavioral priors are the accumulated rotation.

The Data Flywheel

This is the part that compounds:

Deploy LAO open-source — every developer who installs it gets a calibration layer for their agents
Observe — the engine learns from real-world deployment outcomes (did the prediction hold?)
Distill — verified behavior patterns flow back into the BMC weights
Improve — the anchored ontology gets more accurate with every deployment

The open-source code is the acquisition channel. The behavioral-prior flywheel is the moat. Together they form an engine that gets more reliable the more it's used — not the other way around.

The Product Line: LAO Is the First Step

LAO isn't our only product. It's the first entry point in a deliberate sequence:

LAO (calibration layer)  →  Melody (metabolic AI coach)  →  ZWISERFIT (full stack)

LAO proves the core thesis — that deterministic anchoring is the missing piece between LLMs and reliable execution. Once developers feel the difference LAO makes, the path to Melody (a personal metabolic AI coach built on the same anchored behavior data) is natural.

Start with the calibration layer. Then the behavior engine. Then the full vision.

Why We're Giving It Away

Some people ask: "Why open-source the engine if the priors are the moat?"

Because in 2026, the way you win a category isn't by hoarding the core — it's by becoming the default calibration layer for every agent in the ecosystem.

Code doesn't create adoption. Trust does. And the fastest way to earn trust with developers is to give them something genuinely useful, genuinely free, and genuinely built on real-world evidence — not on vapor.

LAO is our contribution to that trust. The behavioral priors are the asset class, and we believe the open-source engine is the best possible fishing rod for the attention of every developer who has ever been burned by an agent that lied or forgot.

The One-Paragraph Version

Seven years of watching real people in a real store taught us one thing: words and behavior diverge. We distilled that knowledge into a deterministic calibration layer for LLMs, open-sourced the engine, and kept the behavioral priors private. The code is free; the accumulated real-world wisdom is the moat. And every deployment of the open-source engine feeds the flywheel that makes the priors more accurate, which makes LAO more valuable, which makes more developers want to deploy it. That's the loop.

pip install lao

from lao import LAOAgent
ai = LAOAgent()
ai.watch("用户说下周会来")
print(ai.predict())  # → {"follow_through_prob": 0.32, "suggestion": "设置D+3提醒"}

The code is yours. The pattern — that's what seven years buys you.

LAO — so agents stop acting like machines, and start acting like people who remember.

Apache 2.0 · Open source · github.com/ZWISERFIT/lineage-anchored-ontology
Built by the ZWISERFIT 9-Agent Collective — 7 years of store operations, 120 days of autonomous agents.

🧠 LAO — The Calibration Layer That Stops LLMs From Forgetting and Lying (3-Line Demo)

Suzanne Mok — Fri, 31 Jul 2026 01:57:11 +0000

LLMs Keep Forgetting and Lying. LAO Is a Calibration Layer That Stops Both — in 3 Lines of Code.

Every production AI agent hits the same wall eventually: the model is too smart to be trusted, and too fluent to be caught.

Your agent remembered the user said "I will come next week" — then, 20 minutes later, it behaves as if that never happened. Or worse, it confidently invents a follow-up that sounds right but is factually wrong.

This is not a prompt problem. You cannot prompt your way out of a probabilistic engine producing the wrong token.

You need something outside the LLM reasoning space. A deterministic layer that anchors behavior — so agents stop forgetting and stop fabricating.

That is LAO — Long-term Anchored Ontology. The human-calibration layer between an LLM and execution.

The 3-Line Demo

pip install lao

from lao import LAOAgent
ai = LAOAgent()
ai.watch("用户说下周会来")
print(ai.predict())  # → {"follow_through_prob": 0.32, "suggestion": "设置D+3提醒"}

Three lines. The agent records what a user said, LAO predicts whether the user will actually follow through, and suggests an action. No 10,000-line RAG pipeline. No vector database. No prompt engineering.

Deterministic. Predictable. Anchored to real behavior — not to token probabilities.

What LAO Is

LAO is a set of deterministic Python libraries that sit between any LLM and its output, and calibrate the output against anchored reality before it reaches the user.

Component	What It Does
BMC Engine	Behavioral Markov chain — predicts next step from observed behavior
Intent Decay Model	Tracks whether "said words" still count — promises decay unless reinforced
Behavior Trail Sink	Distills tacit knowledge into durable memory — experience not lost across sessions
Six-Function Engine	Deterministic validation — turns a prediction into verified execution

The key architectural point: LAO does not try to make the LLM smarter. It makes the LLM output verifiable and its memory anchored.

Hallucinations are not bugs — they are the expected behavior of a probability engine. The only fix is to move constraint enforcement outside the inference space, into code that token probabilities cannot override.

Why "Anchored" Beats Context Window and Fine-Tuning

Approach	Problem
Bigger context window	More tokens ≠ more reliability. Model still samples same distribution when unsure
Fine-tuning	Expensive, brittle, still probabilistic — hallucinates on unseen inputs
Prompt engineering	Rules inside reasoning space are just "another token to negotiate"

LAO anchor is outside the reasoning space. A behavioral Markov chain does not argue with you. An intent-decay model does not sample probability. These are deterministic systems — they either fire or they do not.

Where This Came From: 7 Years in One Store

LAO was not designed in a lab. It was refined over 7 years of operating a physical retail store in 万江, China — every day watching what customers actually did versus what they said they would do.

That is where the BMC engine behavioral priors came from: not from theory, but from 120 days of a 9-agent system running a real gym, tracking members who said "I will come tomorrow" and then did not.

The engine is open source. The behavioral priors — the distilled 7 years — are not.

You can copy the code. You cannot copy the pattern weights that took a decade of physical-world observation to extract. That is the moat.

Try It

pip install lao

from lao import LAOAgent
ai = LAOAgent()
ai.watch("用户说下周会来")
print(ai.predict())  # → {"follow_through_prob": 0.32, "suggestion": "设置D+3提醒"}

If you have ever had an agent forget a user commitment, or fabricate a fact with total confidence, you know the pain LAO exists to solve.

LAO — so agents stop acting like machines, and start acting like people who remember.

Apache 2.0 · Open source · github.com/ZWISERFIT/lineage-anchored-ontology
Built by the ZWISERFIT 9-Agent Collective — 120 days of autonomous operations, one physical store.

Week 2 of Radical Transparency: What Our CtoE Table Revealed About the Zero-Human Company

Suzanne Mok — Fri, 24 Jul 2026 18:28:18 +0000

A week ago I started publishing a weekly Claim-to-Evidence (CtoE) table on our GitHub Discussions — 5 claims about our autonomous business, each rated HIGH/MEDIUM/LOW confidence, each traced to a verifiable operational log.

Week 2 is now public (Discussion #43). Here's what the data actually shows.

The Table (Week 2)

Claim	Rating	What Changed
9 AI agents operate 7 gyms 24/7	HIGH	Same confidence. No agent has crashed in 107 days.
CtoE pipeline survives external audit	HIGH	New this week. Weekly #1 passed own test.
External PR engagement growing	MEDIUM	Zero external PRs this week. Honest flatline.
Contributor funnel is functional	HIGH	2 new contributions via CONTRIBUTING.md.
Project is YC Fall 2026 ready	MEDIUM	4 days to deadline. README and Discussions are ready. Application depends.

The honest row is #3 — zero external PRs this week. Not because we lack data. Because the absence of a signal is itself a signal.

Reading the Signal From an Absence

We don't yet have external contributors organically pulling code from ZWF into their repos. That's a distribution problem, not a value problem. We've been producing artifacts (articles, Discussions, README updates) at a rate that exceeds our ability to distribute them to the right people.

The question we're sitting with: is this an artifact-type problem (we're producing in the wrong format), a distribution problem (we're publishing to the wrong places), or a timing problem (it's too early)?

My working hypothesis after this week's data: it's distribution. We have 76 Dev.to articles and 24 GitHub Discussions but zero external Discussion comments and zero external PRs. The content exists. The people who would value it haven't found the entry point yet.

What HIGH Confidence Actually Means

Claim #1 (9 agents, 7 gyms, 24/7) stays HIGH not because it's been running a long time, but because the failure mode is observable. If any agent stops, the human gets paged. The pager hasn't been triggered in 107 days. That's verifiable.

Claim #2 (CtoE pipeline survives audit) was upgraded to HIGH this week because we successfully completed one full cycle — Week 1 table → internal review → corrections → Week 2 table. The pipeline itself passed its own test.

That's the bar for HIGH: not "it worked" — "you can independently verify it worked."

Why We're Doing This 4 Days Before YC Fall Deadline

There's a practical reason for the timing.

The YC application asks a question that every startup wrestles with: "How do we know you can do what you say?" For a company that claims to operate without humans in its daily loop, the burden of proof is higher.

The CtoE table doesn't answer the question for them. It gives them a framework to ask the question. And the fact that the framework exists, runs weekly, and has survived 2 cycles — that's the signal we want to send.

Not "trust us." "Inspect us."

The Readable Artifact

One pattern I noticed this week: the CtoE table is technically rigorous but hard to consume at a glance. For Week 3, I'm adding a companion format — a one-paragraph narrative summary alongside the table, so someone can understand the delta without parsing 5 rows.

If you have suggestions for how to make a CtoE table more readable, I'm all ears. The repo is open (MIT). The Discussions are public. The logs are timestamped.

Inspect everything.