A rule runs on Monday morning, finds an overdue campaign, and prepares a change. The owner approved the rule on Friday. Over the weekend, the owner’s access changed and the sending capability was switched off.
The trigger still fired correctly. A correct trigger isn’t enough reason for the operation to run.
Proactive work separates the moment someone expressed intent from the moment the product acts on it. The design has to keep that intent without pretending Friday’s context and authority stay true forever.
Decide what the agent is being proactive about
Noticing, preparing, and acting are different commitments. An agent might spot overdue work, prepare a revised schedule, or change dates under a standing rule. Each can be useful. More autonomy isn’t automatically the more complete product.
Shopify’s Pulse shows proactive preparation. Suggestions appear on the admin home page, opening one starts a conversation with a to-do list, and the merchant approves each change before the change applies. The suggestion starts a decision; the suggestion doesn’t authorize every effect that follows. Sidekick Pulse
A suggestion needs a reason to believe the situation matters. A prepared proposal needs a scope and a way to inspect it. An executed change needs the authority that justified acting and a receipt of what happened. Don’t disguise the three modes as one setting.
Write a standing instruction someone can inspect
“Keep my projects moving” expresses intent but makes a weak rule. The phrase doesn’t settle which projects, which changes, or what to do when the situation is ambiguous.
A better rule names a project, a weekday schedule and time zone, and permission to prepare revised dates for overdue draft tasks. The rule allows automatic date changes only inside an explicit scope and limit, and leaves outside notifications out of the grant. When a proposed change exceeds those limits, the agent prepares the change for review instead of splitting the change into smaller pieces to slip under the limit.
The rule keeps a version and an owner. Each run records the version used, the objects selected, and the evidence that made the trigger relevant. When the rule changes while a proposal is pending, don’t reinterpret the old proposal under new, broader wording.
| Part of the rule | Question the part answers |
|---|---|
| Trigger and freshness | Why start now, and is the observation still relevant? |
| Scope | Which objects and changes are included? |
| Acting account | Whose permissions does the run use? |
| Limits and review conditions | What may happen without another decision? |
| Delivery | Who hears about the result, and when? |
| Owner and lifecycle | Who can change, pause, or retire the rule? |
Plain language can explain those choices. Consequential limits also need enforcement where the operation runs. A prompt saying “never send externally” shouldn’t be the only thing between a date change and a customer email.
Name the account that survives the conversation
An unattended run can’t borrow a vague idea of “the user.” The run needs a defined actor and current authority. Some products act with the requester’s account; others give the agent grants of its own or use a configured connection.
Notion documents the distinction. The personal Agent follows the user’s access, while Custom Agents use permissions granted to the agent. Sharing a Custom Agent can let another person retrieve information or make edits through access that person doesn’t hold directly. Notion chose that permission model deliberately; the model isn’t evidence that every agent should act as its creator. Custom Agent sharing and permissions
Decide what happens when the rule’s creator leaves. Revoking the creator’s access may stop a rule that borrows that access; a rule with its own service account may need reassigning. Either way, someone must own failures and future changes. A background job that still runs with no accountable owner isn’t maintained automation.
Notification permissions matter too. A rule may be able to read a restricted record without being allowed to quote the record in a broad team channel. Treat finding something and disclosing it as separate effects. A digest isn’t harmless just because the digest writes nothing to the source.
Recheck at the moment of action
Revoked access and a disabled capability should stop execution even when the proposal was prepared earlier. Running in the background grants no exemption.
A real product also needs an explicit policy for work already prepared or in flight. Neither a rollout change nor an emergency stop necessarily retracts a request a remote system already accepted. So “pause” can mean three different things:
- Stop scheduling new runs while current work continues.
- Ask active runs to cancel, keeping any completed effects.
- Block further writes wherever the block can be enforced.
Pick the control that fits the product and explain the result. “Paused” can accurately describe the schedule while a run is still stopping. One green Paused label for both hides work the person expects to have ended.
Avoid turning one situation into repeated work
A scheduler can fire more than once while the underlying problem stays the same. A reopened tab, a delayed event, or a retry shouldn’t create another proposal or another notification.
Give the situation a stable ID and define when the situation becomes materially different. When someone dismisses a finding as expected, raising the same finding a minute later spends attention without adding information. An approaching deadline or a newly blocked dependency may justify raising the situation again, as long as the interface says what changed. For work started by events, check for self-triggering too: the agent changes a record, receives the change as a new event, and starts again.
Evaluate the interruption as part of the work
Notification opens and proposal approvals are signals, not proof that the issue was real, the action was right, or the result lasted. Follow a sample of findings from trigger to decision to later correction, including dismissed and ignored ones. Then run the engineering test: replay stale triggers, duplicate events, changed permissions, a departed owner, and a pause during execution. Inspect both the changed objects and the outgoing notifications.
A good proactive agent can explain why the agent acted now, what gave the agent authority, what actually changed, and why the agent will or won’t act again. The answers turn a standing instruction into something a team can manage.