As AI agents begin working in the background, the challenge is not only getting them to take initiative. It is deciding when they should stay quiet, notify us, ask permission or stop.

Imagine an AI assistant helping you prepare for a meeting. You have authorised it to check a shared folder and draft reminders. It notices that a briefing document is missing and prepares a message for you to review. Useful. Now imagine it sends that message to everyone attending, or moves the meeting in their calendars, without permission. The same attempt to help has crossed a boundary.

The issue is not whether the assistant spotted a real problem, but whether it had authority to act. A missing document raises two questions: does it deserve your attention, and what may the assistant do about it?

Working between our messages

An AI agent need not wait for someone to type a question. Software can trigger it on a schedule or when an event occurs. “Always-on” does not necessarily mean a model is thinking continuously.

LangChain’s Nathan Drezner describes scheduled runs that let agents handle reminders, monitoring and follow-ups. Behind those tasks sits the harness: software that manages the agent’s tools, state, and workflow, along with controls that restrict its actions.

Yet waking an agent is easier than deciding how it should behave. LangChain co-founder Harrison Chase identifies initiative, responsiveness and alignment with user goals as unresolved engineering challenges. A schedule supplies a trigger, not fresh permission.

When asking becomes another burden

A notification tells you something; an approval request asks you to authorise a consequence. Too many updates compete for attention, while repeated prompts can turn careful decisions into routine clicks.

The team behind Anthropic’s Claude Code describes a similar problem with coding assistants: repeated approval requests can wear users down. Its auto mode uses automated classifiers to assess some actions instead. This approach addresses a coding workflow, not every kind of AI assistant.

Removing every prompt is no answer either. Permission to prepare a reminder does not include permission to distribute it. The aim should be fewer unnecessary interruptions while preserving decisions that genuinely belong to the user.

Four choices for a helpful agent

A useful way to think about this is through four choices: work, notify, ask or stop. This is an editorial lens, not a complete security policy or a tested formula for every situation.

Work quietly when preparation is authorised. The assistant can draft notes from documents it has permission to read; technical access alone does not make a document fair game.

Notify when something merits attention. Routine updates can be grouped, while a missing briefing shortly before a meeting may justify an alert. Urgency changes the value of a notification, not the agent’s authority.

Ask when an action exceeds the current mandate. Before sending a reminder to additional recipients, identify the message, recipients and consequences. A vague “Continue?” is not enough. Explicit prior authorisation can cover recurring reminders to agreed recipients.

Stop before a prohibited action. Pause if the intended recipient or required authorisation is unclear, or a protective check fails, and explain what is missing. A vague approval cannot override a non-overridable restriction.

These choices separate usefulness from permission. Even a reversible calendar change affects other people. Reversibility matters when weighing consequences, but it does not grant authority.

Boundaries beyond the conversation

An instruction to be careful is not enough. Account permissions and available tools should limit an agent’s actions. Check required approvals before execution, record significant actions, and let users pause or cancel future work.

Whose access is the agent using? Harrison Chase and LangChain colleague Caspar Broekhuizen distinguish between agents acting through a user’s account and those using a fixed service account. Either arrangement needs limits on the operations and communication channels available to the agent.

DeepSeek’s research team draws a line between spotting work and starting it. In its agent prototype, an opportunity the system discovers does not automatically become a task it may carry out. Starting such work requires an enabled mode and a matching rule. The prototype illustrates one design approach; it is not production-ready software or proof that interruptions will fall.

Controls still depend on fallible judgements. Anthropic cautions that automated classifiers cannot replace careful human review for high-stakes infrastructure.

A sandbox—an isolated environment limiting what software can access or affect—does not settle every safety question; external services and credentials need separate restrictions. Stopping tomorrow’s run cannot undo an email sent today. Controls must constrain actions before they happen.

Judge assistance by control, not activity

For university readers considering AI assistants for learning, work or administration, practical questions matter more than impressive demonstrations. What may it do without another instruction? Which changes require a specific decision from me? Can I see its actions, pause its work and revoke its future authority?

Even in an ordinary meeting, a draft reminder leaves room for judgement, while a sent message speaks on someone’s behalf. The distinction matters when the user is busy or away.

The goal should not be the largest number of completed actions or the smallest number of approval prompts. It should be useful work within an understandable mandate. Noticing an opportunity to help is valuable. It is not permission to act on it.