The improvement loop

Most AI features ship on vibes. Someone writes a prompt, it looks good in a demo, it goes to production, and nobody finds out it regressed until a customer does. ZeroWidth is built around the opposite stance: an AI feature is done when you can prove it keeps working. The core tools are one loop that makes that practical — and Ledger records whether each pass's call was right.

   ┌──────────────────────────────────────────────────┐
   │                                                    │
   ▼                                                    │
Compass  ──find──▶  Workbench  ──build──▶  Caliper  ──prove──┘
 (what's worth      (the behavior,          (does it
  trying)            as a flow)              hold up?)

• Compass maps how your team actually works — the workflows, the people who hold the knowledge, the systems, the friction — including the tacit expertise that never made it into a doc. Out of that map come the opportunities: the specific experiments worth trying.
• Workbench is where you turn an opportunity into a running behavior: a flow you can call from your code.
• Caliper is the receipt. It scores that flow against a rubric on a dataset you trust — on every change, in CI. A regression surfaces as a failing number before a customer files a support ticket.

Each tool stands on its own. The leverage is in the loop: every measurement Caliper produces is evidence Compass can point back at, and every gap Caliper exposes is the next thing Workbench builds.

Walk it once

Picture a support team that's outgrown its own process. Tickets pour in, and a handful of senior agents know exactly how to route them — billing here, account problems there, the genuinely urgent ones to the front of the line. But that judgment lives in their heads. New hires take months to absorb it, and on a bad week the urgent tickets get buried under the routine. You suspect AI could help. "Add AI to support" is not yet a plan.

Here's that problem moving through all three tools.

1. 1
   Compass — surface the real opportunity

   You start by mapping the work, because the right thing to build isn't obvious until the work is legible.

   In Compass you create a Ticket triage workflow page and connect what surrounds it: the people who own it (your senior agents), the systems it runs through (the helpdesk, the billing database), and the pain points it leaks (slow new-hire ramp, urgent tickets buried). The map starts to show the shape of the problem instead of a vague sense that support is "a mess."

   The part that matters most lives outside every system: the tacit knowledge in your best agent's head — the dozen unwritten rules they apply to decide what's urgent and where each ticket goes. So you send them a stakeholder interview link. No account needed; they just talk through how they actually decide, and that conversation becomes a Document page wired into the workflow. The unwritten rules are now written down and connected to the work they govern.

   Only now does the opportunity stop being a guess: "auto-classify inbound tickets by queue and urgency, applying the rules the senior agents actually use." It's specific, grounded in the real workflow, and you already know what "good" looks like — because you just captured it. That's the difference between mapping the work and brainstorming a backlog: the opportunity falls out of the map.

2. 2
   Workbench — build the behavior

   Now the brief is concrete, so Workbench has something real to build. You make a classifier flow — ticket text in, one of {billing, technical, account, urgent} out — and the urgency signal encodes the rules the interview surfaced. You test it on the canvas, then publish a version so production pins to a frozen snapshot instead of your live draft. The flow's behavior is the contract; you can swap the model underneath later without touching the integration.

   Wire it into your ticketing system with one call (run a flow):

   curl -X POST https://api.zerowidth.ai/1.0/flows/$ZW_FLOW/runs \
     -H "Authorization: Bearer $ZW_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"input":{"kind":"form","values":{"data":"Card declined twice, charged anyway"}},
          "source":{"kind":"published"}}'
   # → { "outputs": { "data": "billing" }, ... }

3. 3
   Caliper — prove it holds up

   A classifier that's right in the demo and wrong on the long tail is worse than no classifier. In Caliper you build a dataset of real tickets the senior agents labeled, write a rubric that encodes the judgment Compass captured, and create an eval that scores your flow against it. So Caliper checks the flow against the same human expertise the whole project came from. Run it in CI on every prompt change and a regression becomes a failing score on a pull request, before it ships. This is the score-a-model-in-CI recipe.

4. 4
   Back to Compass — close the loop

   Caliper shows the classifier nails billing and technical but confuses account and urgent — exactly the call the senior agents said was hardest. That gap is the next opportunity: a sharper urgency signal, maybe its own short interview to pull more of the rule out. It lands back in Compass as the thing to build next, and the loop turns.

Why a loop, not a checklist

AI behavior drifts. Models get deprecated, prompts get "improved," an upstream change shifts the input distribution, and a feature that scored 0.92 last quarter quietly slips to 0.74. A checklist catches that once, at launch. A loop catches it every time the number moves — which is the only cadence that matches how fast the underlying models change.

Start anywhere

You don't have to adopt the whole loop on day one. Each tool earns its keep alone, and you can enter wherever the pain is.