You fix the case they complained about, and break another.

The model is rarely the hard part. Getting everyone around it to agree is.

Anyone can call a model. Shipping an AI feature people trust means working out what it should do with the people who know the work, and keeping it right as they, your users and the models change.

• What "good" looks like isn't written down

  Success lives in the heads of the people who know the work. Until it becomes examples and a rubric, everyone is guessing, the model included.

• The experience decides more than the prompt

  How someone asks, reads and corrects an answer shapes what the model has to do, so designers belong in it from the start.

• The knowledge is scattered

  The answers live in documents, tickets and people's memories. An AI can only be as good as what it can reach.

• A wrong answer doesn't say which step produced it

  Once there are tool calls and sub-agents in the path, the reasoning can go astray anywhere along it. Without a record of what each step received and returned, changing the right one is guesswork.

• The real feedback arrives after launch

  Real users find the cases nobody listed. Without a way to catch what they say, it stays in a chat thread.

• The models keep changing

  A better model arrives every few months. Without evals you can't tell whether switching helps or quietly breaks something.

the loop

So we built the tools around those problems, and the code comes last

You write code in one of these four steps. The other three are how your team decides what it should do, and finds out whether it worked.

1. 01

   Workbench

   Design it with the people who know the work

   Designers, subject experts and stakeholders shape the flow with you on a canvas, answering from your own documents, and try it the way users will. Their feedback lands on the flow itself and becomes tests, instead of a spec you translate into prompts.

   How Workbench works→
   
2. 02

   Caliper

   Agree on what good looks like, then check it on every pull request

   The experts' examples and rubric become a dataset in Caliper, so everyone is working from the same written-down definition of good. Caliper scores every pull request and every new model you try against it, and the build fails when the score drops.

   Evals in CI→
   .github/workflows/eval.yml

   - name: Score the bot  env:    ZEROWIDTH_API_KEY: ${{ secrets.ZEROWIDTH_API_KEY }}    ZEROWIDTH_EVAL_ID: ${{ secrets.ZEROWIDTH_EVAL_ID }}  run: node eval.mjs --threshold 0.8

   
3. 03

   Workbench

   Ship it from your code

   Call the flow over the API with a workspace key, and pin the exact version you tested. Or export it and run it inside your own process with the SDK, on the same engine.

   The run API→
   Node.jscURLPython

   run.mjs

   const res = await fetch(  `https://api.zerowidth.ai/1.0/flows/${process.env.FLOW_UUID}/runs`,  {    method: "POST",    headers: {      Authorization: `Bearer ${process.env.ZEROWIDTH_API_KEY}`,      "Content-Type": "application/json",    },    body: JSON.stringify({      input: { kind: "chat", messages: [{ role: "user", content: "Hello" }] },      source: { kind: "published", version: "1.0.0" },    }),  },)const { outputs } = await res.json()

4. 04

   Ledger

   Measure what it changed, and keep learning

   Send Ledger the numbers the change was meant to move, and it settles each expectation against them. The cases real users hit go back into the flow and its tests, so the next version starts from what you learned.

   Ledger metrics→
   Node.jscURLPython

   metrics.ts

   import { createLedgerClient } from "@zerowidth/ledger-sdk"const ledger = createLedgerClient({  apiKey: process.env.ZEROWIDTH_API_KEY,})ledger.event("ticket_auto_resolved")      // one happenedledger.measure("triage_time_minutes", 4.2) // a level you observed

   

The work your team does in the tools, your code can do over HTTP

A key carries only the permissions you give it, one product at a time. The full reference, with request and response shapes, is in the docs.