Unpacking ChatGPT Work: the Agent for a Billion Users

Editor’s note: I’m excited to welcome Shlok to our guest post roster! You may know Shlok from his excellent explorations (as an outsider — for an insider perspective see our podcast with OpenAI’s Akshay Nathan. Already one of our most popular episodes of the year!) of leading AI Lab memory systems, which he gave an excellent AIE talk on. We’ve been covering OpenAI’s research and deployment of agents to all of humanity since Plugins 2023 and Devday 2024 and Codex 2025, and now ChatGPT Work in 2026 seems the penultimate stage of the long journey. Let’s dive in! On July 9th, OpenAI released ChatGPT Work, their agent product for knowledge work. It was, by any measure, a busy launch: three new models across fourteen configurations, a consolidation of the ChatGPT and Codex desktop apps, and cloud agents brought to the mainstream in their most accessible form yet. Three weeks in, Work (along with Codex) has reportedly crossed 10 million users. Editor’s note: ChatGPT estimated to cross 1B MAU in June and 1B WAU this month. Chat and Work currently sit side by side as separate modes inside ChatGPT, but Greg Brockman has confirmed that they will merge by the end of the year. Work, then, is not just a niche product for power users, but a preview of how ChatGPT’s billion weekly users will soon use the app. That’s why people inside and outside OpenAI are so excited about it, and why it deserves a closer look. Work in its current form takes some decoding. It’s an amalgamation of ChatGPT (in chat form), Codex the app, Codex the harness, Codex the original cloud agent, ChatGPT agent, Atlas, OpenClaw, and more. The product lineup around it is confusing. And the web and mobile versions diverge from the desktop one (unless you run it in cloud mode?!). So I spent the past few days trying to unpack it: what Work is, where it fits in OpenAI’s lineup, the many interesting choices in its design, the tensions underneath, and where I think it’s headed. Most of what follows comes from Codex and me poking around inside Work, and I’ve linked those conversations throughout so you can see where each claim comes from. What is Work? At its core: An agent for knowledge work. You connect it to the places you already work—Slack, email, Drive, calendars, CRMs, project trackers, and hundreds of other plugins—and it gathers context across all of them to produce finished work. Runs on the Codex harness. So it inherits the same models, sub-agents, browser use, and the ability to grind on a task for hours. Its UI is stripped of the evidence (git controls, diff-traces) that would give away you’re talking to a coding agent. Lives in a cloud computer. Specifically, a beefy, isolated microVM: Pro accounts get 8 CPUs, 20GB of RAM, and a 64GB disk; Plus gets 14GB of RAM. Alongside the VM, Work gets a managed Chrome service that the agent operates through tool calls. Produces artifacts. Sheets, docs, and slides rendered in interactive viewers, plus Sites: hosted web apps and dashboards it can build, share via URL, and keep updated. Every new conversation in Work is called a task. On web and mobile, Work runs in the cloud. You can kick off a task on web, track progress and give directions in the ChatGPT app on your phone, then view the result (maybe a report or a spreadsheet) back on your laptop. Work on the desktop app is slightly different and comes in two modes: cloud and local. In cloud mode, tasks run on the same cloud computer as web and mobile and sync across all three. In local mode, the agent works directly on your machine, across your files and apps, with full computer use. These tasks don’t appear on web or mobile, and there’s no way yet to move a local task to the cloud. This makes local mode essentially Codex, minus the code-related UI traces that would scare off a non-developer. On desktop, each new Work task can run locally on your computer or in the cloud. But then things get a little confusing. OpenAI did release a way to hand off a Codex task to a remote environment. Although this doesn’t work for me at the time of writing, I assume it eventually will, and that they will then bring the same functionality to Work. For the rest of this piece, Work = Work in cloud mode. Persistence & Memory One big reason OpenClaw felt different from a chatbot was that the agent had a computer of its own. You could run it on an always-on laptop or a VPS, let it create directories, install software, and maintain databases, and reuse all of this across conversations and subagents. Its state lived not just in chat history, Markdown files, or a dedicated memory system, but across the whole computer. Work’s cloud computer is persistent too. But rather than running in one VM that stays on forever, its workspace is synchronised to persistent storage and restored onto isolated microVMs as needed. So the underlying machine can change, but the working state carries over. Compared to OpenClaw, though, the agent has far less sovereignty over this computer. Every Work task (thread) gets a working directory under /workspace/scratch, where the agent has the freedom of a normal computer: it can make folders, install dependencies, write scripts, keep databases, and search everything with ordinary Linux commands. When I ask it to make a presentation for Acme, it can create clients/acme, copy in the source material, perform some analysis through code, and create charts and slides, all as files in the directory. When I follow up in the same thread, it returns to that working state and can continue editing it. But when a task needs context from other threads, it does not treat their working directories as a shared workspace that it can navigate freely. It relies instead on the ChatGPT product layer. By default, each new thread receives a compressed summary of recent tasks and files worked on . A summary might look like this: 20260731T15:55 Prepare Acme pilot plan:|||| Turn the attached notes into a one-page plan for the Acme pilot, with an objective, deadline, and next steps. > Raw conversation transcripts are not stored on the computer for the agent to browse. When a task needs context from previous threads, the agent calls Personal Context, a dedicated tool that queries Chat and Work history through a separately managed service and returns the relevant excerpts. Files follow the same pattern. ChatGPT’s Library is the central user-facing repository for all files and artifacts. User uploads land there automatically; agent-created files are saved when the user asks, or when the agent judges them worth retaining. The agent can also create directories in the Library to keep it organised. Like conversations, the Library doesn’t live on the computer, and can only be reached through dedicated tools. An uploaded file thus exists in two places: a working copy inside the thread and a canonical item in the Library. Interestingly, the two do not synchronise. If Thread A uploads a file and Thread B later changes the Library version, Thread A continues to read its now-stale local copy when resumed. When instructed explicitly, an agent in one task can navigate the scratch directories of other tasks, find files, and modify them. But it won’t do this on its own, and the directories have opaque names, no legible map to their conversations, and no stated retention contract. Memory is managed externally too. As I’ve written before, ChatGPT’s core memory primitive is a running, synthesised profile of the user. The product maintains that asynchronously and supplies it to Work when a task begins. The agent can reason from it, but can’t modify it or create OpenClaw-style Markdown files that other tasks load by default. ChatGPT’s Projects carry over into Work. Projects group related conversations, standing instructions, and Sources (user-uploaded files). A new task within a Project receives its instructions, summaries of relevant conversations, and local copies of Sources in its directory. But the Project itself does not exist on the computer as a directory, as it does in Codex. It too is an abstraction the product maintains. In short, the agent has broad freedom within a task, but continuity across tasks runs through an opinionated ChatGPT product layer rather than the computer itself. Why the split? My guess is several reasons: Work builds on existing ChatGPT primitives (Conversations, Library, Personal Context, Memory). Ripping all of that out and rebuilding it inside the computer would mean refactoring a stack that already serves a billion users. The separation is a guardrail. OpenClaw-style unrestricted access to a single environment holding every file, conversation, and memory is unsafe for users. It lets OpenAI keep control of the product: what users see in the UI, how context is managed, and how sharing, cross-device sync, and file versioning work. All of that is harder to build if the agent could alter the environment at will. What Work lacks today is a meta-layer agent, one that operates a level above individual tasks and projects and coordinates between them. (Some already use Codex this way.) Perhaps that is coming, along with much else. Work is still young, and the architecture could look very different a few weeks from now. Hints of useful proactivity Today’s AI products are still reactive. Before the model can help, you have to notice that something needs doing, gather the relevant context, and translate it all into a prompt. The agent can do a stellar job from there, but the initial act of agency is still yours. Proactivity, where agents figure out how to be useful on their own, is one of the holy grails of personal AI. Work offers an early glimpse of that. When you open a new Work conversation, alongside the composer, you get personalized tasks generated from your own context. One suggestion offered to prepare me for an upcoming call. When I selected it, Work injected a pre-authored prompt. It had reasoned asynchronously across my context: noticed the calendar event, inferred that preparation would help, pulled data from Calendar and Gmail, and framed a task around the interests and preferences in my memory. When I sent the prompt, it got to work, and the result was a great meeting brief — one I didn’t know I needed! Today, Work takes a credible first step: it suggests tasks. But nothing happens until I execute them. For true proactivity, it would have to complete the tasks it predicts I’d want done, without me in the loop. That future doesn’t seem far off. Scheduled Tasks Automations let Work run tasks at a future time or on a recurring schedule, without the user manually prompting it. They are ChatGPT’s abstraction for reminders and cron jobs. OpenAI introduced them as Scheduled Tasks in January 2025. Work builds on the same scheduler but makes it agentic: each run can use the agent’s context and tools to complete the task. They come in two types. A standalone scheduled task begins each run from a saved prompt and opens a fresh task for the result. It suits self-contained work: a one-off reminder, a daily briefing, a weekly job search, a routine email scan. A scheduled task inside an existing conversation, triggered by a “heartbeat”, reawakens that task with its context intact. It suits use cases like monitoring a long-running operation, polling a connected service, or resuming a review loop at short intervals. At the time of writing, heartbeats work in the desktop app but are not exposed in Work on the web. Either automation can be set up as one-time or recurring. Its trigger can be an exact time, a loose window such as “in the morning”, or a condition the agent monitors. You can manage automations in two places. Inside a conversation, you can ask Work to create one, inspect existing automations, change their instructions or cadence, or pause and resume them. The Scheduled page puts all of this in a UI: every task with its next run and recent results, plus controls [truncated for AI cost control]