An always-on agent still needs a stop condition

On September 29, OpenAI introduced dots: ongoing agents with their own cloud computers. That announcement brings a useful design question into focus. If an agent can keep working after the conversation ends, what tells it that the job is no longer valid? [1]

Consider a content team that asks an agent to prepare material for a launch. The launch is then postponed, the source footage changes, or the person responsible leaves the project. Continuing diligently could now create the wrong work. Our argument is that a recurring assignment needs a lifecycle: a current goal, a defined scope, a responsible person and conditions for stopping. These are recommendations for deploying ongoing agents, not features we have verified in dots.

OpenAI separates dots' proactive research from subsequent action. Its safety explanation says that background research uses read-only tools; follow-up actions remain subject to the usual rules and checks. This specific research mode should not be confused with every authorized task that continues in the background. [2]

For a team, the corresponding design decision is to separate noticing, preparing and releasing. A new interview file might justify preparing a draft clip. It does not, by itself, authorize publishing to a brand account. Write the allowed outcome into the assignment: which materials, which destination, whose approval if required, and which changes invalidate that approval. If the user has already authorized a bounded recurring action, use that authorization within its scope; asking again at every harmless step is not the goal.

OpenAI's MCP Events documentation describes asynchronous processing, retries and potentially out-of-order events. It calls for stable event IDs across retries and idempotent write tools. A delivery acknowledgement is therefore a different milestone from completing the requested work. These are documented integration semantics, not evidence that we tested a particular plugin. [3]

In a video workflow, an upload notification arriving twice should not produce two public posts. Nor should an old review comment overwrite a newer approved revision. One practical design is to track the source item, its version and the intended action together, then check that identity before repeating a write. Let the operator distinguish received, preparing, awaiting a decision, completed and stopped. A generic 'running' label hides precisely the distinction they need when deciding whether to intervene.

The same MCP Events guide requires subscription expiry handling and stopping delivery when access is revoked. Subscription lifetime governs delivery; it does not by itself define when a business goal has expired. That second boundary still needs to be designed. [3]

We suggest recording an owner, review date, allowed scope and stop conditions for each recurring assignment. A campaign ending, a source being withdrawn or an owner leaving can trigger a review. Before an external change, check that the assignment and relevant source version are still current. When an agent delegates, carry the applicable boundary into the delegated work and test what happens when the parent task stops. A stop request should have an observable result, including any step already completed or still in progress.

OpenAI's dots FAQ says that disconnecting a plugin stops new access but does not erase context already retained. It also distinguishes deleting a dot from deleting files or conversations stored separately. Those are product-specific facts; the broader operational lesson is to name the state being changed. [4]

A project cancellation may mean stop future work, revoke a connection, archive working material or remove retained context. These are separate outcomes. An operator needs to know which have happened and which require another action. Do not show 'cancelled' as though it also reversed a message already sent. Equally, do not assume that removing an integration removes every copy of previously obtained material. Define the desired outcome and verify it in the systems that hold the relevant state.

A useful first trial is a narrow, reversible workflow: watch an approved source and prepare a draft for a named reviewer. Then deliberately send a duplicate event, update the source during preparation, withdraw access, cancel the parent task and exhaust a chosen time or cost budget. Check for duplicate changes, obsolete drafts, lingering delegated work and clear explanations of why progress stopped. Define budget enforcement in the actual execution system; a sentence in a prompt is not proof of a hard limit.

There is a real trade-off. Excessive confirmation can turn an agent into another inbox to manage. The answer is to make routine authority explicit and reserve intervention for a changed scope, a consequential step or an unresolved condition. Public documentation does not establish how reliably every integration handles these cases, and we have not run a production evaluation. What the launch makes timely is the acceptance question: can the system stop the right work as reliably as it starts useful work?