拆解 ChatGPT Work：面向十亿用户的 Agent

编者按：我很高兴欢迎 Shlok 加入我们的客座文章作者阵容！你或许已通过他对领先 AI 实验室记忆系统的出色探索认识他（这是外部观察者视角；如需内部视角，可收听我们与 OpenAI 的 Akshay Nathan 进行的播客访谈，这已经是我们今年最受欢迎的节目之一！）；他还曾就此发表精彩的 AIE 演讲。自 Plugins 2023、Devday 2024 和 Codex 2025 以来，我们一直在报道 OpenAI 面向全人类的 Agent 研究与部署；如今，2026 年的 ChatGPT Work 似乎是这段漫长旅程的倒数第二阶段。让我们深入了解！

---

7 月 9 日，OpenAI 发布了面向知识工作的 Agent 产品 ChatGPT Work。无论以何种标准衡量，这都是一次密集的发布：三个新模型，覆盖十四种配置；ChatGPT 和 Codex 桌面应用完成整合；并且云端 Agent 以迄今最易用的形式走向主流。

三周后，据报道，Work（连同 Codex）已经突破 1000 万用户。

编者按：预计 ChatGPT 将在 6 月突破 10 亿月活跃用户（MAU），并在本月达到 10 亿周活跃用户（WAU）。

Chat 和 Work 目前在 ChatGPT 内部仍是并列的独立模式，但 Greg Brockman 已确认，它们将在今年年底前合并。因此，Work 不只是面向高级用户的小众产品，更是 ChatGPT 的十亿周活跃用户不久后将如何使用这款应用的预览。这正是 OpenAI 内部和外部人士都对它如此兴奋的原因，也是它值得深入研究的原因。

目前形态的 Work 需要一些解码。它混合了 ChatGPT（以对话形式呈现）、Codex 应用、Codex harness、最初的 Codex 云端 Agent、ChatGPT agent、Atlas、OpenClaw 等诸多产品与能力。围绕它的产品线令人困惑；Web 和移动端版本也与桌面端有所不同（除非你以云端模式运行它？！）。

因此，过去几天我一直在尝试拆解它：Work 究竟是什么、它在 OpenAI 产品线中的位置、其设计中的众多有趣选择、底层张力，以及我认为它将走向何方。下文大部分内容来自我和 Codex 对 Work 内部的探索；我在全文中链接了相关对话，因此你可以看到每项主张的出处。

其核心是：

• 面向知识工作的 Agent。 你可以将它连接到已经在使用的工作场所——Slack、电子邮件、Drive、日历、CRM、项目追踪工具以及数百个其他插件——它会汇集所有这些系统中的上下文，产出完成度高的工作成果。

• 运行在 Codex harness 上。 因而它继承了相同的模型、子 Agent、浏览器使用能力，以及可为一个任务持续埋头工作数小时的能力。其 UI 去除了那些会暴露你正在与编程 Agent 对话的证据（git 控制项、diff 轨迹）。

• 运行在一台云端计算机中。 更具体地说，是一台性能强大且隔离的 microVM：Pro 账户可获得 8 个 CPU、20GB RAM 和 64GB 磁盘；Plus 账户可获得 14GB RAM。除 VM 以外，Work 还配备了一项托管 Chrome 服务，Agent 通过工具调用操作该服务。

• 产出制品（artifacts）。 包括在交互式查看器中呈现的表格、文档和幻灯片，以及 Sites：它能够构建、通过 URL 分享并持续更新的托管 Web 应用和仪表盘。

Work 中每次新对话都称为一个任务（task）。在 Web 和移动端，Work 在云端运行。你可以在 Web 端发起一项任务，在手机上的 ChatGPT 应用中追踪进度并提供指示，随后回到笔记本电脑上查看结果（可能是一份报告或电子表格）。

桌面应用中的 Work 略有不同，提供云端和本地两种模式。在云端模式下，任务与 Web 和移动端一样运行于云端计算机，并在三端之间同步。

在本地模式下，Agent 可直接在你的计算机上跨文件和应用工作，并拥有完整的计算机使用能力。这些任务不会出现在 Web 或移动端，目前也无法将本地任务迁移至云端。这使本地模式在本质上等同于 Codex，只是去除了那些可能吓退非开发者的代码相关 UI 痕迹。

