An enterprise readiness plan for OpenAI dots agents
A governed pilot starts with a bounded responsibility and a complete view of the permissions and records it depends on.
Define the pilot's business boundary
Choose a responsibility that is valuable enough to evaluate and bounded enough to supervise. Specify the participating group, data classification, approved sources, output destination, and human decision owner. A draft internal research brief has a different control profile from a workflow that updates customer records. Write the business boundary before deciding which product capabilities to enable.
The pilot charter should state its acceptance criteria and exit conditions. Include the conditions that require stopping: unexpected disclosure, an unapproved action path, a source that cannot be constrained, or a result that reviewers cannot verify. These are operational criteria for the proposed process. They should be agreed by the business sponsor and the relevant technology and governance owners before the responsibility becomes recurring.
Verify workspace controls for intended members
The September 29 documentation describes dots as off by default in Enterprise, requiring administrative enablement. Administrators can control dots access, Slack participation, local-computer access, and use of custom rules through workspace defaults and roles. Cloud computer capabilities and password-manager controls also require review. Test access as an intended participant after configuration, not only as a workspace owner.
Granting a workspace permission does not itself connect the relevant service. Members still complete applicable setup, and source accounts retain their own access boundaries. The admin guide also states that enterprise model controls and defaults do not apply to dots. Evaluate dots capability controls directly rather than assuming an existing model-policy configuration covers every part of the pilot.
Separate data boundaries by component
Create a data-flow record showing conversation content, connected app information, cloud-computer artifacts, local-device files, and accepted outputs. Include saved notes or memory that may persist beyond a single interaction. Those components can have different retention, residency, and administrative boundaries. A single statement that “the workspace is compliant” does not answer which data is present in each part of this workflow.
Review current documentation and contractual commitments with the people responsible for your requirements. The dots admin guide notes that an enabled residency-enforcement cloud policy can make local access unavailable. It also explains that local VPN access and signed-in sessions do not automatically extend to the cloud computer. Validate the actual environment rather than inferring network or residency behavior from a generic diagram.
Evaluate action authority and evidence together
Inventory the actions the pilot needs: reading, drafting, editing, posting, or invoking other tools. Define approval expectations for each category and check which account performs the action. Custom rules are one layer; they do not grant app access or override built-in safety requirements. If custom rules are disabled by the workspace, saved rules do not apply. Document the effective configuration observed during testing.
Determine what evidence your organization needs to investigate a run. The enterprise guide points to supported Compliance API records and explicitly advises confirming coverage. Do not assume a complete forensic history of every computer action, memory update, and connected-app effect. Test the records available for your chosen workflow and supplement them with accepted output versions and source-system logs where appropriate and permitted.
Test realistic exceptions before expanding
Use approved pilot data to test incomplete sources, conflicting records, permission denial, expired connections, and an instruction outside the authorized scope. Have a reviewer inspect the output and the available records. Define what an acceptable escalation looks like, including its recipient and the information it may contain. A useful pilot demonstrates both productive work and understandable limits.
Include a stop exercise. Pause the main dot, inspect and stop relevant delegated tasks, and cancel future schedules separately. Review app connections and website sessions as distinct access surfaces. Stopping or revoking one capability does not undo completed actions. The team should know how to identify those actions and who can authorize a corrective change in the affected business system.
Make the rollout decision from recorded evidence
At the end of the pilot, compare observed results with the charter. Record accepted outputs, review effort, material exceptions, unresolved constraints, and the controls actually tested. A completion message or enthusiastic user response is insufficient evidence of readiness for broader use. The decision can be to expand, revise the workflow, retain limited use, or stop.
For expansion, name ongoing owners for business outcomes, access reviews, user training, and incident handling. Prepare a short operating guide that explains the approved responsibility and the boundaries users must preserve. Recheck documentation after material product changes. Enterprise readiness is a continuing operating responsibility, and the first pilot should leave a clear, reproducible record for the next team.
The source record
Sources & editorial notes
Primary documentation checked September 29, 2026. Our implementation recommendations are editorial analysis. Illustrative workflows are proposed examples, not completed client case studies or performance claims.
- Manage dots permissions and capabilities OpenAI
- Roles and workspace permissions OpenAI
- Apps and connectors OpenAI
- ChatGPT Work Cloud security OpenAI
- Compliance API OpenAI
- Tasks and memory OpenAI
- Control your dot OpenAI
Found something that needs updating? Contact the editorial team with the passage and a supporting source.