OpenAI DevDay 2026: Choose What Your Team Delegates to ChatGPT

A ChatGPT Team Task does not inherit its creator's personal memories, custom instructions or chat history. It runs in the cloud with the team's service account and configured connections. A request inside a familiar app can therefore become a job with different context. [1]

That detail changes how I read OpenAI DevDay 2026 on 29 September and the separate Intelligent UI announcement on 7 October. [2] [3] My reading: ChatGPT is becoming a conversational work and integration surface, with fewer visible handoffs but several important ones underneath.

For small teams doing client work, I would start with a recurring draft for review, using named sources and an explicit acting account. Choosing that responsibility means knowing where it runs, what confirms completion and whose allowance pays. A convenient place to start work does not settle those questions.

OpenAI DevDay 2026 and October updates, by surface

OpenAI's recap calls ChatGPT a shared surface. CNBC reported Sam Altman's ambition to put editors, dashboards and whole workspaces inside ChatGPT and Codex. That is an announced direction, not evidence it replaces existing software. [2] [4]

The summary below uses announcements and documentation checked on 11 October 2026, not hands-on account tests. DevDay was on 29 September, outside the preceding seven days.

OpenAI says the ads will be labelled, separate from the generated image and will not influence answers. That is a provider policy claim, not an independence audit. Ad measurement does not establish an effect on organic recommendations. [11]

The September sources describe collaborative slides as arriving in the coming weeks, Sol Ultrafast as forthcoming, specialist dots in focused enterprise pilots, and the Decisions API in limited preview. No newer completion evidence was inspected. [2] [5] [6]

Even when a feature reaches your account, its position beside a conversation does not tell you what kind of work it performs.

An interactive answer is a different job from an ongoing task

OpenAI's Intelligent UI examples include a recipe control that changes shopping quantities when the guest count changes. The model composes responses from a library of native, streamable components; a compiler lets the interface appear progressively before the entire response is complete. [3]

The immediate appeal is exploration inside the answer. Change an input instead of asking for another table. This is the interaction OpenAI demonstrates, not evidence from an accuracy test. The October release changes Chat, not the models powering Work and Codex. Conversational GPT-6 Sol is also distinct from Work/Codex's GPT-6.1 Sol. [3] [12]

A plugin extension has different authorship. A developer supplies an app that can open from the sidebar, sit beside a conversation or provide a file viewer/editor. Those are documented application surfaces, rather than controls composed for one model response. [8] A useful control alone does not establish persistent application state or an external integration.

Dots introduce continuing work. OpenAI describes a dot with its own cloud computer and distinguishes read-only proactive research from other actions governed by built-in rules and Custom Rules. Those rules can allow actions, require approval or block them; built-in safety requirements still apply. It would be wrong to call all dot work read-only, or promise every action waits for a person. [6]

For a private calculator or a discardable text draft, I would keep the interaction simple. Background responsibility is a different commitment. A client comment arriving while you are away brings the event connection into the decision.

MCP Events separates receipt from completed work

The proposed Model Context Protocol (MCP) Events extension lets a client subscribe to updates and react without the user being present. Its draft and OpenAI's implementation guide reveal two separate limits: compatible delivery and evidence of completed work. [13] [9]

A protocol name does not supply a shared delivery mode

The MCP working group's design sketch is explicitly a draft proposal. Under its delivery rules, an event type may advertise polling, push or webhook support. None of those modes is mandatory. A client unable to use any advertised mode cannot subscribe to that event type. [13]

OpenAI's guide supports webhook delivery and callback verification, but not polling or streaming. The integration is documented for Work on web, desktop Work with Cloud selected, and dots, subject to workspace controls. [9]

Consequently, a polling-only event type can follow the draft's delivery rules and still be unusable by this ChatGPT integration. That is a compatibility condition derived from the documents, not a server tested here. “Supports MCP Events” is insufficient to establish that your feedback system can trigger the intended work.

A 2xx response answers the receiving question

Under “Handle delivery responses,” OpenAI says a 2xx response acknowledges webhook receipt; ChatGPT processes the event asynchronously. [9] The response code answers a receiving question. It does not show a revised draft, an authorised write or an accepted result.

Take a hypothetical, untested example: a client comments on a brief and asks for a revised paragraph. An event could initiate preparation of client-brief-v2. For that responsibility, I would look for the named draft available to its reviewer, then check the requested change. Receiving the comment is an earlier state. Preparing the output and accepting its content are later ones.

Recovery has its own qualification. OpenAI warns that events can arrive out of order, recommends idempotent writes so repeat calls do not duplicate changes, and says missed non-replayable events cannot be recovered through the protocol. [9] A successful receipt cannot certify the history was complete.

This analysis compares documents. No server was connected or webhook sent during research, and no reliability measurement was made. The proposal may change independently of the integration. Even an available draft leaves another question: which account produced it, using which sources?

Team Tasks change the account and the context

