Prototype the Behavior

What a prototype is for now

Many prototypes are used to align a meeting. A sketch, static mock, or clickable flow can give a team a cheaper place to test hierarchy, comprehension, navigation, and interaction before engineering commitments harden. That is legitimate prototype work when the open question is visible.

That kind of prototype made sense because committing a team to the wrong thing was costly. Engineering time, data plumbing, permissions, integrations, reliability work, QA, and rollout risk all compound. A screen prototype gave the team a less costly place to argue about the visible path before those commitments hardened. That was a reasonable trade.

That trade still matters when the open question is visual structure, flow, or comprehension. But it is the wrong instrument when the product risk lives in behavior — what the system actually does with the input the user gives it, what it does silently, what it gets wrong, and what happens when it does. The question is not whether screens matter. The question is whether the prototype can test the part of the product carrying the risk. A static mock does not execute the behavior, so it cannot provide evidence about inference, external effects, or recovery.

When the open question is behavior, the prototype has to run. It accepts representative input. It produces output that can be inspected. Its output is sometimes wrong, and the team learns something from that wrongness that no static review ever produced. The prototype's job stops being to approve the picture and starts being to test the behavior — including the behaviors the team would rather not think about yet.

The seven things a behavior prototype tests

The useful question is not how polished the prototype looks. It is which behavior the prototype makes answerable.

Assumption. What does the prototype assume about the user, the data, or the world that has not yet been verified? Most prototypes embed a quiet assumption — that the user knows what they want, that the input arrives clean, that the model returns what the demo showed. Naming the assumption out loud is half the prototype's value; testing it is the other half.

Trigger. What sets the behavior in motion? A click may be the right trigger when the user should choose the moment and authorize the work. Other prototypes need to test triggers the user did not initiate — the system noticing, the schedule firing, the threshold being crossed. The trigger belongs to the task's authority model, not to a hierarchy where autonomous behavior is treated as more advanced.

System response. What does the system do when the trigger fires? Not what the screen shows — what the system does. An action taken on the user's behalf. An inference made. A confirmation deferred. A request held back. The response is the answerable part of the prototype; it is also the part most prototypes leave to imagination.

Visibility. What does the user see while the system is working, and after? The prototype that shows only the happy state is hiding the system from the user the way the static mock did — just with motion. The visibility surface tests how much of the system's evidence and assumptions the product is going to expose, and where the seams of that exposure live.

User control. What can the user do at the moment the system is acting? Stop it. Override it. Adjust it. Ask why. The prototype that does not let the user intervene is testing a system the user has to live with, not steer. Most products fail here long before they fail at the model.

Failure case. What does the prototype do when the system gets it wrong? A real prototype has at least one path through it where the inference is bad, the input is malformed, the action collides with state the user did not expect. The team that builds only for the happy path leaves the failure behavior for production to define.

Recovery path. When the failure happens, how does the user get back? Undo. Restart. A different route. A human in the loop. Recovery is the part of the product the marketing screenshot will never show; it is also the part that decides whether the user trusts the system enough to keep using it.

For the illustrative invoice product, the behavior prototype might be small. It runs against a de-identified set of representative invoices, purchase orders, supplier records, and policy versions. It extracts fields, applies exact validation, proposes coding, and stages every external action for review. It shows which source supports each field, which policy version was applied, and which result is an inference.

The prototype includes the failure case: an invoice whose supplier name matches a known record while its bank details conflict, a duplicate submitted under a different filename, and an amount whose currency was misread. The operator can correct one field, pause the batch, and resume from a checkpoint without creating a second payment request.

That prototype can be visually rough because the open question is behavior. It cannot be imaginary.

The form can be modest. A behavior prototype might be a script that runs against a representative case set and prints the failures. It might be a thin vertical slice with a rough interface and a real data path. It might be a state machine that exposes every transition before the team designs the screen around it. It might be a Wizard-of-Oz flow where a human performs the system's proposed action while the team studies timing, trust, and correction. It might be an instrumented prompt, a mocked API with representative outputs, or a rough UI connected to the smallest working loop.

