OpenAI Is Selling the Agent Factory

Update: the factory owns the clock now

OpenAI has added a clock to the agent factory.

The Agents API can now run scheduled automations on a recurring cron schedule or at a one-time future timestamp. A schedule can start a clean session for independent work or return to an existing session for a context-aware follow-up. OpenAI has also added an optional tool that lets an agent create and manage schedules for its current session from natural language.

That sounds like a modest convenience.

It is not.

The moment an agent can decide that work should happen later, the application stops being only a place where a user starts tasks. It becomes an operating system for promises.

Check this price every morning.

Review these incidents in an hour.

Continue the investigation after the next data refresh.

Those promises now survive the chat turn that created them. They need ownership, budgets, cancellation, auditability, and a truthful account of what actually happened.

Cron is the easy part.

The product is everything between "run at 9" and "the work is done."

A completed invocation is not completed work

OpenAI's documentation makes the most important distinction unusually explicit.

Every scheduled run creates an invocation. If the invocation is marked completed, that means the message was delivered to the target session.

It does not mean the agent finished the task.

That one sentence should shape the entire interface.

A scheduled agent has at least four different states:

• the schedule exists and is eligible to run
• an invocation attempted to deliver the task
• the session accepted and executed the work
• the work produced the expected outcome

There is a fifth state if the user needs to know about it: the application displayed or delivered the result.

Collapse those states into one green checkmark and the system will lie.

A morning report can be delivered to a busy session, accepted later, fail during a tool call, and never reach the user. The scheduler can still have done its job perfectly.

This is the same mistake teams make with message queues: acknowledging the envelope is not the same as completing the business process inside it.

OpenAI supplies invocation records and session events. The application still has to join them into an honest status model.

Pause is not stop

The second useful warning is about cancellation.

Pausing or deleting a schedule prevents future deliveries. It does not stop work that a session has already accepted. That active turn must be cancelled separately.

Again, the implementation detail becomes a product requirement.

A user who presses "pause" usually means one of two things:

• do not start another run
• stop whatever this automation is doing now

Those are different commands. A serious interface should expose both.

The same split matters for edits. Updating a schedule does not rewrite an invocation that is already queued. A changed prompt, budget, or destination may apply only to the next run while the old instruction is still waiting to execute.

If that difference is hidden, the system will occasionally do exactly what it was told and still look disobedient.

Agent-created schedules need human ownership

The new automation tool lets an agent create, inspect, update, pause, resume, and delete schedules for its current session.

That is powerful because the agent can turn a conversational commitment into persistent behavior.

It is also where a harmless sentence becomes infrastructure.

"Keep checking" could mean three runs, three months, or until a forgotten API key drains its budget. Removing the automation tool later does not remove schedules that were already saved. They keep existing until the application pauses or deletes them.

So every agent-created schedule needs an owner and a boundary:

• who authorized it
• which session and goal it belongs to
• when it expires
• how much it may spend per run and in total
• which tools and data it may use
• whether overlapping runs are allowed
• which outcomes require approval
• where results and failures are reported
• how a human finds and kills it

Natural-language scheduling is a good input surface.

It is not a governance model.

New session or old context is an architecture choice

OpenAI lets a schedule target a new session or an existing one.

That choice looks small in an API request. It changes the failure model.

A new session is easier to isolate and reproduce. It starts without accumulated conversational baggage, but the application must provide the facts, credentials, and artifacts needed for that run.

An existing session preserves continuity. It can remember why the automation exists and what happened before. It can also inherit stale assumptions, a bloated context, unresolved tool state, or an instruction that was sensible last week and dangerous today.

OpenAI recommends keeping a main agent focused on the durable goal, schedule, and concise summaries while delegating detailed runs to subagents. That is a sensible pattern because recurring output can otherwise fill the very context meant to preserve continuity.

The deeper lesson is that memory is not free just because the provider stores it.

Someone still has to decide what deserves to survive.

The new lock-in includes time

The Agents API already moved lock-in above the model.

Sessions, compaction, sandboxes, subagents, browser state, approval events, and private tool connections all live in the runtime around the model.

Scheduled automations add another layer: temporal state.

Now the provider can hold not only what the agent knows and where it runs, but also what it has promised to do later. Migration means reconstructing schedules, time zones, queued invocations, retry behavior, pause state, session links, and the evidence that a run did or did not happen.

OpenAI also says recurring runs receive a small randomized delay, and a run can wait longer when its target session is busy. That is reasonable infrastructure behavior. It also means a schedule is not a precision timer.

Before using it for serious work, builders should decide:

