Designing copilots people actually trust

A copilot that writes fluently and acts silently will be abandoned after the first bad edit. Trust is not a tone of voice. It is a set of controls that make the model’s uncertainty visible and reversible.

Show the draft, not the commit. In documents, tickets, and CRM fields, the default should be a suggestion the user can accept, edit, or discard. Auto-applying model output into a system of record is how you train people to stop using the feature.

Calibrate confidence in the UI. If retrieval is weak or the tool call is low-confidence, say so in plain language and offer a narrower action: “I can draft a reply, but I could not verify the refund policy.” Fake precision — 97% badges on generative answers — trains the wrong instinct.

Every write path needs undo and a diff. Copilots that change copy, SQL, or workflow state should show what will change before it happens, and make rollback one click. This is not polish. It is how you get permission to automate the next step.

Keep a human handoff that does not feel like failure. “Talk to a person” should carry the thread, the retrieved sources, and the last tool calls. Dumping the user into an empty form after the model gives up is how trust leaks out of the product.

Measure adoption as accepted actions, not messages sent. Chat volume is a vanity metric. The copilots that last are the ones that sit next to a real job — reply, reconcile, schedule, file — and make that job faster without hiding the work.