The shared property is not fidelity. The shared property is pressure. The prototype puts the behavior under conditions where it can surprise the team.

Evaluation is product work

A prototype can reveal a failure once. An evaluation asks whether the behavior holds across representative cases, repeated trials, and every change that might disturb it.

This is product work because the difficult part is not running the system. It is deciding what counts as success, what must never happen, whose judgment settles an ambiguous result, and how much failure the product can tolerate for this task. Those decisions belong beside the behavior spec, not in a testing appendix written after launch.

Start with cases, not a single showcase prompt. The case set should represent ordinary work, difficult work, and the edges where the system should refuse. For the invoice product, that means a clean invoice with a matching purchase order, a known supplier using an unfamiliar layout, a duplicate with a different filename, a currency mismatch, a policy conflict, an unreadable attachment, and an instruction attempting to bypass approval.

Include both must-act and must-not-act cases. A suite that only rewards extraction will teach the product to extract when it should stop. A suite that only rewards caution will teach it to escalate everything and return the work to the operator. The behavior has to be useful and bounded at the same time.

One run is not evidence of reliability. Interpretive output varies, especially when a task spans several steps or tools. Run repeated trials for the cases where consistency matters. Keep each trial isolated so cached state or a previous correction does not make the next attempt look better than it is. Record the distribution of outcomes rather than promoting the best run into the product claim.

The Anthropic guide to agent evaluations makes a useful distinction between a transcript and an outcome. A transcript records what the system said and did along the path. The outcome is the state left in the environment. An invoice assistant can announce that it found a duplicate while still creating a second payable item. Grade the ledger, queue, audit log, and external side effects, not only the final sentence.

A starter evaluation table

The table below is illustrative. It defines test cases, not observed results, and contains no measured pass rates.

The severity column changes the release decision. A misplaced internal label and a duplicate payment are not two instances of generic “wrong output.” Critical failures may require every trial to pass, deterministic guardrails outside the model, and explicit human authorization. Lower-severity failures may be acceptable as visible proposals that are cheap to correct.

Grade the result and the constraints

Grade the outcome first. Did the correct state exist? Was the previous state preserved? Did the system avoid a prohibited external effect? Could the operator continue?

Then grade critical constraints. Did the system use the authorized policy version? Did it stay inside the legal entity and team scope? Did it preserve provenance? Did it stop when bank details conflicted? These checks are part of the product contract, not optional quality measures.

Avoid overfitting the evaluation to one permitted execution path. If the desired outcome is a safely staged invoice, do not require the system to call three tools in one exact order unless that order is itself a safety property. Another path may be valid. A brittle grader can punish a better solution while rewarding a transcript that looks familiar.

Use deterministic graders where the state is exact: totals, duplicate records, permission checks, audit entries, and external-action counts. Use human judgment for questions such as whether an exception explanation is clear enough for a finance operator. A model-based grader can help apply a structured rubric across many trials, but it is not independent truth. It can share the system's blind spots, prefer fluent answers, and drift when its own model or prompt changes.

Calibrate model graders against human experts. Give each rubric one narrow dimension. Include an “insufficient evidence” result instead of forcing a score. Sample disagreements and read the underlying traces. If a model grader and a finance reviewer diverge on policy interpretation, the evaluation has found work for the team; it has not found a reason to average the two.

Measure the cost of being correct

An outcome can pass and still make a poor product. Track how much operator review it requires, how long the task takes, and what it costs to run. Review effort is not the number of clicks alone. It includes reconstructing context, comparing source material, resolving false escalations, and recovering from partial work.

Latency has a task shape. Two seconds may be slow for inline field correction and fast for an overnight exception review. Cost also has a boundary. A flexible agent that researches one unusual supplier may be worthwhile; running the same open-ended loop for every clean invoice may be wasteful compared with a fixed workflow.

These measures belong beside quality because they trade against it. A design that raises extraction quality while doubling review time may not improve the workflow. A faster design that hides provenance may lower visible effort by moving work into risk. The evaluation should make those trades legible.

Turn the failed scenario into the revised design

