It does not explain who can fire a task or whether each run gets a permission check, and that gap is now the main governance question.
Summary
OpenAI announced ChatGPT Spaces, shared workspaces where coworkers, ChatGPT and its Dots personal agents use the same files and generated material. Spaces are for Pro, Business and Enterprise subscribers. OpenAI is also bringing @ChatGPT into Slack and Microsoft Teams for Business and Enterprise, has extended Dots so they can delegate to Codex and edit Scheduled Tasks, and documents Team Tasks, which run in the cloud under a team service account. Taken together, these make the team, not the individual user, the unit an agent acts for.
What happened
According to the lead report, Spaces keep files uploaded by colleagues next to material generated in ChatGPT, and Dots agents can draw on the same shared information. Spaces are for Pro, Business and Enterprise subscribers. Rollout starts on desktop and web, with mobile later. A macOS meeting plugin writes notes, summaries and action items into a Space. It reaches Pro and Business first, with Enterprise to follow, and OpenAI says captured audio is deleted once the notes are generated. Separately, Business and Enterprise users will be able to @-mention ChatGPT in Slack and Teams channels, DMs and threads. Connections to external tools need administrator or user permission. Pages, collaborative slides and shareable profiles were also reported.
The Verge's coverage of DevDay on September 29, 2026 describes Dots as always-on assistants that work in the background across connected apps. Dots are limited at first to Pro, Business Premium and Enterprise. OpenAI also added a $500-per-month Pro tier, reopened the $200 tier with new limits, and reported 1.2 billion weekly users.
An OpenAI community post adds four things. Dots can now be created from the mobile app. They can start or continue Codex threads. They draw on ChatGPT conversations, Codex threads and automations. And they can review and edit recurring Scheduled Tasks. The post states no plan requirements for these features.
OpenAI's Enterprise documentation describes Team Tasks as shared workflows that run on a schedule or in response to an event. Its examples include a Friday update on what shipped and what is blocked, and an onboarding brief prepared when a deal closes. Team Tasks run under the team's service account with configured app connections, and administrators control who can create teams and manage their automations. None of the sources gives Spaces pricing, broad availability for Team Tasks, reliability data, or the permission limits of Dots.
What the archive adds
The archive shows how the shared surface grew in stages. A Telegram post (qwgai) recorded Shared Projects reaching Free, Plus and Pro users, with shared chats, shared files and shared instructions. Context was shared, but a person still started every action. The ChatGPT release notes then describe Codex cloud tasks that each get an isolated workspace and keep running while the user's computer sleeps, with the managed workspace's Codex cloud-access settings applied. That is background execution under rules set by the workspace. OpenAI's own "Introducing dots" post (dossier d2) gives continuity as the reason for Dots: always-on agents that learn a user's preferences, carry context between ChatGPT, Slack and Teams, and work toward goals in the background. The Team Tasks help article (d3) is the key document for this take. It says tasks run in the cloud under a team service account, use admin-approved company connections, and can be triggered by activity such as a Slack message. A CNBC DevDay recap (d1) is in the archive, but its excerpt is too short to add facts beyond the Dots launch.
Trend signal
The pattern has three steps. First came private chat. Then came shared projects, where context was shared but a person triggered every action. Now there are shared Spaces with background agents and team-owned automations, where context is shared, machines can trigger actions, and the work runs under a non-human identity. Each step makes it easier to start work and widens how far that work can reach. Putting @ChatGPT inside Slack and Teams fits the same pattern: the agent goes to the channels where work already happens, and those channels become places where tasks can be triggered. Our read is that the product is shifting from answering questions to running work, and running work brings the questions that every shared service account brings: which identity, which scopes, which triggers, and which audit trail.
Why now
1) Continuity as the reason for the product. OpenAI's Dots post (d2) presents always-on agents that carry context across ChatGPT, Slack and Teams, and shared context only becomes useful once agents can act on it. 2) Turning context into managed work. Team Tasks (d3) put scheduled and event-triggered workflows under a team service account with admin-approved connections, which turns ad-hoc chats into recurring jobs that a team depends on. 3) Tiered pricing. According to The Verge, Dots launch only on Pro, Business Premium and Enterprise, alongside a new $500-per-month Pro tier, so agent features are being used to set the plans apart. 4) Distribution. Per the lead report, @ChatGPT in Slack and Teams brings the agent into channels workers already use. Those channels are also where activity can trigger tasks (d3).
Connections to other events
Follow d3 one step further. If a Team Task runs under a team service account with admin-approved connections, its reach is set by that account, not by the person who wrote the task. If activity such as a Slack message can trigger that task, a second question follows: can everyone who can post in that channel cause a run that reads systems they could not read directly? The sources do not answer this. They do not say who is allowed to fire a trigger, whether triggers can be limited to named people or channels, or whether a run checks the permissions of whoever triggered it. That makes this a conditional risk, not a reported leak. If triggers are open to the whole channel and there is no check on each run, the trigger audience can end up wider than the data audience, and the summary posts back where everyone can read it.
Dots add a second layer. According to the community post, a Dot draws on its owner's ChatGPT conversations, Codex threads and automations, and per the lead report it can also use a Space's shared information. None of the material explains how personal and team context are kept apart when a Dot answers in a shared place.
Meeting notes add a third layer. The audio is deleted, but the summaries and action items stay in the Space, where the next scheduled task or Dot can likely use them as input. So Space membership works in practice as access to everything the Space's agents have turned into text.
For comparison, more mature sharing models usually separate the right to use a shared assistant from the right to edit it, keep individual chats private within a shared project, and warn users that sharing an agent also shares its connectors. Our material does not show whether OpenAI documents anything like this for Spaces, Dots or Team Tasks. What the sources do show is that admins control who can create teams and automations, and which connections they use. That is a control on who sets things up, not on each run.
Why it matters
For builders: the work that matters is now scoping, more than prompt writing. Treat each Team Task as a small service. Give it an owner, a least-privilege service account, an explicit set of triggering channels or events, and a written list of the sources it may read. Pick triggers in channels whose members could already read every one of those sources. For buyers: before rolling out Spaces and Team Tasks widely, ask OpenAI four direct questions. Who can trigger a task? Is the triggering user's access checked on each run? What does the audit log record for each run? How are a Dot's personal sources kept out of shared replies? Get the answers in writing, because the public material we reviewed does not contain them. If the answers are weak, keep Team Tasks in small, closed channels, and keep meeting notes out of Spaces with mixed membership.
What happens next
- OpenAI will document controls on who may trigger a Team Task or which channels may trigger it, or a per-run permission check, beyond workspace-level admin permissions. (6 months, 60%). Watch for: Help-center or Enterprise release notes adding trigger allowlists, per-Space connector scoping, or per-run audit logs for Team Tasks.
- A security researcher or press report will describe content crossing a permission boundary through a ChatGPT Space, a Team Task or a @ChatGPT reply in Slack or Teams. (12 months, 35%). Watch for: A published write-up showing a user obtaining Space or connector data through a triggered task or channel mention that they could not access directly.
- Dots will be offered on ChatGPT Plus or Free plans. (6 months, 30%). Watch for: OpenAI release notes listing Dots availability for Plus or Free.
Limits and uncertainty
Our material is partial. OpenAI may already offer trigger allowlists, connector scoping per Space, or audit logs for each run, and the documentation we have may simply not show them. Comparison findings on other vendors' sharing models were not in the dossier, so the comparison above is general, not specific to any vendor. Team Tasks appear in Enterprise documentation, but their broad availability is not established. Business Premium, which The Verge names for Dots, is not clearly the same as the Business plan named for Spaces. We have no reliability data. If adoption stays limited to top tiers, these questions will come up later and for fewer organisations.
Skill to build now
Learn to treat agent automations as non-human identities and threat-model them that way. First exercise: take one report your team writes by hand, such as the Friday shipped-and-blocked update, and write it as a Team Task spec with four fields: trigger, service account, connectors with read and write scopes, and output audience. Then list everyone who could fire the trigger, and mark anyone who could not read one of the sources directly. Each person you mark is a design flaw to fix before the task goes live.
Reader takeaway
If you run ChatGPT Business or Enterprise, take an inventory before enabling Team Tasks. For each planned automation, record the service account, each connector and its scope, every channel or event that can trigger it, and who can read the place its output goes. Approve a task only when everyone who can trigger it could already read every source it uses, and hold off on the rest until OpenAI documents per-run checks.
Open question
When a Dot draws on both its owner's private Codex threads and a shared Space, and then answers in a Slack channel, whose permissions should decide what it reveals: the owner's, the Space's, or the narrowest permissions of anyone who can read the reply?