在桌面端，每项新的 Work 任务都可以在你的计算机本地运行，或在云端运行。

不过，接下来情况会变得有些令人困惑。OpenAI 确实发布了一种将 Codex 任务移交给远程环境的方式。尽管截至本文写作时它对我还无法使用，我假设它最终会可用，届时他们也会将相同功能带给 Work。

在本文余下部分中，Work = 云端模式下的 Work。

OpenClaw 与聊天机器人不同的一个重要原因是，Agent 拥有自己的一台计算机。你可以让它运行在一台始终在线的笔记本电脑或 VPS 上，允许它创建目录、安装软件、维护数据库，并在对话和子 Agent 之间复用这些资源。它的状态不仅存在于聊天记录、Markdown 文件或专用记忆系统中，也存在于整台计算机之中。

Work 的云端计算机同样具有持久性。但它不是始终运行在一台永久在线的 VM 中，而是将工作区同步至持久化存储，并在需要时恢复到隔离的 microVM 上。因此，底层机器可能会变化，但工作状态会延续。与 OpenClaw 相比，Agent 对这台计算机的主权要小得多。

每项 Work 任务（线程）都在 /workspace/scratch 下获得一个工作目录，在这里 Agent 拥有普通计算机上的自由：它可以创建文件夹、安装依赖、编写脚本、保存数据库，并使用常规 Linux 命令搜索一切内容。

当我要求它为 Acme 制作一份演示文稿时，它可以创建 clients/acme，复制源材料，通过代码进行分析，并创建图表和幻灯片——这些都以该目录中的文件形式存在。当我在同一线程中继续追问时，它会回到这个工作状态并继续编辑。

但当一项任务需要来自其他线程的上下文时，它不会将这些线程的工作目录视为可自由浏览的共享工作区，而是依赖 ChatGPT 产品层。

默认情况下，每个新线程都会收到一份最近任务和已处理文件的压缩摘要。一份摘要可能如下所示：

20260731T15:55 准备 Acme 试点计划：||||
将附上的笔记整理成一份关于 Acme 试点的一页计划，其中包含目标、截止日期和后续步骤。
<<文件名="acme_notes.txt">>

原始对话文本记录并未存储在计算机中供 Agent 浏览。当一项任务需要此前线程的上下文时，Agent 会调用 Personal Context——一个专用工具；该工具通过独立管理的服务查询 Chat 和 Work 历史记录，并返回相关摘录。

文件遵循相同模式。ChatGPT 的 Library 是面向用户的中心化文件及制品仓库。用户上传的文件会自动进入其中；Agent 创建的文件则会在用户要求保存时，或在 Agent 判断其值得保留时保存。Agent 还可以在 Library 中创建目录，以保持内容井然有序。与对话一样，Library 不存在于计算机中，只能通过专用工具访问。

因此，一份上传文件会存在于两个位置：线程内部的工作副本，以及 Library 中的规范版本。有趣的是，两者不会同步。如果线程 A 上传了一个文件，而线程 B 随后修改了 Library 中的版本，当线程 A 恢复时，它仍会读取自己已经过时的本地副本。

在明确指示下，一项任务中的 Agent 可以浏览其他任务的 scratch 目录、查找文件并修改它们。但它不会自行这么做，而且这些目录使用不透明的名称，与其对应对话之间没有可读映射，也没有声明的保留期限承诺。

记忆也由外部管理。正如我此前写过的，ChatGPT 的核心记忆原语是持续运行、综合生成的用户画像。产品会异步维护它，并在任务开始时提供给 Work。Agent 可以据此进行推理，但不能修改它，也不能创建由其他任务默认加载的 OpenClaw 式 Markdown 文件。

ChatGPT 的 Projects 同样延伸至 Work。Projects 将相关对话、常驻指令和 Sources（用户上传的文件）归组。Project 内的一项新任务会获得其指令、相关对话摘要，以及目录中 Sources 的本地副本。但Project 本身并不以计算机中的一个目录形式存在，而 Codex 中的 Project 则是如此。它同样是由产品层维护的一种抽象。

