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. <<File name=”acme_notes.txt”>> 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,