• Is the workflow idempotent if a run is retried?
• What happens when a run is late, missed, or overlaps the next one?
• Which time zone owns the schedule, including daylight-saving changes?
• Can the user see the next run, last delivery, active turn, and last successful outcome separately?
• Do approval requirements expire between scheduling and execution?
• Can spending or tool permissions change before the run begins?
• How is a provider outage reconciled after service returns?
• Can schedules and their history be exported to another runtime?

The scheduler is a useful addition.

It is also a clean demonstration of what OpenAI is really selling.

Not just intelligence.

Not just execution.

Continuity, infrastructure, and now time.

The agent factory can keep running after everyone leaves the room.

That makes the control plane more valuable.

It also makes honest controls part of the product, not a layer developers can add later.

Update: the factory is now an API

The factory is no longer only an enterprise service.

OpenAI is turning it into infrastructure that developers can rent.

At DevDay, the loud announcement was GPT-6.1 Sol, a cheaper model for coding and professional work.

The more important announcement was everything OpenAI put around it.

The Agents API entered public beta on September 10. OpenAI says it runs the Codex harness as a managed service, including session orchestration, context compaction, recovery, durable sessions, hosted sandboxes, tools, and subagents. On September 29, OpenAI added computer use, so an agent can operate a browser hosted by OpenAI while the developer's application handles website approvals and sign-in.

The same release cycle added Secure MCP Tunnel, an outbound connection from a customer's network to OpenAI. It lets ChatGPT, Codex, the Responses API, and other supported OpenAI products call a private MCP server without that server accepting public inbound traffic.

Put those pieces together.

OpenAI can now host the agent, preserve its session, compact its context, coordinate its subagents, give it a browser, connect it to private tools, and stream the work back to the application.

That is not a model API with a few utilities attached.

It is an agent control plane.

The abstraction is moving up again

The first useful model APIs sold tokens.

The next layer sold tool calls, structured outputs, files, retrieval, and background work.

The Agents API sells the loop.

Developers can still bring their own environment or supported provider. OpenAI also says the harness is built on open-source components. Those are meaningful escape hatches.

But the default product is clear: send the task to an OpenAI-managed runtime and let OpenAI operate the difficult machinery around it.

That is attractive because the machinery is difficult.

A long-running agent needs more than a prompt and a while loop. It needs state that survives a dropped connection. It needs context compaction that does not quietly delete the important constraint. It needs tool permissions, environment isolation, progress events, retries, cancellation, recovery, and a record of what every subagent did.

Most teams do not want to build all of that before they can test whether the workflow is useful.

So OpenAI is offering a very good trade:

Give us the operational complexity.

Also give us the center of the architecture.

Computer use makes the boundary visible

The browser feature shows how this product wants responsibility to be divided.

OpenAI hosts the browser and runs the agent loop. The developer's application receives requests when the agent wants to visit a website or sign in. The application is supposed to show the request to the user, collect approval or credentials, and return the decision.

That is the right shape.

The agent should not approve its own access.

But an approval event is not an approval product.

Builders still have to decide:

• what the user is actually consenting to
• whether approval applies to one page, one origin, one action, or the rest of the session
• how credentials stay out of model context and logs
• what happens when a request expires during sign-in
• how the user sees what the browser did after approval
• which actions require a second confirmation before data changes

OpenAI supplies the mechanism.

The application still owns the meaning.

That distinction will be easy to miss in demos and impossible to ignore after the first incident.

Private access is not the same as private execution

Secure MCP Tunnel solves a real enterprise problem.

A company can keep an MCP server behind its firewall, run OpenAI's tunnel client inside the network, and open only an outbound HTTPS path. OpenAI queues MCP work, the client forwards it locally, and the response travels back through the same tunnel.

That is much better than telling every enterprise to expose a new public endpoint because the agent needs one tool.

It also changes the trust diagram.

The private server remains private.

The request still passes through an OpenAI-hosted tunnel endpoint.

OpenAI's documentation makes another useful distinction: tunnel metadata changes appear in Platform audit logs, and normal app-level compliance logging still applies, but tunnel control-plane traffic and individual transport requests are not emitted as ChatGPT Compliance Platform app events by the tunnel path.

That does not make the tunnel unsafe.

It means security teams need to map which system records which evidence before they call the workflow auditable.

"The server is not public" answers a network question.

It does not answer every question about data handling, authorization, retention, observability, or incident response.

The new lock-in is operational memory

Model lock-in is easy to describe.

Your prompts work best with one model. Your evals target its behavior. Your budget assumes its prices.

Runtime lock-in is deeper.

It lives in session history, compaction behavior, tool definitions, approval events, sandbox assumptions, subagent traces, retry semantics, and the recovery path after a partial failure.

