Set the contract

The single most expensive design mistake in AI products is letting people discover the system’s limits by hitting them. When someone asks your assistant to do something it can’t do, and the assistant fails silently or confabulates, you haven’t just lost that interaction — you’ve taught the person that the product’s promises are unreliable. Microsoft’s HAX guidelines put this first for a reason: make clear what the system can do, and make clear how well it does it. Two contracts, and most products ship neither.

The good versions are unglamorous and effective. ChatGPT states its knowledge cutoff and shows when it’s browsing versus answering from training. Claude tells you when it can’t open a link. GitHub Copilot frames itself as a suggestion engine — the ghost-text presentation itself communicates “this is a draft, not an answer,” which is contract-setting done through form rather than copy. Compare that to the first wave of AI search summaries that presented probabilistic guesses with the same visual confidence as retrieved facts, and absorbed a news cycle of ridicule for it.

The contract has two halves and teams reliably ship only the flattering one. “What it can do” is marketing’s favorite half. “How well it does it” is the half that builds trust: this transcription is roughly 95% accurate, this summary may miss items in tables, this agent cannot see your screen. Granola is a good study — it presents itself as notes built from your meeting audio plus your own typed fragments, which quietly sets the expectation that you are a participant, not a bystander waiting on magic.

State the contract where the work happens, not in a help center. A capability statement in onboarding is forgotten by the third session; a limit surfaced at the moment it becomes relevant — “I can’t run this code, but here’s what it should do” — is remembered forever. And self-identification is part of the contract, not a legal nicety: people calibrate differently the instant they know they’re talking to a machine, and every product that has blurred that line has regretted it.

The test is simple. If a new user’s first three failures each make them say “right, it told me it couldn’t do that,” you set the contract. If they say “I thought this thing was supposed to be smart,” you didn’t — and no amount of model quality will buy that trust back cheaply.

The honest case against this principle is that stated limits are a tax on wonder, and wonder is what sells. Every disclosed weakness is ammunition for a competitor’s demo, a caveat that flattens your launch video, a reason for a hesitant buyer to wait a quarter. There’s also a real UX cost: front-loading limitations makes a product read as apologetic, and people who are told “this is roughly 95% accurate” sometimes trust it less than the numbers warrant — under-reliance is a documented failure mode, not a hypothetical. Growth teams aren’t wrong that ambiguity converts. But the debt comes due at retention, not acquisition. The user you dazzled into a miscalibrated first week is the user who churns loudly in the fourth, and the model improves underneath a stated contract far more gracefully than a reputation recovers from a broken implied one. You can always widen a promise you kept; you cannot re-narrow one you broke.

You measure the contract by measuring surprise. Instrument the first-session failure moments: when the system declines or errs, does the user retry a variant of the same doomed request (they never got the contract) or redirect to something the product handles (they did)? A healthy product shows doomed-retry rates falling toward zero within the first three sessions. Pair that with retention-after-first-error — cohort users by whether their first failure was a disclosed limit or an undisclosed one, and compare week-four retention; the gap is the dollar value of your contract. Support tickets phrased as betrayal (“it said it could…”) versus calibration (“can it do X?”) are the qualitative twin. Good looks like this: fewer than one in ten first-week failures land on capabilities the interface never scoped, and users who hit a disclosed limit retain within a few points of users who hit no limit at all.