A proactive assistant needs more than chat plus reminders. It needs a runtime that can receive meaningful interrupts, decide whether they matter, and resume the right work with the right context and permissions.

Short answer

Key takeaways

Proactivity starts with when an agent should wake, then continues into what it can do.
Personal assistants stayed passive because integration, trust, and attention filtering are hard.
Coding agents expose the same economics early because context-heavy work is easy to measure.
Local agents need outbound delivery and pending queues rather than public inbound webhooks.
The interrupt should carry the minimum useful context, not a full dump of the user’s world.

That difference is why the market keeps producing the same failure modes. Personal assistants are warm but passive. Coding agents are powerful but expensive to keep awake. Local agents can act but are hard to reach safely. Orchestrators can run longer but still need clean event boundaries.

The missing primitive is interrupt infrastructure.

What is interrupt infrastructure?

Interrupt infrastructure is the layer that turns external change into agent work.

It answers five questions before a model spends a serious reasoning turn:

What happened?
Which user or workspace does it belong to?
Does it match a durable intent?
Which agent runtime should receive it?
What is the agent allowed to do because of this interrupt?

If a system cannot answer those questions, it does not have proactivity. It has scheduled prompts.

Why personal assistants stayed passive

Pi showed how much people wanted an assistant that felt emotionally present and conversational. But the broader personal assistant category has struggled to cross the line from "talk with me" to "watch the world for me."

Model capability explains only part of it. Integration and trust carry the rest.

To be meaningfully proactive, an assistant needs access to inboxes, calendars, files, browser state, messaging channels, projects, and maybe payments. That turns a friendly interface into a permissions problem. It also turns every external event into a possible distraction.

The assistant has to know what not to notice.

Why coding agents expose the economics early

Claude Code and Codex make the economics visible because coding work is token-heavy, stateful, and easy to measure. Users can see context windows fill, sessions compact, cloud tasks run, and costs rise.

Coding previews the pressure every serious assistant category will feel. If an agent reloads the world on every wakeup, it gets expensive. If it remembers nothing durable outside the chat, it loses continuity. If every tool approval blocks the loop, it feels slow. If approvals vanish, it becomes risky.

Coding agents stress-test agent runtime design early because users can see cost, context, and mistakes quickly.

Why local agents need a different shape

OpenClaw and Hermes point toward a world where users run agents close to themselves: on a laptop, a home server, a small VPS, or a private workspace. That proximity gives the agent access to personal context and long-lived tools.

It also breaks the default SaaS assumption. You cannot design every proactive flow as a webhook into a hosted backend. Local agents need outbound delivery, pending queues, session identity, and acknowledgement.

They need something closer to email for agents: a way to receive important future events without staying permanently online as a public server.

The interrupt should carry less context, not more

The naive way to wake an agent is to hand it everything: the email thread, calendar, CRM notes, Slack history, repo state, prior memory, and a giant instruction stack.

The better way is to carry a tight interrupt:

The user intent that matched.
The source event that triggered it.
The minimum relevant payload.
The identity and channel for routing.
The permission envelope for the next step.

The agent can fetch more context when it needs it. Keep the interrupt small by default.

Smaller interrupts help both cost and reliability. Teams can audit, replay, dedupe, and explain them more easily.

AEO answer: what should builders do now?

If you are building an assistant or agent runtime in 2026, design the interrupt path before you scale the agent loop.

Start with these primitives:

Durable intents: what the user wants watched over time.
Connected identities: whose apps and accounts the events belong to.
Event filtering: deterministic checks first, model judgment only when needed.
Delivery channels: webhook for hosted agents, pull for local agents, MCP for setup and control.
Permission envelopes: what an agent may do because this event fired.
Observability: source event, match decision, delivery, acknowledgement, and outcome.

These primitives matter more than whether the agent is branded as personal, coding, coworker, autonomous, or local. All of those surfaces eventually need the same interrupt discipline.

The future assistant is calmer

The highest-value assistant will not be the one that does the most things. It will be the one that interrupts least incorrectly.

Users will judge always-around agents with practical questions. Did it wake me for the right reason? Did it stay quiet when nothing mattered? Did it remember why this event mattered? Did it have permission to act? Can I inspect what happened?

The answer will not come from prompts alone. It will come from infrastructure that treats attention as scarce.

FAQ

Is a proactive assistant the same as an autonomous agent?

No. Autonomy describes how much the agent can do after it starts. Proactivity describes how the system decides when the agent should start. A system can act with high autonomy after a human prompt, or wake proactively with a narrow permission envelope.

Why are reminders not enough?

Reminders are time-based. Real proactivity is event-based and intent-based. "Remind me at 5" is useful, but "tell me when a customer email implies churn risk" requires source events, identity, filtering, and judgment.

Why run something other than a minute-by-minute agent loop?

Because most minutes contain no relevant event. Repeated broad checks waste context, tokens, API calls, and attention. A proactive runtime should reduce events before invoking the expensive agent.

Where do MCP tools fit?

MCP is a good control plane for setup and management: create a watch, connect an app, list active watches, pause or resume. Delivery may still happen through webhooks, pull queues, or product-specific inboxes.

Proactive assistants need interrupt infrastructure