You can replace a model name in an API call.

Replacing the system that remembers the work, decides what context survives, schedules the tools, and reconstructs a failed session is closer to replacing an operating environment.

That does not mean builders should reject the Agents API.

Managed infrastructure is often exactly the right choice.

It means the architecture review should stop pretending the model is the only dependency that matters.

Before putting serious work on a hosted agent runtime, ask:

• Can we export the full session, tool events, approvals, and subagent traces?
• Can we reproduce the workflow with another runtime?
• Which state belongs to us, and which state exists only inside the provider?
• Can we pin the model, harness behavior, and tool contracts?
• What happens to an in-progress session during a provider outage or API change?
• Can we stop every child agent from one control surface?
• Which actions are enforced by our systems rather than requested in the prompt?
• Where do we investigate when the application log, tunnel log, and provider trace disagree?

The factory has become easier to rent.

The buyer still needs to know where the emergency exits are.

DevDay's real product

GPT-6.1 Sol may be faster, cheaper, or better for a particular benchmark.

Those advantages will move again.

The durable DevDay signal is that OpenAI wants to own more of the path between a request and completed work.

The model reasons.

The harness remembers.

The runtime executes.

The browser acts.

The tunnel reaches private systems.

The application approves.

That last line matters. OpenAI is supplying more of the machine, but responsibility has not disappeared. It has been divided across more boundaries.

The winning agent platform will not only make those boundaries powerful.

It will make them legible.

The agent factory is here.

Now developers have to decide whether they are buying machinery or renting the floor it sits on.

The Short Version

OpenAI is no longer just selling the agent.

It is selling the factory around the agent.

On July 22, OpenAI introduced OpenAI Presence, an enterprise product for deploying voice and chat agents across customer and internal workflows. The official page says Presence connects agents to company systems, policies, permissions, simulations, evaluations, guardrails, escalation paths, and human approval.

That is a lot of nouns.

It is also the point.

Presence is not "here is a smarter model, good luck."

It is OpenAI saying:

We will help you choose the workflow, connect the systems, define the policies, test the agent, monitor production sessions, propose improvements, and roll out changes under approval.

Very casual. The chatbot has become a managed operational system.

The useful story is not that OpenAI wants enterprise revenue.

Of course it does.

The useful story is that model labs are moving up the stack into deployment, quality control, systems integration, and business-process software. OpenAI already launched the OpenAI Deployment Company in May to embed Forward Deployed Engineers into organizations. Presence is the product version of that same thesis.

The model is no longer the whole sale.

The sale is:

Can we make this agent reliable enough to touch your customers, your claims process, your IT tickets, your procurement flow, and your internal systems without turning every incident into a meeting with legal?

That is a much harder business.

It may also be the real enterprise AI business.

Presence is not a wrapper

The lazy version of the story is:

OpenAI launched a customer-support agent.

Fine.

Another support bot.

Please hold while the future routes your issue to a knowledge base.

That undersells it.

OpenAI says Presence starts with a specific job: billing issues, insurance claims, employee IT requests, customer support, outbound sales, procurement, HR. The company receives only the knowledge and system access required for that job. The customer sets policies for what the agent can do, when it needs approval, and when a person should take over.

That is not a wrapper.

That is workflow architecture.

It means the product is less about the chat bubble and more about the surrounding machinery:

• standard operating procedures
• permissions
• tool access
• simulations
• evals
• graders
• guardrails
• escalation rules
• production monitoring
• change management
• human approval

Beautiful. We finally made agents enterprise-ready by surrounding them with the exact amount of process that makes enterprises enterprise.

But that process is not decoration.

It is the product.

The day before the original version of this article, I wrote that long-running agents need brakes. Presence is the commercial version of the same idea, but aimed at businesses: not just "can the agent act?" but "can the company govern how it acts?"

The agent has to keep changing

One detail in OpenAI's post matters more than it looks.

Presence is designed to improve after launch.

OpenAI says production sessions and escalations reveal gaps. Codex can investigate those signals and propose updates. Teams can test proposed changes against the production version, then approve a controlled rollout.

That is the part that makes this different from old automation.

Traditional enterprise software often fails because it freezes a process that is already changing. The policy changes. The product changes. The customer changes. The support team invents an exception. The workflow slowly diverges from the implementation until everyone starts copying notes into a spreadsheet called "temporary."

AI agents make that drift faster.

An agent that talks to customers will encounter new edge cases every day. It will learn where the policy is ambiguous, where the knowledge base is stale, where users ask questions no one anticipated, and where the handoff to humans is too late or too early.

So the real system is not:

