OpenAI DevDay 2026: Codex and the AI Work Revolution — From Solo to Team Collaboration

At DevDay 2026, Jason from OpenAI's developer experience team shared a fundamental shift in AI collaboration: we're moving from a "single-player" to a "multiplayer" model. This isn't simply about giving each person a more powerful AI assistant — it's about enabling entire teams and AI agents to work together within the same system.

From "What Can I Do with AI" to "How Do I Bring the Whole Team Along"

Jason candidly shared that over roughly seven months at OpenAI, as his own productivity soared, he noticed a growing problem: he had become the "glue" between all systems — and the bottleneck in the workflow. Many developers in the audience could relate to the feeling of being micro-managed after being "armed" with AI tools.

He mapped out three stages in the human-AI relationship: first, "What can I do with AI?"; then, "What can AI do once it has access to my computer, files, browser, and apps?"; and now, the critical question — "How do I build systems that bring the rest of my team along, rather than just amplifying my own capabilities?"

For Jason, multiplayer collaboration isn't about opening more chat windows or pulling colleagues into the same thread. It means: I'm no longer the only one who has to carry work from start to finish. Conversations across the team can be automatically picked up and followed through by AI, forming a system where everyone — and every agent — is seamlessly connected.

Act One: Bringing Context into the Agent

Jason framed his talk around a hypothetical scenario: at 8 a.m., he spots a complaint on Twitter about rate limits, but has no idea what happened or whether anyone is investigating. Six months ago, he'd have had to manually dig through Slack with Codex, piece together information, and run everything on his own machine — with himself still doing all the pushing.

He highlighted a feature called app shot. It's not just a screenshot — it captures the full context of an application: metadata, URLs, and content below the fold. He said it was the first time he felt like he could "@" an AI from inside any app. At one point, roughly 30% of all Codex sessions were initiated via app shot. The core idea: let the agent "meet you where you are."

But a new problem emerged: the more app shots he used, the more threads he pinned, the more heartbeat automations he set up — he was still the one grinding at 3 a.m. The real turning point came with something called dot — a persistent, proactive agent that continuously absorbs context from incoming messages, emails, and replies in the background, without him having to maintain "15 pinned automations plus a memory store plus a bunch of markdown files that never get updated."

Act Two: Making Agents More "Embodied"

Jason placed particular emphasis on the concept of embodiment. After an app shot is sent to the cloud, dot has its own computer, browser, and files in the cloud — it can independently investigate issues even when your machine is off. Yet it still "meets you where you are" — you can check in on its progress from your phone or browser at any time.

Going further, even though dot runs in the cloud, once authorized, it can reach back and control your local machine. Jason described this as "enhanced remote control": an investigation might start on your computer, you follow along on your phone, and mid-way through, dot might ask, "I need to log into the browser — are you logged in? Can I access your machine? There's a local app to check — can I test it on your device?"

Voice was another prominently demonstrated input method. Jason noted that most people speak three to four times faster than they type, and the biggest advantage of voice is that "you can be really messy and let the AI clean it up." This spans from one-way dictation to two-way agentic voice, all the way to multi-person meeting scenarios — where dot automatically transcribes conversations in the background and picks up action items. He gave a real example: in a meeting he casually said, "I think it might be guardian mode — I saw a Slack message from someone whose name starts with T — also check the feature flag config, cache updates, and compare a few PRs." He'd never have typed that out, but dot could take it all in.

At the end of the meeting, he assigned action items to both the team and the agents: use the Slack connector to DM two specific people to confirm they understood a change; once they replied, post back to the main channel; use the browser to reach four people online to collect feedback IDs. Agents were also given distinct identities and could be directly @ mentioned in Slack or Teams, creating a landscape where "your dot, my dot, and eventually a team dot" work in concert.

Act Three: Organizing and Sharing Information with the Team

Bringing context in is only half the battle — information still needs to be organized, kept current, and shared. Jason was candid about what went wrong before: all his automations and workflows were locked on his local machine, which meant teammates couldn't contribute, and more powerful cloud agents couldn't be leveraged. He argued that software engineering is highly productive precisely because agents can collaborate on a single source of truth — and knowledge work has always lacked that layer.

The solution is space: agents create pages from templates, share them with teammates and their respective agents, and move what was previously a local memory store into the cloud. Even more critical is page instructions — essentially an "AgentMD file" for a document that defines how custom components, embedded HTML, and visualizations should be updated by agents, ensuring that when multiple agents collaborate on a document concurrently, they don't corrupt its structure.

