At OpenAI DevDay on September 29, the company launched Dots, always-on AI agents with their own cloud computers, running on GPT-6 Astra and capable of connecting to more than 4,000 applications. The framing was direct: these are not AI assistants. They are persistent digital employees, assigned ongoing responsibilities and working continuously in the background.
The enterprise preview launched off by default. That detail deserves more attention than the feature list.
mindmap
root((Always-on AI agents<br/>governance dimensions))
Technical
Agent identity and credentials
Output auditability
Cross-app integration scope
Organizational
Ownership per Dot
Human-in-the-loop triggers
Escalation protocols
Financial
Usage cost visibility
Per-agent ROI measurement
Risk
Context drift over time
Access scope creep
The rundown
OpenAI’s DevDay 2026 introduced over twenty product launches, with Dots as the centerpiece. Each Dot is provisioned with its own cloud computer and browser, able to connect to integrations across Slack, Microsoft Teams, and thousands of other applications. Companies can configure specialist Dots — assigned a specific function, given their own identity and credentials — and manage enterprise instances through Microsoft Agent 365.
The productivity claims are grounded in what these agents can actually do: track customer requirement changes and update sales proposals, synchronize project documentation as new information arrives, manage dashboards, flag blockers, and coordinate work across teams. These are tasks that currently require a human to remember to do them. An always-on agent doesn’t forget.
Enterprise access launched as a preview, off by default. The Microsoft Agent 365 integration for managing Dots through existing governance tools is planned but not yet shipped. Both of those details are informative.
For the working software engineer
The engineering work that Dots creates is not obvious from the marketing announcement. Each agent requires an integration architecture — how it authenticates to the systems it touches, what data it can read and write, how its outputs are versioned and auditable. These are not trivial problems when the agent is running continuously and making decisions on behalf of the organization.
The deployment pattern that will work in enterprise environments involves the same properties that every reliable automation requires: idempotent operations wherever possible, clear state management, defined escalation triggers, and audit logs that a human can review without having to reconstruct what the agent did from scratch. The teams that figure out that architecture early will have a significant advantage over the ones that bolt governance on after deployment.
Context drift is the engineering challenge that gets underestimated most consistently in early agent deployments. An agent running on instructions set six weeks ago, in a business environment that has shifted, produces outputs that were correct at one point in time and are increasingly incorrect over time. Managing that decay requires an explicit refresh cadence, not just alert-based monitoring.
For business owners and operators
The business case for always-on agents is real. Tasks that currently require a person to maintain a mental model — tracking changing conditions, keeping documentation synchronized, monitoring for specific triggers — are exactly what persistent agents do well. The question is not whether the productivity gain is there. It is whether your organization has the accountability model to capture that gain without creating new risk.
Enterprise access is off by default for a reason. An agent with its own credentials, running continuously across dozens of integrated systems, creates accountability questions that don’t exist with passive AI tools. When the agent makes a decision — updates a document, adjusts a forecast, modifies a workflow — who owns that decision? How is it audited? What happens when it acts on context that is no longer accurate?
The companies that answer those questions before they deploy will get the productivity gain. The companies that deploy first and build the accountability model later will spend the productivity gain managing incidents they didn’t anticipate.
My take
At a class-action settlement administration company I worked with, I built a returns processing and fulfillment workflow integrated directly with USPS systems. This was well before AI agents existed — it was event-driven orchestration built in C# — but the governance challenge was structurally identical. The automated system was making consequential decisions about mail returns: which items to accept, route, and fulfill. The temptation in the early design was to make the system fast and deal with edge cases later.
The lesson I took from that engagement was the opposite: the architecture of an automated workflow that makes consequential decisions needs to be the first decision, not a refinement. Every shortcut in the accountability model came back as an incident. The workflows that ran cleanly for years were the ones where we spent the first third of the project designing the audit trail, the escalation triggers, and the error handling — before we wrote a single integration.
Always-on AI agents are the latest form of that same class of system. They are more capable than anything we had in that engagement. The governance principles are the same. Build the accountability layer first. Define what the agent owns, what it cannot touch, and who reviews its output at what cadence. The productivity gain follows from getting that right — it does not arrive before it.
The off-by-default enterprise preview is OpenAI acknowledging the same thing. The question is whether enterprise buyers hear that signal or dismiss it as a temporary access restriction.
