A capability contract is the model's promise, stated up front: here's what this system is for, here's where it taps out, and here's what it hands back to a human. Set it before the first use — not after the first complaint. The product's limits, named plainly, are what make the rest of it believable.
Declare the edges in the interface
Most products bury scope in a terms-of-service page and hope. Then the model gets a question outside its competence, answers anyway, and a user's trust dies in a single confident wrong answer. The fix is to state the boundary where the work happens — in the interface, at the moment of use.
An honest "I don't handle that" is not a weakness; it's the thing that makes the "I do handle this" believable. A model that knows its own edges reads as a colleague, not a slot machine.
Hand off; don't fake it
When a request leaves the model's competence, the right move is a clean hand-off to a human — visibly, not silently. The worst pattern is graceful-looking degradation: the model keeps answering, in the same confident tone, well past the point where it knows anything.
Design the hand-off as a first-class path, with the same care as the happy path. The person should feel routed, not abandoned — "this one needs a specialist, here's how to reach one," not a shrug.
Specific beats vague
"Results may vary" protects no one and informs no one. A real capability contract is specific: "I can't price illiquid assets," "I don't read handwriting," "I'm trained through 2024." Specific limits are the ones a person can actually plan around.
Specificity also disciplines the team building the thing. Writing the contract forces an honest conversation about what the model actually does well — and that conversation, more than any feature, is what keeps the product trustworthy as it grows.
Shipping a model that should say 'no' sometimes?
The honest boundary is what makes the confident answer land. I've drawn the scope contract for AI in regulated workflows. Bring yours and we'll compare notes under NDA.
Send me the roleImplementation Checklist
- Write the contract before launch: what it's for, where it taps out, what it hands back.
- State limits in the interface, at the point of use — not only in the docs.
- Make out-of-scope a clean hand-off to a human, not a silent confident guess.
- Be specific: name a boundary a person can plan around.
- Revisit the contract every time the model's scope actually changes.
See This Pattern In Action
- Programmatic Advertising Platform: every call resolved to act, review, or ignore — "ignore" was the model admitting it had nothing worth saying.
- AI-Assisted Due Diligence: the model declared the deals it wouldn't score, up front, instead of bluffing through them.
One pattern a month. The tradeoffs I paid for, plus code.