Scoping, and the Autonomy Question
In one line: "personal assistant" describes a product surface, and the design is decided by what it may do without asking.
The question that comes first
Not what it can do — what it may do unasked.
An assistant that answers questions about your calendar is a retrieval system with a friendly interface. One that moves meetings, replies to emails and books travel is an agent with write access to your life, and the failure modes are unrecognisably different.
Between those extremes is the range where real products live, and it is not one setting. Autonomy is granted per action type, because the actions differ enormously in what a mistake costs.
That ladder is the single most useful framing in this chapter, and it recurs — it is the same shape as the enforcement ladder in moderation and the three-way decision in fraud, arriving in a third place because the underlying problem is the same: a binary choice cannot represent a range of confidence against a range of stakes.
Where each rung belongs
Inform is the default for anything the assistant noticed. Cheap to be wrong, and the user's attention is the only cost — which is not nothing, and gets its own lesson.
Draft is the right rung for most write actions in a new product. The assistant does the work, the user approves. It gets nearly all the value of automation while keeping the human in the decision, and it produces exactly the labelled data you need to decide whether full autonomy is warranted later.
Act should be earned, per action type, from evidence — a category where the draft was approved nearly every time over a meaningful sample is a candidate for promotion. Granting it upfront because it demos well is how these products lose trust in the first week.
Reversibility is the axis
Which actions are safe to automate is decided less by confidence than by whether a mistake can be undone.
| Action | Reversible? | Rung |
|---|---|---|
| Read anything | N/A | Act |
| Add a calendar hold | Yes, silently | Act |
| Move a meeting others attend | No — they were notified | Draft |
| Draft a reply | Yes | Act |
| Send an email | No | Draft, then earn |
| Book a refundable trip | Within a window | Draft |
| Buy something | No | Draft, always |
| Delete anything | Depends on retention | Draft |
The design move that makes this tractable is the same one from the fraud chapter: make actions reversible so they do not need a gate. An outbox with a cancel window converts sending from irreversible to reversible, which moves it up the ladder honestly rather than by accepting more risk.
The four scoping questions
What surfaces? Chat, a device, an ambient presence, a background process with no interface. This decides whether interruption is even possible and how proactivity is delivered.
What data does it see? Calendar, mail, files, location, messages. Each is an integration and a privacy commitment, and the combination is more sensitive than the parts — an assistant that reads your calendar and your email knows things neither source states.
How long are the tasks? Seconds, or hours? A task that spans hours needs durable state, resumability and a way to report progress, which is a different system from one that completes in a turn.
Who is the user? A consumer assistant and an executive assistant used by a professional have different tolerances: the consumer wants magic and forgives little, the professional wants control and will configure it.
The trust budget
The framing worth carrying into the design.
A new assistant starts with a small amount of user trust. Every good action adds a little; every bad one subtracts a lot, and the asymmetry is severe — people remember the meeting it moved wrongly far longer than the twenty it handled correctly.
Two consequences.
Early autonomy is expensive. Spending trust before earning it means the product is disabled before it can demonstrate value, and a disabled feature generates no data with which to improve.
Trust is per capability. Someone who trusts it with their calendar may not trust it with their email, and treating autonomy as one global setting forces them to choose the minimum across everything.
Committing
A personal assistant integrated with calendar, email and files, on mobile and desktop. Tasks range from a single lookup to multi-step work spanning hours, so state has to be durable and resumable. Everything write-capable ships at the draft rung; individual action types get promoted on approval-rate evidence. Autonomy is configured per capability, not globally. And the proactive surface has a hard notification budget, because attention is the scarcest resource in the system.
Every clause is used later. Durable state forces the loop to checkpoint. The draft rung decides where the confirmation gate sits. Per-capability autonomy shapes the permission model. And the notification budget is the constraint on proactivity, which is the hardest part of the product.
Key takeaway
The design question is what the assistant may do unasked, and the answer is a ladder — inform, draft, act — granted per action type rather than globally. Ship write actions at draft and promote them on approval-rate evidence, because that rung is the only way to generate the evidence. Reversibility, not confidence, is the axis that decides what can be automated, so making an action reversible promotes it honestly.
Next: planning, and why plans go stale.