This is a loser-interesting question because it sounds like sabotage. The demo finally worked. The room relaxed. Then the serious builder does the rude thing: expire the token, break the handoff, point the tool at the wrong target, or swap the ambient assumption that made the magic look easy. That move is not cynicism. It is how a performance becomes a product.
Dependable agents earn trust after the first pass, not during it. The real proof is a deliberate break test with visible traces, named tools, approval pauses where they matter, and a recovery receipt another operator can inspect later.
Why this question feels socially expensive
Builders want applause for the clean run. Investors, teammates, and customers also reward the clean run because it compresses complexity into a nice short story. The embarrassing part is that the story is usually incomplete. A working demo says the model found one path under one mood with one live environment. It says almost nothing about what happens when the credential expires, the target changes, the human revises the request, or the system has to resume in front of someone skeptical.
That is why the deliberate break test looks mean but creates trust. It replaces "believe my polish" with "inspect the boundary that failed, the handle that survived, and the recovery path that still worked."
The primary docs already favor systems that survive the wound
The official OpenAI guide for evaluating agent workflows centers traces, graders, datasets, and evaluation runs. That is not demo language. It is a measurement stack for repeated probes. The guardrails and human review guide makes the runtime consequence explicit too: sensitive actions may need a run to pause so a human can approve, reject, or stop the flow. Meanwhile the MCP tools specification insists that tools have names and schemas, which turns side effects into inspectable verbs instead of background folklore.
Even outside AI, the same posture shows up in the Principles of Chaos Engineering: define a steady state, vary real conditions, and build confidence by experimenting under turbulence. The shared lesson is blunt. If a workflow only looks good in the happy path, it is not dependable yet. It is merely rehearsed.
The demo that never gets wounded teaches the wrong lesson
A flattering demo trains the team to overcredit the model and underprice the system. The model sounds smart, so everyone forgets to ask whether the task had a durable ID, whether the tool authority was smaller than the language authority, whether the approval seam was visible, and whether a second operator could tell what changed after the run.
This is where many agent products quietly turn back into theater. The narration says "autonomy." The runtime reality is that one hidden session, one unspoken environment assumption, or one expired credential is still carrying the whole experience. The deliberate break test is how you find out whether the product contains a workflow or just a mood.
Name the steady state first
Decide what "working" means before you add the wound: the active route, target, output, tool boundary, and proof surface.
Inject the boring failure
Expired auth, wrong target, stale context, interrupted handoff, or missing approval usually teaches more than a theatrical catastrophe.
Keep authority smaller than intelligence
Let the model classify, propose, or draft. Keep mutations behind named tools, typed inputs, and visible review pauses.
Publish the recovery receipt
The valuable artifact is not the narrator's confidence. It is the trace, diff, route, or live revision that shows what failed and what recovered.
Chopshopr already prefers the rude version of the story
The public Chopshopr labs that feel most trustworthy already follow this shape. Continuity Relay becomes interesting only after a synthetic clinic handoff is broken on purpose and the recovery proposal has to show its source IDs in public. Causal Forge is not just a pretty multi-agent world; it asks you to inject a failure and inspect what the system does next. Those surfaces are more honest because the break is part of the product, not a thing hidden backstage.
The same rule governs the site ship loop. A route is not "done" because HTML exists locally. The claim only hardens when build passes, the deploy completes, and the live route survives a cache-busted check. That is the product form of wounding the demo on purpose: ask the work to survive the exact environment shift that usually exposes bluff.
Smarter models make this discipline more necessary, not less
As models get more fluent, the social cost of skipping the break test goes up. A more persuasive answer can hide a broken approval seam more elegantly. A more capable coding agent can mutate a larger surface before anyone notices the target was wrong. Better model intelligence expands the blast radius unless the system gets even stricter about traces, tool contracts, and public recovery evidence.
That is why the serious builder's instinct becomes narrower, not broader. Shrink the authority. Name the state. Break the likely boundary. Make the recovery visible. Then, and only then, call the demo dependable.
The product question worth keeping
When an agent demo impresses you, ask one meaner question before you believe the story: what failure did you inject on purpose, and what public receipt proves recovery? If the answer is vague, the workflow still depends on theater. If the answer is crisp, you are probably looking at a tool someone can inherit.