简而言之，Agent 在单项任务内部拥有广泛自由，但跨任务的连续性通过一层具有明确设计取向的 ChatGPT 产品层来实现，而不是通过计算机本身。为什么要这样拆分？我猜测有几个原因：

• Work 构建于既有的 ChatGPT 原语之上（Conversations、Library、Personal Context、Memory）。将这一切剥离出来并在计算机内部重建，意味着要重构一个已经服务十亿用户的技术栈。

• 这种分离是一道护栏。让 Agent 以 OpenClaw 的方式不受限制地访问一个保存着全部文件、对话和记忆的单一环境，对用户而言并不安全。

• 这让 OpenAI 能保有对产品的控制：用户在 UI 中看到什么、上下文如何管理，以及分享、跨设备同步和文件版本控制如何运作。如果 Agent 可以随意改变环境，所有这些都更难构建。

Work 目前缺少的是一个元层 Agent：它运行在单项任务和 Project 之上的更高层级，并负责协调它们之间的关系。(已有一些人以这种方式使用 Codex。) 这或许正在到来，连同其他许多能力一起。Work 仍然很年轻，其架构数周后可能就会大不相同。

今天的 AI 产品仍然是被动响应式的。在模型能够提供帮助之前，你必须先注意到有事情需要完成，收集相关上下文，并将这一切转化为一个 prompt。Agent 从那一步开始可以完成极其出色的工作，但最初的主动行为仍然来自你。主动性（即 Agent 自行判断如何发挥作用）是个人 AI 的圣杯之一。

Work 提供了这一方向的早期一瞥。当你打开一段新的 Work 对话时，除了输入框外，还会看到基于你自身上下文生成的个性化任务。

其中一项建议是帮助我为即将到来的通话做准备。当我选择它时，Work 注入了一条预先撰写的 prompt。它已经异步地在我的上下文中进行了推理：注意到日历事件，判断准备工作会有帮助，从 Calendar 和 Gmail 提取数据，并围绕我记忆中的兴趣和偏好构建任务。当我发送这条 prompt 后，它就开始工作，结果是一份很棒的会议简报——一份我甚至不知道自己需要的简报！

如今，Work 迈出了可信的第一步：它会建议任务。但在我执行它们之前，什么也不会发生。要实现真正的主动性，它必须在无需我参与的情况下，完成它预测我希望完成的任务。这样的未来似乎已经不远。

Automations 让 Work 能在未来某个时间或按照重复计划运行任务，而无需用户手动发出 prompt。它们是 ChatGPT 对提醒事项和 cron job 的抽象。

OpenAI 在 2025 年 1 月将其作为 Scheduled Tasks 推出。Work 在相同调度器的基础上，将其 Agent 化：每次运行都可以使用 Agent 的上下文和工具来完成任务。

它们分为两类。

独立的定时任务每次运行时都从一条已保存的 prompt 开始，并为结果打开一项全新任务。它适合自包含的工作：一次性提醒、一份每日简报、一项每周任务

Editor’s note: I’m excited to welcomeShlok 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.

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.

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.

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.

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 to create, edit, pause, or delete them.

The Scheduled page adds another element of proactivity: ChatGPT suggests custom automations for you. Some, like a Daily Brief, are generic; others, like a weekly recap for the football club I support, are personalized from my memory.

For years, ChatGPT had limited access to the web. It could search, retrieve pages, and use commands like curl to download files or call APIs. But it couldn’t click through an interface, stay logged into a service, or complete workflows like filling a form. ChatGPT first gained this ability with Operator and ChatGPT agent. It then became a core part of Codex and now finds its most integrated expression in Work.

Unlike Codex running locally, the Work browser doesn’t live on the same computer as the agent. Instead, the agent controls a separately hosted Chrome service through tool calls. It can inspect the page, click, type, scroll, take screenshots, manage tabs and dialogs, and move files between the browser and its computer.

On web and desktop, Work shows a replayable timeline of the browser’s past states, so you can retrace what the agent did. You can also take over the live browser to navigate or enter a password, then hand it back to the agent. You can’t do this on mobile yet.

The browser service also keeps its own persistent profile. New browser instances inherit preferences and logged-in sessions: I switched Wikipedia to dark mode and signed into Google in one task, and a fresh task inherited both. The Work agent never sees this profile or its credentials. Instead, a small permission ledger is synchronised into its computer alongside the workspace, recording, globally and per conversation, which sites it may act on and whether it may move files to or from them.