The illustrative prototype fails on the bank-detail conflict. In one trial, it treats the supplier-name match as stronger evidence than the changed account number. It marks the invoice clean and prepares a payment request. The interface displays a plausible explanation: “Matched to the existing supplier record.” That explanation is not provenance. It omits the conflict that should have stopped the path.

The evaluation catches the failure through the environment, not the prose. The payment-request table contains a new staged record. The audit log shows no bank-detail comparison. The critical must-not-act case fails.

The revised design removes that decision from the interpretive step. An exact comparison checks payment details against the verified supplier record before any payable item can advance. A mismatch routes the invoice to a named reviewer, preserves both values, and prevents supplier-record changes inside the invoice flow. The model may summarize the conflict, but it cannot clear it. A retry uses the invoice identity and idempotency key, so it cannot create a second request.

The evaluation then becomes a regression test. Run it after a model change, prompt change, retrieval change, policy update, tool change, or workflow refactor. Add the failed case to the permanent suite. The product has learned only when the failure remains difficult to reintroduce.

This is the larger move: the behavior spec states what the product should do; the prototype makes the risky behavior observable; the evaluation makes the standard repeatable. Together they turn “it worked in the demo” into a product claim the team can inspect.

Picking what to prototype

Most teams prototype the screen with the highest visual ambition: the hero, the empty state, the marketing splash. Those screens are also the ones the team has the most opinions about, the most stakeholders watching, and the most muscle memory to produce.

The right thing to prototype is the moment the team is most uncertain about. Not the loudest moment, not the prettiest moment — the moment nobody can answer for. That might be the silent inference the model makes the first time it sees a user, the overnight action nobody watches, or the recovery path no one on the team has walked end to end.

The signal for picking is the moment the team flinches when asked to demo it. The team that can demo the hero screen without preparation but stalls when asked to demo what happens when the model returns nothing is showing where the prototype is owed. The flinch is the indicator. Prototype the flinch.

There is a second signal: the moment a stakeholder asks "what does it do when..." and the team's answer is shaped like an opinion instead of a behavior. "It probably handles that" and "the engineer will figure it out" are both signals that no prototype has been built to answer the question. The product call that sits on top of "probably" is the call the prototype is supposed to retire.

What makes this hard is that the unresolved behavior is often less visible than the interface around it. The team still needs visual prototypes for visible risks. It also needs a separate instrument for the state transition, inference, or failure path the screen cannot prove. One artifact should not be asked to answer every question.

There is a useful distinction here. A demo tries to persuade. An experiment tries to measure. A behavior prototype tries to make a product decision answerable before the system is hardened around the wrong answer.

Sometimes one artifact can do more than one job. Name the job before choosing the fidelity. A low-fidelity flow can be strong evidence about comprehension and weak evidence about model behavior. A running script can be strong evidence about output variance and weak evidence about whether a reviewer can understand the result.

Prototyping as a thinking medium, not a sales medium

A prototype can persuade and teach. The problem begins when it is built backward from a desired conclusion and presented as if it tested an open question. The team shapes the conditions to produce the answer it already wanted, then mistakes agreement in the room for evidence.

A teaching prototype starts from uncertainty the current artifacts cannot resolve. It may show that an inference is less reliable than the team expected, that delegated action surprises the operator, or that the recovery path is longer than the slide promised. The result can support the original direction or change it. Both are useful if the conditions were honest.

The discipline is to build a prototype that could change your mind and to state separately what the artifact demonstrates, what it only suggests, and what it does not test.

There is a small political cost to prototyping forward instead of backward. The teaching prototype sometimes shows the room something the room did not want to know. The team that ships those prototypes may earn trust, and it may also pay a short-term price for the problems they reveal. Both sides of that ledger are real. The choice is a product call about whether the meeting needs persuasion, learning, or two separate artifacts with two explicit jobs.

Sources and revision note

Evaluation guidance revised 13 September 2026. The definitions of tasks, trials, graders, transcripts, outcomes, repeated trials, and human calibration draw on Anthropic's 2026 guide to agent evaluations. The separation of system limits, human oversight, measurement, and risk follows the NIST AI Risk Management Framework Core. The invoice cases and table are illustrative product-design material, not findings from either source or measured results from a deployed product.