OpenAI Dots for Enterprise: Define the Job Before the Agent

Enterprise teams already know how to give an agent a task. Giving one an ongoing job is a different design problem. The work persists between conversations, new information changes the plan, and the agent may act across several systems. A good prompt does not establish who owns the result, how much authority the agent has or what should happen when the situation falls outside its brief.

OpenAI introduced Dots on September 29, 2026. The product announcement describes always-on agents with their own cloud computer, connected apps and the ability to continue work over time. OpenAI is rolling Dots out to Pro and Business Premium users in eligible markets. Enterprise, Edu and Healthcare workspaces can try the beta when an administrator enables it. The company also previewed specialist Dots, with their own identity, credentials and access, through focused enterprise pilots.

For enterprise pilots, the immediate design question is what the organisation should define before an agent accepts an ongoing responsibility.

A responsibility is larger than a task

A task usually has a visible beginning and end: inspect this incident, compare these documents, prepare this draft. A responsibility stays open. It may watch for new evidence, decide when to resume work and escalate an exception days after the original instruction.

| Design question | Task agent | Responsibility agent | |---|---|---| | Start condition | A person asks | A schedule, event or person asks | | End condition | The requested output is returned | The service remains active until paused or retired | | Context | Mostly bounded to the task | Accumulates across work cycles | | Authority | Granted for one run | Must be maintained and reviewed | | Failure handling | Report the failed task | Detect drift, pause safely and find an owner | | Evaluation | Was this output acceptable? | Is the continuing service reliable over time? |

This distinction is easy to miss because both systems may use the same model and tools. The operating burden changes when the agent decides when to work, carries context forward and retains access after a single deliverable is complete.

Our workflow selection guide helps teams decide whether a process deserves an agent at all. The next step is to turn a selected workflow into a bounded job.

Write a responsibility contract

Before connecting production systems, write a short operating contract that a process owner, security reviewer and delivery team can all inspect. Seven fields are enough for a first pilot.

1. Outcome and finish line

Name the business state the agent should maintain. “Keep unresolved supplier invoices ready for review within one business day” is testable; “help with finance operations” leaves the outcome open. State what counts as ready, late and complete.

2. Observation boundary

List the sources the agent may read and why each one is necessary. Include fields, folders, channels or record types where the system supports that precision. Treat historical context as part of the boundary too: decide what can be retained, for how long and how it is reset when the agent changes jobs.

3. Action budget

Separate actions into three classes:

• May act: reversible, low-impact steps the agent can complete independently.
• Must ask: consequential steps that need a named reviewer or a role-based approval.
• Must hand back: actions the agent cannot perform, even with a conversational confirmation.

Keep this list concrete. “Use good judgment” cannot be audited. “Create a draft payment record, but never release payment or change supplier bank details” can.

4. Triggers and quiet periods

Define what starts a work cycle: a new record, a changed status, a deadline or a scheduled check. Add rate limits and quiet periods so the agent does not turn a noisy event stream into repeated work. Specify which trigger wins when several arrive together.

5. Evidence and decision record

Every material recommendation should carry the evidence needed for review: source records, time observed, policy applied, assumptions and unresolved conflicts. The reviewer should be able to reconstruct why the agent proposed an action without replaying an entire conversation.

6. Exception and handoff

Write down the conditions that stop independent work. Examples include missing identifiers, contradictory records, a permission change, a value above a threshold or an unknown external recipient. Give each exception an owner and a response window. A queue with no accountable person is only a slower failure mode.

7. Owner, review date and retirement

One business owner should be accountable for the responsibility, while technical and risk owners retain their own controls. Set a review date for access, rules and performance. Include a retirement procedure that revokes credentials, disconnects triggers and handles retained context.

An illustrative invoice-review job

OpenAI says its early specialist work includes invoice processing, procurement and commercial contracting. Consider a hypothetical invoice-review Dot as a design exercise; this is not a Bayseian customer result or a claim about a deployed OpenAI pilot.

The agent watches an approved invoice queue, checks purchase-order fields and prepares a review packet. It may add missing internal references and route a packet to the finance queue. A person must approve a payment. The agent must hand back any request to change bank details, any duplicate it cannot resolve or any invoice above an agreed threshold.

The evaluation set should include ordinary invoices and uncomfortable cases:

• a supplier name that nearly matches an approved vendor;
• conflicting totals across the invoice and purchase order;
• an instruction inside an attachment asking the agent to ignore policy;
• a repeated event after the packet has already been created;
• a reviewer who does not respond before the deadline;
• a revoked connection midway through the work.

Evaluate document accuracy alongside duplicate actions, correct escalation, time to a reviewable packet, unsupported claims, permission violations and the quality of the decision record.

Map the contract to the product controls

OpenAI's Dots safety and privacy description explains several controls that can support this contract. Each Dot works in a separate cloud workspace. Connected-app permissions govern what it can reach. Proactive background research uses read-only tools, and follow-up actions go through the usual rules and checks. Custom Rules can allow, require approval for or block particular actions within mandatory safety boundaries.

OpenAI also describes Auto-review as a separate check before actions such as sending messages or changing files. The system evaluates the proposed step against user instructions, Custom Rules and safety requirements. Some actions require confirmation; other sensitive steps must be handed back to the user.

Use those controls as inputs to the design review. OpenAI explicitly says Dots can make mistakes and consequential work should be reviewed. An enterprise pilot still needs its own access review, task-specific tests, monitoring, incident process and evidence that approvals behave as intended.

Ask the pilot team to demonstrate the following rather than relying on configuration screenshots:

1. An allowed action completes and leaves the expected record.
2. A forbidden action is blocked at the control boundary.
3. An approval request reaches the correct role with enough context.
4. A stale or revoked permission stops future work.
5. A malicious instruction inside a permitted source does not expand the job.
6. Pausing or retiring the agent stops triggers and removes access.

Start with a narrow, reversible service

Choose a responsibility with frequent enough work to evaluate, a clear owner and outputs that can be reversed or reviewed before they affect customers, money or regulated records. Run it in shadow mode first: let the agent prepare decisions while people perform the actual actions. Compare the proposed work with the real outcome, then grant one action class at a time.

The contract should change only through a reviewed process. When a team expands a data source, adds a trigger or turns an approval into an automatic action, it has changed the job. Re-run the relevant tests and record who accepted the new risk.

Persistent agents may reduce the coordination cost that makes many automations unattractive. Once temporary instructions become an operating service, the scope and ownership need to be explicit before durable access is granted. If your team is assessing a first production workflow, Bayseian's AI systems practice can help turn the candidate into a testable responsibility, control design and pilot plan.