OpenAI announced on June 11, 2026 that it plans to acquire Ona to expand Codex with secure, persistent cloud environments. The stated goal: enable long-running AI agents across enterprise workflows. This is a rare public signal about the operational plumbing needed when agents move from demos to production workloads that span sessions, tools, and hours or days of execution time.
Most agent demos run in ephemeral contexts. A user asks a question, the agent calls a few APIs, returns an answer, and the process dies. Enterprise workflows don’t work that way. An agent that provisions infrastructure, waits for deployment, runs tests, and files a report needs state that survives across multiple execution windows. It needs a place to park intermediate results, credentials, and context without leaking data between tenants or sessions.
The State Management Problem
Traditional orchestration tools (Airflow, Temporal, Step Functions) solve workflow state by externalizing it into a database or event log. Each task is stateless. The orchestrator tracks progress and retries failures. This works when you control the task boundaries and can serialize everything into JSON.
Agents break this model in three ways:
- Unpredictable tool sequences: The agent decides at runtime which APIs to call and in what order. You can’t predefine a DAG.
- Stateful sessions: Many enterprise tools (IDEs, browsers, SSH sessions) require persistent connections that can’t be serialized and resumed.
- Long pauses: An agent might wait hours for a CI pipeline or approval workflow. Keeping a container running is expensive. Killing it loses context.
Persistent cloud environments address this by giving each agent a durable, isolated workspace that survives process restarts. Think of it as a lightweight VM or container that can hibernate and wake up without losing open file handles, environment variables, or in-memory state.
What “Persistent” Actually Means
A persistent cloud environment is not just a long-running container. It’s a set of primitives that let an agent maintain continuity across execution boundaries:
| Primitive | Purpose | Failure Mode |
|---|---|---|
| Checkpoint/restore | Serialize process state (memory, file descriptors, network sockets) to disk and resume later | Incompatible kernel versions, non-deterministic code paths |
| Durable storage | Persist files, logs, and intermediate outputs across restarts | Storage quota exhaustion, orphaned resources |
| Session isolation | Prevent credential leakage and data mixing between concurrent agent runs | Shared filesystem paths, environment variable pollution |
| Network identity | Maintain stable IP or hostname for callbacks and webhooks | IP exhaustion, DNS propagation delays |
| Resource quotas | Limit CPU, memory, and storage per agent to prevent runaway costs | Quota too low kills legitimate work, too high enables abuse |
The checkpoint/restore primitive is the hardest. CRIU (Checkpoint/Restore In Userspace) can snapshot a Linux process tree, but it’s brittle. File descriptors to network sockets often can’t be restored if the remote end closed the connection. Shared memory segments and GPU state are even harder.
Most production systems avoid full process checkpointing. Instead, they use application-level state management: the agent periodically writes its context (conversation history, tool results, next steps) to a database. On restart, it reads the context and continues. This is simpler but requires the agent framework to expose hooks for serialization.
Architecture: Persistent Environments in Practice
Here’s what a persistent environment looks like under the hood:
# Agent framework pseudocode
class PersistentAgentSession:
def __init__(self, session_id, checkpoint_store):
self.session_id = session_id
self.checkpoint_store = checkpoint_store
self.workspace = f"/mnt/agent-workspace/{session_id}"
self.env = self._load_environment()
def _load_environment(self):
"""Restore environment from last checkpoint"""
checkpoint = self.checkpoint_store.get(self.session_id)
if checkpoint:
return {
"context": checkpoint["context"],
"tool_state": checkpoint["tool_state"],
"credentials": self._decrypt(checkpoint["credentials"]),
"next_action": checkpoint["next_action"]
}
return self._initialize_fresh_environment()
def execute_step(self, agent_logic):
"""Run one agent reasoning step, then checkpoint"""
result = agent_logic(self.env)
self._checkpoint({
"context": self.env["context"],
"tool_state": self.env["tool_state"],
"credentials": self._encrypt(self.env["credentials"]),
"next_action": result.next_action,
"timestamp": time.time()
})
return result
def _checkpoint(self, state):
"""Write state to durable storage"""
self.checkpoint_store.put(self.session_id, state)
# Also write to local disk for fast resume
with open(f"{self.workspace}/.checkpoint", "w") as f:
json.dump(state, f)The key insight: the agent doesn’t need to know it’s being checkpointed. The framework handles serialization between reasoning steps. Each step is atomic. If the process dies, the orchestrator spins up a new environment, loads the last checkpoint, and continues from the next action.
Security Boundaries
Multi-tenant persistent environments are a nightmare for security. You can’t just give each agent a Docker container and call it done. Containers share a kernel. A malicious agent (or a compromised one) can escape and access other tenants’ data.
Ona’s infrastructure likely uses one of three isolation models:
-
Firecracker microVMs: Each agent gets a lightweight VM with its own kernel. Overhead is ~125ms startup and ~5MB memory per VM. AWS Lambda uses this. It’s fast enough for agents that wake up frequently.
-
gVisor sandboxing: Intercept syscalls in userspace to prevent kernel exploits. Slower than native containers but lighter than full VMs. Google Cloud Run uses this.
-
Namespace isolation with seccomp: Standard Docker but with aggressive seccomp profiles that block dangerous syscalls. Cheapest option but weakest isolation.
The choice depends on threat model. If agents run untrusted code (like Codex generating and executing scripts), you need VM-level isolation. If agents only call approved APIs through a controlled SDK, namespace isolation might suffice.
Credential management is the other hard problem. An agent that talks to GitHub, AWS, and Slack needs API keys for all three. You can’t bake them into the environment. You can’t pass them as plaintext environment variables (they’d leak in logs and checkpoints).
The standard solution: a secrets manager (Vault, AWS Secrets Manager) with short-lived tokens. The agent requests credentials at runtime using its session ID. The secrets manager checks that the session is authorized for those credentials, issues a token with a 1-hour TTL, and logs the access. The agent never sees the long-lived secret.
When Long-Running Environments Make Sense
Not every agent needs persistence. A customer support bot that answers questions from a knowledge base can run in a stateless Lambda function. Each request is independent. No need for continuity.
Persistent environments pay off when:
- The workflow spans hours or days: Provisioning infrastructure, running tests, waiting for approvals.
- The agent uses stateful tools: SSH sessions, browser automation, database connections that can’t be easily serialized.
- Intermediate state is expensive to recompute: If the agent spends 10 minutes analyzing logs to decide the next action, you don’t want to redo that work after a restart.
- The agent needs to respond to external events: Webhooks, file system changes, scheduled tasks.
The cost is complexity. You need checkpoint logic, quota enforcement, garbage collection for abandoned sessions, and monitoring for stuck agents. You also need to handle version upgrades: what happens when you deploy a new agent framework while 50 sessions are hibernating?
Observability Challenges
Debugging a long-running agent is harder than debugging a stateless function. The agent might fail on step 47 of a 50-step workflow. The logs are spread across multiple restarts. The failure might be non-deterministic (a flaky API, a race condition).
You need structured logging that ties every log line to a session ID and step number. You need distributed tracing that follows the agent’s path through multiple services. You need a way to replay a session from a checkpoint to reproduce the failure.
The observability stack looks like:
- Structured logs: JSON with session_id, step_number, tool_name, input, output, duration.
- Trace spans: One span per agent step, with parent/child relationships for nested tool calls.
- Checkpoint history: Store the last N checkpoints so you can rewind and replay.
- Metrics: Session duration, steps per session, checkpoint size, restart frequency.
Without this, you’re flying blind. An agent that silently gets stuck in a loop or keeps retrying a failing API call will burn through your budget before you notice.
Technical Verdict
Use persistent cloud environments when:
- Your agent workflows span multiple hours or days with long idle periods.
- You need to maintain stateful connections (SSH, browser sessions, database cursors).
- Intermediate state is expensive to recompute and can’t be easily serialized.
- You’re building a multi-tenant platform where agents run untrusted code.
Avoid them when:
- Your agent workflows complete in seconds or minutes.
- All state can be externalized to a database or event log.
- You can decompose the workflow into independent stateless tasks.
- You’re prototyping and don’t need production-grade isolation or observability.
The Ona acquisition signals that OpenAI sees persistent environments as critical infrastructure for enterprise agents. This is the plumbing layer beneath orchestration: the primitives that let agents survive restarts, maintain context, and run securely in multi-tenant environments. If you’re building agents that do real work (not just answer questions), you’ll need something like this. The question is whether you build it yourself or wait for the platform to provide it.