Free preview

Proactivity, and the Cost of Speaking

In one line: the hard part of a proactive assistant is not finding things worth saying, it is deciding not to say most of them.

The second entry point

Everything so far assumed the user asked. A proactive assistant has a second trigger: something in the world changed and the system noticed.

That is the property that makes it an assistant rather than a chatbot, and it is where most of the product value lives — a system that only answers questions requires you to know what to ask.

Note where the decision sits. The interesting logic is not "what should I tell them" but "should I speak at all", and that gate rejects most candidates.

Attention is the scarce resource

The constraint that binds, and it is much tighter than teams expect.

People tolerate a small number of unsolicited interruptions per day before they stop paying attention — and then disable the feature. The commonly cited ceiling is a handful, total, across everything the product might want to say.

The cost of getting this wrong is not linear. Interruption research has long found that recovering from an interrupted task takes far longer than the interruption itself, and that even brief interruptions measurably increase error rates in demanding work. So a notification is not a free impression; it is a withdrawal from the user's attention, and the account is small.

Worse, the damage is lagging. Dismissal rates rise quietly for weeks before the feature is turned off, so a proactive system tuned on immediate engagement will look fine right up until it is disabled.

The notification budget

Which makes the design decision a budgeting one rather than a filtering one.

Fix the budget first. Decide how many proactive messages per day is acceptable, and treat it as a hard constraint rather than an outcome. Everything the assistant might say competes for those slots.

Rank candidates against each other, not against a threshold. A threshold produces a quiet day when nothing is urgent and a flood when several things are. Ranking within a budget produces a consistent experience, and it surfaces the most useful thing rather than everything above a bar.

Spend the budget on value, not on volume. Batching helps enormously — one morning summary of five things costs one interruption instead of five, and most proactive content is not time-critical.

That last point is the largest practical win available. The question to ask of any proactive candidate is not "is this worth saying" but "is this worth saying now, rather than in the next digest".

The autonomy ladder, applied

The scoping lesson's ladder is what makes proactivity safe, and each rung has a different bar.

Inform — "your 3pm moved". Cheapest, and it still costs a budget slot.

Draft — "here's a reply to this, send it?" The sweet spot for proactive work: the assistant did the labour, the user keeps the decision, and one interruption delivers real value rather than just information.

Act — done, and reported afterwards. Only for actions that are reversible, low-stakes, or explicitly delegated. And the report still costs attention, so acting silently is sometimes correct for genuinely trivial things.

The trap is treating the rungs as a progression the assistant graduates through globally. It is per action type, and a system that has earned the right to auto-archive newsletters has not earned the right to decline meetings.

Triggers

What actually fires the evaluation, roughly by cost.

Scheduled — a morning digest, an end-of-day review. Cheap, predictable, and it is where batched content belongs.

Event-driven — an email arrived, a meeting was cancelled, a flight changed. Timely, and it needs a filter, because most events are not worth a thought let alone a message.

Condition-driven — a watched state became true: the report is due tomorrow and is unstarted. The most valuable and the most expensive, since it requires evaluating conditions continuously.

Inferred — the assistant noticed a pattern. Highest value when right and highest risk, because the user did not ask for this class of attention at all.

The practical architecture runs cheap filters first and expensive evaluation rarely — the same cascade shape as everywhere else in this course, applied to deciding whether to think about something.

Timing

Underrated, and nearly free to get right.

The same message is helpful at 9am and an intrusion at 11pm. A meeting change is urgent an hour before and informational a week ahead. Someone in a meeting should not be interrupted for anything non-urgent.

Signals available without much work: calendar state, working hours, device activity, time zone, whether they are already in the app. Using them costs almost nothing and it is the difference between a system that feels attentive and one that feels careless.

The rule worth stating: deliver at the moment it is actionable, not the moment it is known. Most proactive content is discovered well before the point at which the user can do anything about it.

Measuring it

The metrics that matter here are unusual, because engagement is the wrong signal.

Dismissal rate, trending. Rising dismissal is the early warning that precedes disabling by weeks.

Disable rate — the terminal metric, and by the time it moves the damage is done.

Action rate — how often a proactive message led to something. The positive signal, and the only one that justifies the interruption.

Unprompted value — how often the user says the assistant told them something they would have missed. Hard to measure and the actual objective.

And the one to watch most carefully: the ratio of proactive messages to actions taken. A rising ratio means the assistant is talking more and helping less, which is the trajectory that ends in the feature being turned off.

Key takeaway

Proactivity is what makes it an assistant, and the binding constraint is attention rather than detection — a handful of interruptions a day, total. Fix the budget first and rank candidates against each other rather than against a threshold, batch anything not time-critical, and deliver when it is actionable rather than when it is known. Watch dismissal rate rather than engagement, because the damage lags by weeks and by the time the disable rate moves it is over.

Next: what happens when the user interrupts the agent.

Enjoying the preview?

Create a free account to unlock the rest of this course, the in-browser judge, and live AI mock interviews.

Sign up free to continue