OpenAI Dots Turn Always On Agents Into a New Kind of Platform Lock In

OpenAI introduced Dots at DevDay on September 29, describing them as remarkably capable, always on agents built to handle ongoing responsibilities. The interesting part is not that another agent can browse, plan, and complete tasks. Plenty of systems can already assemble those pieces. The important change is persistence. An assistant answers a request. An always on agent remains responsible for work after the conversation ends. That turns the model provider into part of the operating environment, not just a source of intelligence.

I think this is a bigger business move than a model release. A better model can be compared against another model and replaced when the economics change. A persistent agent accumulates context, permissions, schedules, tools, unfinished work, and expectations. Every useful week makes it more capable, but also more expensive to move. The product begins to look less like an application interface and more like an employee account, cloud computer, and workflow system bundled together.

Persistence changes the unit of competition

Model companies have mostly competed on intelligence, price, latency, and developer experience. Dots push competition toward continuity. The question becomes whether an agent remembers the right context, notices the right event, keeps working reliably, and can act across the services a person already uses. Those qualities do not live inside model weights alone. They live in the surrounding system.

That favors large platforms. OpenAI can connect an agent to ChatGPT users, developer tools, subscriptions, and a growing catalog of integrations. Once the agent is trusted with a continuing responsibility, the relationship becomes harder for a rival model to interrupt. A competitor may offer better reasoning next month, but better reasoning is not enough if moving requires rebuilding permissions, history, automations, and review habits.

This is why I do not see always on agents as merely another chat feature. They are a bid to own the workflow between prompts. The most valuable activity may happen when the user is not looking at the product at all. Monitoring, checking, preparing, retrying, and escalating all create value without a fresh chat session. They also create a durable place for the platform inside the business.

The model is becoming the replaceable part

There is a useful contradiction here. OpenAI is making the agent relationship more persistent at the same time models are becoming less durable as technical choices. Frontier leads keep narrowing and shifting. Open weight models improve. Inference engines make existing weights faster and cheaper. A task that needs the most capable hosted model today may run well on a local model six months from now.

The agent state should therefore be more portable than the model, but commercial incentives point the other way. Providers benefit when memory, tool configuration, identity, schedules, and execution history stay inside their product. Customers benefit when those assets belong to the workflow and can survive a model change. That tension will define the next round of agent competition more than another benchmark lead.

I run local models and agent systems because the separation is operationally useful. Interactive work can use one model while background jobs use another. A difficult planning step can call a frontier endpoint while routine execution stays on hardware I control. That only works when the agent is not fused to a single model or provider. The workflow has to treat intelligence as a route, not an identity.

Dots make the opposite path look convenient. The provider supplies the intelligence, runtime, persistence, and product surface together. Convenience will win many buyers, especially when the system works without infrastructure work. But convenience does not erase dependency. It packages dependency well enough that people stop seeing the individual parts.

Always on also means always consuming

Persistent agents change the economics of AI use. Chat creates visible consumption because a person initiates each exchange. Background agents can monitor continuously, retry tasks, inspect changes, and produce work nobody requested in that moment. Useful autonomy means more inference, more tool calls, more storage, and more execution time. The billing relationship can expand from paying for answers to paying for ongoing responsibility.

That is attractive for providers because it increases both usage and retention. It can also be rational for customers when the work is valuable. The problem is that value becomes harder to attribute. A completed request is easy to inspect. A background agent may spend all day watching for an event that never happens. The cost of readiness becomes part of the product, even when the visible output is small.

Local inference has an interesting role here. Hardware is not automatically cheaper, and operating it is not free. But persistent background work is exactly where owned capacity can become strategically useful. Latency matters less when the agent is not blocking a person. A smaller open model can handle monitoring and routine execution, while a hosted frontier model remains available for rare hard decisions. The economic boundary follows the task rather than forcing every action through the most expensive intelligence.

The real moat is the agent record

The durable asset in an always on agent is not its current model. It is the record of what the agent knows, what it can access, what it has tried, which decisions required approval, and how its work was judged. That record improves performance and trust over time. If it cannot leave the platform, it becomes the lock in mechanism.

OpenAI Dots are a clear signal that the market is moving from chat sessions toward delegated responsibility. I expect that direction to stick even if the first products are uneven. The key test is not whether the agent can complete an impressive demonstration. It is whether its memory, permissions, schedules, evaluations, and history can move when a better model or runtime appears.

My recommendation is to test portability before giving any always on agent a permanent job. Export its state, replace its model, recreate its permissions, and resume an unfinished task somewhere else. If that process breaks the agent, the business did not just adopt useful automation. It hired a workflow that can never leave its employer.