A demo becomes an operating system when three things stop depending on the person who built it: the workflow is written down in units anyone can check, the evidence for each claim is recorded next to the claim, and one named owner can run the next test without asking you. Until then you have a demonstration, not an operation. The practical move is not a bigger build — it is a shorter loop: write the current workflow in minutes, mark what is unknown, pick one bounded test, and only then decide whether to automate anything.

Three public exhibits show what each part of that loop looks like as an actual working page, and what each one explicitly refuses to claim.

Exhibit one: measure the workflow, not the tool

Handoff is a workflow mapping desk: you record, per stage, how many minutes someone actively works and how many minutes the item waits for the next stage, across two to eight stages. It returns totals, a wait share, the largest wait with ties named, a text table and a downloadable Markdown plan. Nothing is uploaded or saved, and the page states that no AI model stands between you and the arithmetic.

That last detail is the point worth copying. A demo usually measures the exciting part — the model, the extraction, the automation. An operating routine needs the boring part measured first: where does the item sit, and for how long. The Handoff page carries an invoice example with 13 work minutes and 4,780 wait minutes, waiting about 99.7% of elapsed time. It labels those figures as invented to illustrate the idea, not measured, and not a result of any engagement. Treat it exactly that way. Hypothetical illustration, not a benchmark and not a saving.

The page also states that naming the largest wait identifies a candidate for a small test, not a measured saving. Keep that sentence when you write your own. It is what separates an operating plan from a pitch.

Exhibit two: separate the claim from the fixture

The agent memory reference is a runnable, MIT-licensed implementation of store, retrieve, provenance and consolidate operations. Store is described as an append-only ledger with explicit event IDs and timestamps; retrieve queries with BM25 or a tag-based scorer returning ranked scored results; provenance carries source, event ID and insertion time per item; consolidate is a merge-or-summarise pass described as deterministic for a given input.

The page reports observed fixture metrics on a synthetic corpus of 16 entries, 5 queries, seed 7, k=5, with two independent runs producing identical aggregate rows: BM25 mean recall@k 0.90, mean precision@k 0.28, MRR 1.00; tag scorer mean recall@k 1.00, mean precision@k 0.32, MRR 1.00. It then says, in the same breath, that these are observed numbers on a tiny fixture, not a benchmark, that full JSON output differs between runs for an undiagnosed reason, and that no bit-reproducibility, Python 3.9 compatibility or external performance guarantee is claimed.

This is the pattern to imitate in an operating system: every number carries its fixture size and its unknown. A demo that reports 1.00 MRR without the corpus size is not lying necessarily, but it is unusable — nobody downstream can tell what would change the result. Copy the qualifier along with the number.

Exhibit three: keep the arithmetic inspectable

The 13 Labs worksheet takes 3–200 finite numbers and compares mean and median with and without one identified outlier removed, optionally resampling sample means with replacement (sample size 2–100, not more than the dataset length; 50–500 repeats; a whole-number seed that reproduces the same sample plot for the same seed and settings). Entries are not uploaded or stored.

The page's own limits are the interesting part: outputs are illustrative and generated from the numbers you type, carry no significance claims, p-values or predictions, and removing an outlier is a judgment call offered so you can see the effect, not as a recommendation. In operation terms, that is a system that tells you what it cannot tell you — the cheapest form of trust you can build.

The move: from demo to routine

A compact sequence, each step producing an artifact you can hand to someone else:

  1. Write the workflow in minutes. Stages, work minutes, wait minutes, owner role per stage. If you cannot name the owner, that is the first unknown.
  2. Name the largest wait. Not the most annoying step — the one your own notes say holds the most elapsed time. Ties named.
  3. State what the demo does and does not do. Input ranges, what is stored, what is uploaded, what is claimed. If entries are not uploaded, say so; if a result differs between runs, say that too.
  4. Attach a fixture to every number. Corpus size, seed, query count, run count, and the explicit unknown.
  5. Assign an owner and a trigger. Who runs the next test, on what date, with what evidence recorded.
  6. Scope one bounded pilot around the largest wait, and define in advance what evidence would tell you to stop.

Two related guides take the middle steps further: define evidence before building handles the fixture-and-claim discipline, and design the human handoff handles owners, triggers and the moment a person must be asked to decide.

Practical limits

None of the three exhibits is an operating system in itself, and none of the pages claims to be. The agent memory reference says plainly it is intentionally small, not production-grade, and not a claim of proprietary benchmark results. The Handoff figures are invented. The 13 Labs worksheet makes no inferential claims and no predictions. That is not a weakness of the demonstration; it is the correct scope statement for something you are about to adapt.

What the exhibits do give you is a shareable vocabulary: work minutes, wait minutes, seed, fixture, unknown, owner. Once a demo speaks that vocabulary, review becomes possible — a colleague can check a claim against its stated fixture instead of trusting a screenshot.

What remains unknown

For your own project, the unknowns are the work. Which stages exist, whose minutes they are, which numbers are invented, which claim has no fixture behind it, and who owns the next test. Write them into the plan rather than around it. To turn a specific project into a structured statement — goal, current workflow, constraints, evidence needed, owner, next test, with the unknowns kept visible — use the implementation brief builder. It produces a Markdown brief you can download and reset; nothing is stored.

A demo that works is a beginning. A demo whose limits are written down, whose numbers carry their fixtures, and whose next test has an owner is the thing you can actually run.