Who owns a ChatGPT team task? A rollout guide
This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.
ChatGPT team tasks move recurring work, such as a weekly project update, from one person's calendar to a shared agent that runs on a schedule or when an app event occurs. OpenAI launched them for all Business and Enterprise workspaces at DevDay on 29 September 2026. The Team Tasks admin guide is clear that a task acts through the team's service account, not through the person who wrote it. So the adoption question is less "can it write the update" and more "who answers for it when the update is wrong".
This guide is for engineering leads who want to delegate recurring team work to agents without losing track of ownership. The same questions apply whether the work later moves into Codex, Claude Code or Cursor.
Should your team adopt ChatGPT recurring tasks now?
Adopt them when three things are already true. The recurring output has a reader who acts on it. The sources live in tools your workspace can connect centrally, such as Slack or GitHub. And someone has time to read the first runs closely.
Wait when the work needs a fresh sign-in each time, because unattended runs cannot complete a new app sign-in. Wait also when the output would go straight to customers or production systems. Team tasks can write to connected systems where the tool and connection allow it, and they remain subject to action-approval requirements. That is a control, not a reason to skip review.
Cost is metered on workspace credits. Team spending limits are separate from user limits, so finance and the team owner should agree a limit before the first schedule goes live.
Which account does a ChatGPT team task act as?
This is the part to get right first. A team task uses the team's service account and the app connections configured for the team. There are two kinds:
- Workspace connections use centrally managed company accounts that an admin approves.
- Team connections share one person's individually connected account with the whole team.
The docs warn that connected accounts may reach information a member's own account cannot. A junior engineer in the team can therefore read the output of a task that searched a channel they are not in. Review team membership alongside each connection's resource access, not separately.
Tasks also do not inherit the creator's memories, custom instructions or chat history. Everything the task should know belongs in its instructions, its linked sources, or the team's shared Space. That is good practice anyway: instructions a reviewer can read beat context that lives in one person's head.
Ownership roles and approval points
| Role | Decides | Watch for |
|---|---|---|
| Workspace owner | Who gets Create teams and Create and manage team tasks | Granting both to everyone on day one |
| Workspace admin | Which workspace connections exist and who can use them | Connections with write actions nobody asked for |
| Team owner | Team connections and membership; only this role deletes a team | Team ownership does not grant workspace admin rights |
| Task author | Instructions, success criteria, guardrails, trigger | Vague goals that produce long, unreadable runs |
| Named reviewer (ours) | Whether each run is good enough to share or act on | Runs that nobody opens |
| Compliance or security | Audit review through the Compliance API | Assuming every team, task and connection record is covered |
Every row except the named reviewer follows OpenAI's docs. The reviewer is our addition. The product does not require one, and that is exactly why you should.
What happens when people join, leave or pause a task?
Membership changes carry more weight than they look. New members see all earlier runs and generated files, and individual tasks or runs cannot have separate access restrictions. Members can invite coworkers, and same-workspace join links need no owner approval. Treat a join link like a shared folder link.
Departures need a plan. Team-owned tasks are designed to persist after the creator leaves, but required connections may lose access. Owners must transfer ownership before leaving. Connections the new owner cannot access become disabled for the entire team, which can silently stop a task that everyone assumed was running.
Pausing prevents future scheduled and event-triggered runs. OpenAI says neither pausing nor deleting a task should be relied on to interrupt an active run. If a run is doing something wrong, the fix is at the connection or permission level.
Rollout checklist for the first recurring task
- Pick one recurring output that a named person already produces by hand and someone reads.
- Ask the workspace owner to grant the two permissions to that team only.
- Have the admin approve read-only workspace connections first. Add write actions later, one at a time.
- Before inviting members, confirm everyone may see every past run and file.
- Write instructions with a goal, expected output, success criteria and guardrails. Link task-specific sources.
- Use Run now and review the result in Previous runs before turning the schedule on.
- Name the reviewer and a backup. Write both names in the task instructions.
- Agree who takes ownership if the owner leaves, and test that their access covers every connection.
What to measure in the first month
Measure the review, not the generation. Record how long the reviewer spends on each run, how many runs needed a correction before anyone could use them, and how many runs nobody opened. Add credit spend against the team limit. If review time does not fall after the first few weeks, the instructions or the sources are wrong, and a second task will double the problem.
Our guide to measuring an AI workflow before scaling it explains how to keep those numbers honest. The ownership model underneath is the one in our Delegate, Review, Own method: the agent does the recurring work, and a person owns the result.
Start this week by writing down one recurring report, its reader, and its reviewer before anyone opens the Scheduled page.