Your AI Agent Needs More Than a One-Time Yes

Key takeaways

• Persistent agents need permissions with a defined scope and expiration conditions.
• Reading email, drafting replies, and sending messages require separate permissions.
• Approval rules should reflect an action’s consequences and pause execution when permission is unclear.
• Stopping future actions, recovering completed work, and investigating failures require separate controls.

An AI that books your flight while you sleep sounds useful—until the trip has been canceled. Suppose OpenAI Dots could keep working after you closed the chat; that is a hypothetical scenario, not a claim about its actual features. It raises a practical question: when should your original yes stop counting?

Instructions can outlive the reason you gave them

“Plan my business trip next week” seems straightforward if the agent returns a few flight options. You review them and decide what happens next.

Now let it monitor prices and book when a suitable fare appears. The agent must keep making decisions after you leave. That is persistent autonomy: delegating judgment over time, as well as a task.

Your circumstances can change while it works. The meeting gets canceled. The agent continues following its instructions and buys a ticket. It may have followed the original request faithfully and still produced an unwanted result.

A durable instruction therefore needs an endpoint. “Monitor prices until Friday afternoon” defines a time limit. “Pause booking if the meeting changes” defines a condition that suspends permission.

Both matter. A task can remain technically executable long after it stops being useful.

Make permissions specific to actions

An email connection leaves plenty unsaid. You may want an inbox summary. Whether the agent can reply on your behalf is a separate decision.

Permissions become easier to understand when they describe actions:

• Read and summarize relevant messages.
• Save reply drafts.
• Ask for approval before sending to an external recipient.

Scope should also cover which messages the agent can access and for how long. A travel assistant could read only emails related to the trip, with that access expiring when preparation ends.

This is least privilege: grant the access needed for the job. For a persistent agent, that principle must remain adjustable. When the assignment shrinks or circumstances change, its permissions should shrink too.

The user also needs a clear view of active assignments. Managing an assistant should not require remembering every instruction issued last month.

Put approval where the consequences are

An agent that asks permission before reading every email creates another inbox to manage.

A more useful approach ties approval to consequences. Information gathering and drafting can proceed within an agreed scope. Payments and outgoing messages can require confirmation immediately before execution.

Recurring work can have standing permission, provided the boundaries are concrete. Consider an instruction to order office supplies from an approved vendor within a fixed monthly budget.

The spending cap is only part of the rule. A different delivery address or a change in the items being purchased could trigger a fresh approval. If the agent cannot determine whether an action fits its permission, it should pause.

The approval screen needs to expose the actual decision. “Continue?” tells the user almost nothing. “Send this message to this recipient now?” gives them something meaningful to review.

The goal is a clear relationship between what the user approves and what the agent subsequently does.

A stop button is only the beginning

A persistent agent needs an obvious stop control, alongside a view of its running and queued tasks.

Stopping prevents further execution. Recovery addresses what has already happened. A recipient may already have read a sent email. A completed booking may require a cancellation process. Those need separate controls.

Then there is the question of explaining a failure. A useful record connects the original instruction to the permissions in force at execution time. If a person approved the action, it should also preserve what the approval screen showed them.

Suppose the user requested a draft and the agent sent it. Several things deserve investigation: how the instruction was interpreted, whether sending permission was too broad, and whether the approval step worked.

That record does not automatically settle legal responsibility. It does provide evidence for finding the failure and fixing it. “The AI decided” offers little help with either.

Persistent delegation is useful because it lets you stop watching. To earn that freedom, an agent needs clear limits on what your permission covers and when it ends. Decide in advance which tasks can run while you sleep—and which decisions should wake you up.