Demo or production: the opening round, two depths, one upgrade path

Every page in this room was written for a worker that runs a real business every day. Most first builds are not that. They are a demo: a person wants to see the worker do the job on invented data, show it to someone, and decide whether it earns the full build. Running a demo through the full build costs the person most of a day and a large share of their model budget, and hands them something only an engineer can open. This page is how the record tells the two apart before any work starts, and how a demo grows into the real thing without being thrown away.

What a test build showed

A mortgage follow-up worker was built from this record and the skill on invented pilot data, from a production-grade brief. The coding agent did everything the record asked: maps, gates, a spec, 69 tests, 96 offline eval checks, a container, a live address. The owner's review named three problems, none of them a missing rule: the build took far too long, it used more than half of the owner's model allowance on one project, and what was handed over was an API behind a token that the owner could only test from a terminal, with an API documentation page that could not even send the token. ¹ A second lesson came from the model: the brief named one provider, the owner switched to a free tier of another at the end, and the switch cost a second round of work and a model that was not available to new accounts. ¹

So the depth and the model are decided first, together, and the build is sized to the answer.

The opening round

Before the work is read, the coding agent sends one message with every blank it can propose, each answer already filled in from the person's own words, so the person corrects only what is wrong. The rules of the interview still hold: nothing is skipped, and every question offers three answers, the third in the person's own words. What changes is that the first answer is pre-selected and marked as the assumption.

Before I start, here is what I am assuming. Change any line that is wrong;
anything you leave stands.

1. Depth: a demo on sample data (assumed), or a production worker for daily
   use, or something else, in your own words.
2. Model: [the provider whose key you have] (assumed), or OpenAI, Gemini,
   Anthropic (Claude) or Grok, or another, in your own words.
   Free or paid: [free tier] (assumed) or paid, or in your own words.
3. What it gives back, for whom, how often: [proposed from your words].
4. Three example runs, PROPOSED until you confirm them: [one line each].
5. Who says yes before anything leaves the worker: [you] (assumed), or
   [a named role], or in your own words.
6. The data: invented sample data (assumed), or real data, or in your own
   words.

The coding agent asks only what it cannot propose. Which system holds the data, a path and a key stay placeholders until the deploy step, as understand the work says.

Two answers are never assumed silently:

• The model. The provider's key goes in .env, placed by the person, and the model id is listed from the provider before it is written into code, never guessed. How each provider is wired under the same SDK is on use another model.
• Real data on a free tier. Some free tiers allow the provider to use the content sent to it to improve its products. If the person chooses real data and a free tier, the coding agent says so in one sentence and asks again before any real record is sent. Invented data has no such question.

Two depths, step by step

The ten steps are the same; the depth decides how much each one produces. A demo is the default.

Both depths end the same way: one page with a chat box, an upload and a Run button, behind a password, handed over in plain words. That page is on the worker's page, and it is not optional at either depth.

The budget a demo keeps to

A demo is sized so it finishes in one working session:

• Questions: the opening round, then one round of corrections at most, then the approval word.
• Tests: what proves the confirmed runs and the page rules, not a suite for every edge.
• Live model calls while testing: a fixed number written in progress.md before the first call (twenty is a sensible ceiling on a free tier), offline and scripted tests first, and one live check per behaviour rather than one per case. A demo that runs out of quota stops and says so; it never switches to a paid model on its own.

Production

Production is the full room, every step at the depth its page describes, with the same page as the surface. Choose it when the worker will run real work every day, when someone other than its owner depends on it, or when real personal data goes in. The book's warning applies: a durable worker runs on the API, where every model call is metered and paid for. ²

From demo to production, without starting again

A demo is built in the same folders, with the same files, as a production worker; it is the same worker with steps left shallow. The upgrade is the missing depth, step by step, never a rebuild:

1. Change Depth: demo to Depth: production in progress.md, with the date and the person's words.
2. Change the spec first, as the spec page says for every change; interview what the opening round only proposed. ³
3. Write the full governance record; real data waits until it passes.
4. Widen the tests to one per acceptance criterion; run the eval steps the demo skipped.
5. Move what the demo kept in memory into storage: the daily chat count, the uploaded files and the audit lines (give it a record).
6. Replace the single password with a sign-in per person when more than one person uses it.
7. Run the five-stage checklist on the end-to-end page and hand over again.