The Signal
Dots can keep working. Give them a job that has an end condition.
OpenAI’s always-on agents shift the question from prompting to delegation. Start with a bounded responsibility, visible evidence, and a clear handoff.

The Signal · Release analysis · September 29, 2026
The most consequential part of an always-on agent is the work it might do after you stop watching. That makes the job description more important than the opening prompt.
OpenAI introduced Dots on September 29. The product uses GPT‑6 Astra, a cloud computer, and connected apps to pursue work across conversations. It is rolling out to Pro and Business Premium users in eligible markets; Enterprise, Edu, and Healthcare access is an administrator-enabled beta. Specialist Dots with organizational identities are focused enterprise pilots, not a generally available substitute for every department.
OpenAI also distinguishes proactive research from subsequent action: its background research tools are read-only. Follow-up actions remain subject to permissions and action checks. That is a useful boundary to preserve when designing the job you hand over.
Delegate an outcome you can inspect
“Keep an eye on sales” sounds natural but hides several decisions. Which records matter? What counts as a stalled opportunity? May the agent contact anyone? Does a missing response mean a customer lost interest, or that a salesperson forgot to log a call?
A better starting responsibility is concrete: review opportunities in a named pipeline, identify those without a recorded next step, and prepare a daily exception list with links to the underlying records. The agent can do useful work before it gets permission to send anything.
This is a design recommendation, not a claim that Dots will perform that exact workflow successfully in your account. The integration, data quality, and permissions must be tested.
A hypothetical first assignment
Imagine a service company whose estimator handles both quoting and scheduling. Leads sometimes sit because the estimator is on site. The owner wants a persistent assistant to make the neglected work visible.
Give the assistant a short operating brief:
- Scope: one pipeline and one team, excluding closed or disputed records.
- Deliverable: a reviewable list of missing next steps, with the last relevant activity and a record link.
- Authority: read the selected records and prepare drafts; no customer messages or status changes.
- Uncertainty: flag conflicting dates, duplicate contacts, and missing history.
- Stop condition: do not keep retrying a failed connection; report the missing coverage.
- Owner: the estimator decides what to do with each exception.
The first successful run is not “the agent found ten things.” It is that the estimator can verify the list, distinguish a true omission from incomplete data, and resolve the useful items quickly.
Ongoing work needs a maintenance rule
A responsibility can become stale even while the agent keeps executing it faithfully. Someone changes a pipeline stage, replaces the scheduling tool, or starts logging calls in a different place. A daily report built on the old definition may look reassuring and be wrong.
Include a review date and an owner for the instructions. When the business process changes, revisit the task. Ask the agent to expose its coverage: which source it read, how current the information was, and what it could not inspect.
Avoid turning every observation into a notification. A persistent assistant that interrupts for every minor inconsistency simply creates another inbox. Agree on which events justify immediate attention and which can wait for a digest. The threshold should follow the cost of delay, not the agent’s enthusiasm.
Permission is a separate decision
Once a read-and-draft workflow proves useful, you might consider a narrow write action. For example, the assistant could propose an internal follow-up task. That is different from changing a customer’s appointment or sending a quote.
Assess each action separately. Can the result be checked? Can an incorrect change be reversed? Could a retry create a duplicate? Which person owns the exception if the destination system does not confirm success?
A broad instruction to “handle it” leaves those questions unresolved. A bounded instruction makes them reviewable. Read the permission boundary behind persistent agents before expanding access.
Judge the product by recovered attention
The launch establishes a product direction and documented controls. It does not prove that an agent will understand your organization’s informal rules or remain reliable across every connected system.
For a first trial, count how much useful work reaches an accountable person and how much cleanup the agent creates. Keep a record of false alarms, missed cases, unclear handoffs, and decisions that required more context. Those observations are more useful than the number of tasks the agent says it completed.
The operator takeaway: start with one recurring responsibility that produces evidence you can inspect. Expand its authority only when you understand its failure modes. Persistence is valuable when it removes follow-up work from people; it is costly when it merely keeps an ambiguous process running.
Source: Introducing Dots, checked September 29. The service-company scenario is hypothetical. This article does not report a Xovion deployment or trial.
The Signal
Read next.
Agents · Coding
Cloudflare gives coding agents their own repos. Who decides what ships?
Artifacts now lets teams fork agent work and wire previews to review. Isolation helps, but the acceptance decision needs evidence and an owner.
Risk · Security
Your agent needs three permissions: read, decide, and act
Persistent agents make permission design an operating decision. Separate access to information from authority to change the business.