Agent launches.

Agent works.

Done.

The real system is:

Agent launches.

Agent fails in interesting ways.

The company learns.

The workflow changes.

The evals change.

The agent changes.

The approval process decides whether the change is allowed.

That loop is the product.

OpenAI is not just selling an agent that answers the phone.

It is selling a way to keep changing the agent after it answers the phone.

This is where SaaS gets nervous

Presence puts OpenAI in a strange position.

It is still a model company.

It is also becoming a systems integrator.

It is also becoming an enterprise software vendor.

It is also potentially competing with the companies that used to build on top of its models.

If Presence handles customer support, outbound sales, claims, IT help desk, HR, and procurement, then OpenAI is not only a supplier to software vendors in those categories. It is moving into their territory.

Not necessarily by replacing them.

At least not immediately.

Presence still needs company systems. It has to connect to CRMs, ticketing tools, identity systems, policy databases, call-center stacks, knowledge bases, billing systems, HR tools, and whatever terrifying internal app was built in 2014 and somehow still runs payroll.

So the likely near-term shape is integration, not total replacement.

But the strategic pressure is obvious.

If the agent layer becomes the place where customer conversations happen, then the agent layer starts to own the workflow. The underlying SaaS app becomes one of the systems the agent uses.

That changes power.

The question for SaaS companies is no longer only:

Can we add AI features?

It is:

Do we remain the system of work, or do we become a tool inside someone else's agent?

Very fun question to bring to the next board meeting.

OpenAI wants deployment data too

There is another subtle piece here.

OpenAI says Presence was developed in collaboration with its Research team, and that generalized insights from deployments inform research and product development.

That makes sense.

It is also strategically important.

The companies that see real agent deployments will learn what agents actually fail at.

Not benchmark failures.

Real failures:

• customers who phrase the same problem five different ways
• policies that contradict each other
• tools that return weird states
• approval rules that are too strict
• escalation paths that are too slow
• agents that sound confident but miss the actual issue
• humans who override the agent for reasons the eval did not capture

That is incredibly valuable feedback.

The model lab that operates the deployment layer gets a better map of where agents need to improve. It sees the business cases, the failure modes, the workflows, the integrations, and the places where companies are willing to pay.

That is a data advantage.

Not necessarily training-data in the narrow sense.

A product-learning advantage.

Presence turns enterprise deployment into a feedback loop for the lab.

Limited availability is part of the signal

Presence is not self-serve.

OpenAI says it is available to eligible enterprise customers through a limited general availability program, with deployments led by OpenAI Forward Deployed Engineers and select global systems integrators.

That matters.

If this were a normal SaaS feature, the button would say "Start free trial."

Instead, it says: talk to your account team.

That is not just enterprise sales theater. It tells you what the product still requires.

It requires integration work.

It requires policy mapping.

It requires access reviews.

It requires eval design.

It requires change management.

It requires human owners.

The absence of self-serve is a useful honesty marker. Production agents are not yet plug-and-play for serious workflows. The market keeps saying "agents." The work keeps saying "implementation."

That is why OpenAI's Deployment Company matters. The lab is building a services arm because the model alone does not produce the outcome.

The frontier capability is necessary.

The deployment muscle is what makes it billable.

What buyers should ask

Presence may be genuinely useful.

It also raises the right buyer questions.

If a company brings an AI lab into customer support, claims, HR, IT, sales, or procurement, it should know:

• Who owns the SOPs and policy definitions?
• Which systems can the agent read or modify?
• Which actions require approval?
• What counts as a successful resolution?
• Who designs the evals?
• Can the customer export logs, evals, prompts, and policy rules?
• How are proposed agent changes reviewed?
• Can another vendor run the same workflow later?
• What happens if OpenAI changes the underlying model?
• What happens if the customer wants to use a non-OpenAI model for part of the workflow?
• Who is accountable when the agent follows policy but the policy is wrong?

That last one will matter.

Enterprise AI will fail in boring ways.

Not always because the model hallucinated.

Sometimes because the policy was unclear, the integration was brittle, the approval path was wrong, or the business process was already a mess before the agent arrived.

The agent will not magically fix that.

It will reveal it at scale.

The bottom line

OpenAI Presence is not the biggest AI model story of the week.

It may be the more important enterprise story.

It shows that the frontier labs are no longer content to be intelligence suppliers. They want to own the deployment layer: the policies, evals, guardrails, escalation paths, workflows, and improvement loops that turn a model into something a company can put in front of customers.

That is where the money is.

That is where the lock-in is.

That is where the failures will be.

The agent race is not only about who has the best model.

It is about who owns the factory that turns models into work.