The Team Task guide specifies the team's service account and configured app connections for cloud execution. It asks for task-specific sources and instructions, while excluding automatic inheritance of the creator's personal memories, custom instructions and chat history. [1] Personal dots, by contrast, start with ChatGPT memory and can create memories of their own. [7]

A Team Task is not empty of context. It needs the context for its job supplied explicitly. In the hypothetical client draft, I would name the brief and feedback as sources, rather than expect the task to remember a preference discussed in a personal chat.

The account distinction is equally specific. Workspace connections use company-managed accounts; team connections can share an individually connected account. The guide tells a team owner to confirm which external account each connection uses before scheduling work. Team ownership does not grant workspace-admin permissions. [1]

Before inviting a colleague, the same guide says to review access to earlier runs and generated files, because individual tasks and runs cannot have separate access restrictions. [1] For mixed-client work, that makes the existing contents of the team relevant to the invitation. This is a documented access condition, not an observed leak or a claim of a security defect.

Space and Pages offer shared working artifacts, but a Pro user's page entitlement does not establish Business/Enterprise Team Task access. [2] If a client needs an independently retained deliverable, make that a separate delivery decision; shared access and retained file control is related reading on that distinction.

A separate account tells you who acts. It does not necessarily tell you whose allowance funds the work.

Lower token prices leave another spending boundary

GPT-6.1 Sol's published standard OpenAI API rates are $2 per million input tokens, $0.10 per million cached input tokens and $10 per million output tokens. The Astra comparators are $10, $1 and $50 respectively. Standard input/output prices are one-fifth of Astra's; the cached-input comparison is one-tenth. These are API token rates, not subscription-task prices or an 80% reduction in total work costs. [5]

OpenAI reports near-Astra performance on several evaluations, but says research/API conditions can differ from production ChatGPT. [5] Lower inference prices can reduce that component of cost. The sources do not establish net savings after token volume, tools, failed work, review and app fees. No matched workflow-cost test was performed here.

Delegating through a dot does not remove the usage boundary. OpenAI says dot conversations do not count toward ordinary ChatGPT usage, but the Work/Codex tasks a dot starts or manages count as usual. Deeper dot work has its own included allowance. [6]

Partner apps add a funding choice to sign-in. Current help permits Go, Plus and Pro users to opt into using their plan for eligible AI requests in participating commercial apps, subject to the app's requirements. Those requests consume included Work/Codex usage. The app may still charge separately for its subscription, infrastructure or services. [10]

A weekly per-app limit is a cap on shared usage. It neither reserves capacity nor adds a separate pool. Signing in to a second interface does not create a second allowance. [10]

Usage sharing itself does not expose conversations, memories or an API key; other permissions need separate review. Credit use also requires separate opt-in: a 100% app cap alone does not enable it. [10]

For the recurring draft, I would identify the funding arrangement before calling the task inexpensive. These checks should stay small, though. A more convenient experience loses its point if every harmless request acquires another process.

Contained work may need no extra process

The strongest objection is that these announcements mostly package familiar capabilities more conveniently and lower model prices. Provider-managed controls might already remove enough coordination work. OpenAI's Team Task guide itself asks for expected output, success criteria and connection checks. [1] Adding a parallel system could be wasted effort.

There is a serious data objection too. Improvado's Ivo Petrovic argues that governed, consistent source data becomes the bottleneck for marketing analytics. [14] That is commercially interested analysis, not a productivity study, but naming an acting account cannot repair incorrect spend data. I agree with that limit.

For a private calculator or a reversible draft, I would use the simpler experience. The recommendation here concerns continuing work across connected accounts, shared context or shared usage. Provider-managed infrastructure still does not make an event receipt a completed output, or give a Team Task the creator's personal context. [9] [1]

Use the provider's existing controls for the boundary actually crossed. A manual prompt or existing workflow remains reasonable when work is infrequent, event delivery is incompatible or access is unconfirmed. Broader controls around computer-using agents are adjacent reading, not a requirement to build another layer for every draft.

Repeated client feedback is a narrower candidate: useful work can stop before anything is sent.

Make the first recurring task a draft for review

OpenAI's task instructions ask for explicit sources and an expected output. [1] My starting choice, where ongoing work is available, would be one client draft with a clear review point. Here is an illustrative, untested brief for the same comment-to-draft example:

Use the named client feedback and current brief to prepare client-brief-v2 for the project lead. Show the requested revision and leave unresolved questions visible. Stop at a draft ready for review. Do not send or publish it.

That choice follows from the documented boundaries. Check a compatible trigger, the configured source account and explicit task context; identify the reviewable output and the allowance owner before treating it as a continuing responsibility. [9] [1] [10] This is editorial advice, not evidence the example ran or saved time.

If there is no named draft, completion remains unconfirmed. If account eligibility is unconfirmed, so is the ongoing workflow's availability. A manual draft remains an option without new task access. The useful starting point is a responsibility you can explain before and after it runs, with sending still outside its scope.

Share this dated availability summary with a teammate before choosing your first recurring ChatGPT task.