Automations can be defined not just at the individual dot level, but at the page or team level as well. He walked through several real use cases: a finance team uses cloud agents to automatically update analytical reports weekly; an engineering team uses them to organize all PRs, project scope, and identify DRIs (Directly Responsible Individuals); a research team uses them to track long-running experiments; and Jason himself used a space to delegate almost everything for DevDay — the talk, slide updates, booth logistics, and mod retros.

---

「Single Source of Truth (SSOT)」 is a classic principle in software engineering: a team maintains exactly one authoritative record for any given piece of data or state, and all people and systems read from that single record, eliminating inconsistencies between multiple copies. A Git repository for code, or a database for business data, are textbook examples. Jason's point is that knowledge work has long lacked this mechanism — meeting notes are scattered across individual notebooks, decision context is buried in personal Slack threads and emails, and automation scripts run only on someone's local machine. The combination of space and page instructions attempts to fill this gap: page instructions function like CODEOWNERS or CI configuration files in a code repository, defining update rules and structural constraints for documents so that multiple agents writing concurrently don't produce conflicts or formatting chaos — giving knowledge bases the engineering-grade property of being truly collaborative and trustworthy.

「DRI (Directly Responsible Individual)」 is a management concept popularized by Apple, referring to the single individual who bears ultimate responsibility for a given task or decision, preventing the "collective responsibility equals no responsibility" trap. When an agent automatically identifies DRIs while organizing project scope, it's not just aggregating information — it's also helping clarify accountability on the human side.

---

From Delivering Results to Becoming a "Plugin Hero"

Once work is done, it still needs to be delivered. An ideal incident investigation ultimately produces a space: a timeline, a report, feedback IDs collected online, plus links and citations to the relevant conversations, so teammates know what to trust. And when it comes to actual delivery, a PR is never the finish line — there are still retrospectives, demos, and blog posts.

Most of these are handled by instruction-based plugins. Jason sees rules and automations as "keeping work moving," while plugins and extensions are the next step: shareable, updatable, versioned, and able to be rapidly distributed to the entire team when improved. With plugin extensions, you can even build custom interfaces directly inside the Codex app, turning it into a "unified cockpit" — OpenAI's own meeting product and code review product are both built on the same component system. He also mentioned capabilities like WebMCP, which allow websites to expose authenticated MCP servers, building tools that both humans and AI can use.

Jason believes the next phase isn't about deploying more agents or more tokens — it's about investing in systems that let automations, plugins, and skills be shared across the team, becoming a collective responsibility. The goal is to become the company's "plugin hero."

Let AI Do the Laundry, Let Humans Create

This methodology isn't limited to engineering. Jason also uses dot and space to manage production shoots, content planning, and more: when he's slammed on set, dot pushes him updates in the gaps; when inspiration strikes, he just "shouts into the void" and later receives a draft website, presentation, or proposal.

He referenced the widely circulated quote — "I want AI to do my laundry and dishes so I can make art." In his view, he's gradually getting better at distinguishing which tasks are "laundry" and which are "art." Over these past months, he's actually had more time to collaborate with research, creative, product, and marketing teams. He admitted that in 2026, it's easy to fall into the trap of "coding alone with an AI agent until 3 a.m.," but that's not interesting to him — he joined a company to get things done with great people. When teammates and agents can pick up the baton and nobody has to be the "glue" anymore, collaboration itself becomes a joy again.

---

Background Notes

「Embodied (具身化)」 is a term borrowed from cognitive science and robotics, originally referring to an agent that has a physical body and interacts with its environment through a perception-action loop. In the context of AI agents, embodiment is extended to mean: the agent doesn't just passively answer questions — it has a persistent "digital body" consisting of an independent computing environment, browser, file system, and access to external services, enabling it to actively sense environmental changes and take continuous action. This is fundamentally different from traditional "stateless" conversational AI, which forgets everything once a session ends. An embodied agent maintains state between sessions, autonomously monitors events, initiates actions, and doesn't require a human to manually trigger it each time. The dot Jason describes is the realization of this concept — running continuously in the cloud, constantly absorbing context, and able, with authorization, to extend its "arm" into the user's local machine, creating seamless agentic capability bridging cloud and local.

MCP (Model Context Protocol) is an open protocol designed to standardize how AI models communicate with external tools and data sources — analogous to USB for hardware peripherals. Any MCP-compatible tool can be called directly by any MCP-compatible model, without requiring a custom integration layer for each model-tool pair. Jason's WebMCP is its web-side extension: websites can expose an authenticated MCP server on the server side, allowing AI agents to access the site's features and data with the same permissions and context as a human user. The significance of this is that it naturally extends the boundary of tool capabilities from "things humans can operate" to "things both humans and agents can operate," without requiring websites to redesign their APIs specifically for AI — dramatically lowering the barrier to integrating agentic workflows with the existing web ecosystem.