A managed AI agent can feel like a single product surface: give it a task, let it work, and wait for the result.
Operationally, it is something else entirely.
On September 14, OpenAI reported elevated Work Mode errors affecting some Plus users. The issues included problems starting or resuming tasks, as well as accessing workspace tools and files. OpenAI later reported mitigation and recovery.
The immediate lesson is not that the model is unreliable. It is that an agent depends on a distributed system of services, state, permissions, files, tools, queues, and interfaces. Any one of those dependencies can fail while the underlying model remains available.
The agent is more than the model
A production agent workflow may need to:
- accept and persist an instruction;
- maintain task state across multiple steps;
- retrieve files or other context;
- invoke external tools;
- wait for asynchronous work;
- record completed actions; and
- resume after an interruption.
If task state is lost, the agent may not know where it stopped. If a tool is unavailable, it may be unable to make progress. If a file or workspace dependency cannot be reached, a task that worked moments earlier may fail before the model can do anything useful.
This is familiar territory for anyone who has operated a distributed application. The agent interface can hide the dependencies, but it cannot remove them.
Design for interruption, not uninterrupted execution
When an agent performs consequential work, treat every step as interruptible.
Persist durable checkpoints. Record the task, current stage, relevant inputs, outputs, and next action somewhere that survives a process or service failure. A user should not have to reconstruct the entire task from memory after a failed run.
Make actions idempotent. Retrying an operation should not create duplicate tickets, send repeated messages, or apply the same change twice. Use stable operation IDs, deduplication, and explicit status tracking where appropriate.
Retry selectively. Temporary failures may recover, but retries should have bounded attempts, backoff, and clear handling for failures that are not transient. Blindly repeating a side effect is not resilience.
Make resumption explicit. A resumed task should know which steps were completed, which were attempted, and which still require confirmation. “Run again” is not a safe recovery strategy when the agent can change external systems.
Degrade gracefully. If a tool, file, or workspace dependency is unavailable, the agent should preserve what it can: save a draft, report the blocked step, ask for the missing input, or provide a clear handoff. A partial, observable result is usually better than silent failure.
Expose state to operators and users. Show whether a task is queued, running, waiting, blocked, failed, or complete. Clear state makes recovery possible; a spinner does not.
A useful production question
For every agent workflow, ask:
If this task stops halfway through, what allows us to resume safely?
The answer should identify the checkpoint, the owner of task state, the retry policy, the deduplication mechanism, and the fallback path. If the answer is “the model will try again,” the workflow is not yet operationally complete.
Managed agent platforms can reduce the infrastructure your team has to operate. They do not eliminate distributed-systems failure modes. As agents take on longer-running and more consequential work, reliability will depend less on an uninterrupted model session and more on the workflow around it.
Build agents that can stop, recover, explain what happened, and continue safely. That is the difference between a compelling demo and a production system.