---

References

[1] OpenAI, "Set up and manage teams and Team Tasks." https://learn.chatgpt.com/docs/enterprise/teams . Living guidance checked during research on 11 October 2026. Documents cloud execution, configured accounts, task-specific sources, excluded personal context and access to historical runs. Not evidence of a privacy incident or an observed task.

[2] OpenAI, "DevDay 2026 Recap," published 29 September 2026. https://openai.com/index/devday-2026-recap/ . Event baseline, collaboration entitlements, identity announcement and preview promises. Checked during research on 11 October 2026; launch wording does not establish completed account rollout.

[3] OpenAI, "GPT-6 and Intelligent UI for everyone," published 7 October 2026. https://openai.com/index/gpt-6-for-everyone/ . Provider examples and component mechanism, Chat-only release and announced rollout timetable. Checked during research on 11 October 2026. The Free/Go model announcement conflicts with the current Help listing in reference 12.

[4] CNBC, "OpenAI DevDay recap: AI lab rolls out Dots agents, Altman and Friar comment on IPO." https://www.cnbc.com/2026/09/29/openai-devday-2026-live-updates.html . Independent keynote reporting, specifically the plugin-extension ambition. Checked during research on 11 October 2026. Captured live-entry labels differ from the September 29 URL and photo captions; the primary recap supplies event chronology.

[5] OpenAI, "Introducing GPT-6.1 Sol." https://openai.com/index/introducing-gpt-6-1-sol/ . Published API prices, Work/Codex/API availability and vendor evaluation caveats. Announced in the September 29 recap; no standalone publication dateline was visible in the capture. Checked during research on 11 October 2026.

[6] OpenAI, "Introducing dots," published 29 September 2026. https://openai.com/index/introducing-dots/ . Provider description of cloud work, read-only proactive research, action rules, usage accounting and specialist pilots. Checked during research on 11 October 2026. No provider anecdote is used as a verified customer outcome.

[7] OpenAI Help, "Getting started with your dot." https://help.openai.com/en/articles/20001530-getting-started-with-your-dot . Living guidance checked during research on 11 October 2026 for gradual availability, plan-specific region restrictions, enterprise beta controls and personal-dot memory. Its relative update label is not treated as a launch date.

[8] OpenAI Developers, "Plugin Extensions." https://developers.openai.com/plugins/build/extensions . Living build guidance checked during research on 11 October 2026. Documents developer-authored surfaces, forthcoming Free/Go web extensions and desktop-only composer mentions; not universal installed-app availability.

[9] OpenAI Developers, "MCP Events." https://developers.openai.com/plugins/build/mcp-events . Living implementation guidance checked during research on 11 October 2026. "Before you start," "Handle delivery responses" and "Manage subscriptions" establish supported surfaces, webhook-only delivery, receipt before asynchronous processing, ordering and replay limits. No delivery experiment was performed.

[10] OpenAI Help, "Using your ChatGPT plan in other apps and sites." https://help.openai.com/en/articles/20001542-using-your-chatgpt-plan-in-other-apps-and-sites . Living account guidance checked during research on 11 October 2026. Separates identity, optional Go/Plus/Pro partner usage, shared caps, app fees, data permissions and credit opt-in. Not evidence of net savings or universal app eligibility.

[11] OpenAI, "Building advertising for the way people use AI," published 5 October 2026. https://openai.com/index/new-chatgpt-ads-format-and-measurement/ . Upcoming US Free/Go visual-ad test and attributed labelling/answer-independence policies. Checked during research on 11 October 2026; not an audit of organic ranking, ad independence or campaign performance.

[12] OpenAI Help, "GPT-6 and other models in ChatGPT." https://help.openai.com/en/articles/20001354-gpt-6-and-other-models-in-chatgpt . Living model guidance checked during research on 11 October 2026. Documents Intelligent UI effort/device exclusions and distinguishes conversational models from GPT-6.1 Sol. Its Free/Go GPT-5.6 Luna listing conflicts with reference 3's announced GPT-6 Luna expansion; no cause or reconciled rollout history was established.

[13] MCP Triggers and Events working group, "MCP Events Design Sketch," draft proposal dated 19 February 2026. https://github.com/modelcontextprotocol/experimental-ext-triggers-events/blob/main/docs/design-sketch-proposal.md . Independent protocol-maintainer artifact checked during research on 11 October 2026. "Summary" and "Listing Available Events" permit optional delivery modes and require a compatible advertised mode. The document date is not proof of its last revision. Draft status does not establish final adoption or tested cross-client interoperability.

[14] Ivo Petrovic, Improvado, "OpenAI DevDay 2026: What the Announcements Mean for Marketing Analytics Teams," published 8 October 2026. https://improvado.io/blog/openai-devday-2026-marketing-analytics . Commercially interested analytics commentary checked during research on 11 October 2026. Used for the governed-data opposing explanation, not as independent validation of OpenAI benchmarks or productivity outcomes.