But because the cloud browser runs in a datacenter, and not on your laptop, it faces constraints a local browser does not. Amazon US rejected it as an unsupported “session or client”, and Google Photos repeatedly timed out when I asked it to copy a shared album. Both tasks worked in local mode. Work can attempt a CAPTCHA, but only with your permission, and it is instructed not to loop, rotate its fingerprint, or otherwise evade a site’s safeguards.

Still, the cloud browser makes Work far more capable. It can finish whole classes of tasks that ChatGPT with web search alone never could.

OpenAI has spent years searching for the right primitive to connect ChatGPT to outside apps and services: Plugins (March 2023), GPTs and Actions (November 2023), connectors (June 2025), and apps, the Apps SDK, and the App Directory (late 2025). In March 2026, plugins returned to Codex as packages of apps and skills.

With the July 9 launch, the App Directory became the Plugin Directory, existing apps were packaged into plugins, and the directory expanded across Work and Codex. For now, OpenAI seems to have settled on plugins as the way for Chat and Work to interact with the external world.

A plugin today can contain:

• Apps , which connect the agent to services such as Gmail, Slack, or Salesforce. Most use an MCP server to expose tools : discrete operations the agent can invoke, such as searching messages or sending an email.

• Skills , which combine instructions with supporting material—references, templates, and sometimes scripts—to teach the agent a workflow.

• App templates , which let an organisation configure the private or organisation-specific app a workflow depends on.

Plugins come in three broad types:

1. Operational plugins give the agent Codex-native enhancements. Computer Use lets it operate interfaces; Sites lets it deploy websites; Documents, Presentations, and Spreadsheets let it create interactive artifacts.

2. Role-specific plugins equip the agent for a particular kind of work. The Sales plugin, for example, teaches it to apply 20 skills (Analyze Account Signals, Build Business Case) across 29 apps, including Salesforce and Slack.

3. Service plugins connect the agent to external products such as Gmail, Slack, Notion, Figma, Salesforce, and PitchBook.

Users can also create personal plugins by connecting a custom MCP server and, if needed, adding skills or custom UI. Developers who want to distribute a plugin more widely can submit it to OpenAI; once approved, it is published to the Plugin Directory.

The Plugin Directory already holds more than 1,000 plugins covering most major apps and services, but discovery is a weak link. Work routes tasks to installed plugins seamlessly, yet never suggests a relevant plugin when one is missing. When I asked it to search for flights and hotels, it ignored several available but uninstalled travel plugins in favour of web search, even though a plugin might have used fewer tokens, returned better results, and let me complete a booking directly. Even naming Expedia outright didn’t prompt it to offer the plugin.

I can imagine the product challenges: how does ChatGPT know when to handle a task itself, when to recommend a plugin, and which path serves the user better? And if several can do the job, which should it suggest? Without a solid discovery layer, though, OpenAI is leaving value on the table—for users, for developers, and for itself in its quest to become a platform.

When Work folds into Chat later this year, its design choices will become the default for a billion people. Before then, OpenAI has to resolve a few tensions that kept surfacing as I used it:

1. Does the cloud computer become the user’s primary AI computer? And how can syncing between it and the local machine feel seamless?

2. Do Work agents get more OpenClaw-like sovereignty over that computer? Does ChatGPT keep the opinionated role it plays in continuity, or is there a middle ground?

3. How does Work come to feel as familiar to users as Chat? And in the meantime, how does OpenAI teach Chat users, from within the product and outside it, what Work is for and how to get the most out of it?

None of this should detract from the fact that Work is an impressive, ambitious, yet underrated launch. It consolidates years of scattered products and experiments into one increasingly cohesive whole. And it’s close to the ChatGPT OpenAI would build if it were starting from scratch with today’s agents.

I’m excited to see where it heads next.

I spend most of my time thinking about personal AI: going down rabbit holes like this one, figuring out what the best products are getting right, and imagining what our AI sidekicks will look like a year and five years from now. If you made it this far, we probably think about the same things, and I’d love to hear from you. Find me on X or through my website.