From a Slack message to an ongoing responsibility
Connecting a channel opens a conversation. Reliable recurring work needs an explicit assignment, an update policy, and a stopping procedure.
A channel is a place to communicate
ChatGPT and supported messaging channels let you communicate with the same dot. The documentation describes continuity of relevant context while visible conversations remain in their respective channels. That continuity can help with a responsibility that starts at a desk and continues on a phone. It also makes audience boundaries important: information useful for reasoning is not automatically authorized for disclosure in a team conversation.
As checked on September 29, 2026, the enterprise guide describes Microsoft Teams as an invite-only alpha, even though general messaging documentation discusses Teams more broadly. Texting is described as coming soon. Treat those as availability constraints when choosing a delivery channel. A rollout plan should use a destination confirmed in the intended account and workspace, with a documented alternative if access is unavailable.
Turn a request into a responsibility
An ongoing assignment needs a subject, authoritative inputs, and a result someone can inspect. “Watch our launch” leaves the boundaries unclear. “Review these approved launch records for changed dates, maintain this internal decision list, and ask me when a dependency lacks an owner” gives the dot a more specific job. Include what it should do when the source is missing or two records disagree.
In an illustrative launch-coordination workflow, the dot prepares a decision list and links each entry to the source. Routine corrections stay in that list. A deadline conflict goes to the named owner through the agreed channel. This keeps the notification destination separate from the working artifact. It also lets a reviewer inspect whether the assignment is producing useful decisions instead of a stream of repetitive status messages.
Choose a schedule only when timing matters
The tasks documentation says dots can decide when to pause and resume follow-up work. Fixed-time recurring work uses a saved schedule. If you need a predictable review, specify the task, frequency, time zone, end date, and delivery destination. Ask the dot to confirm what was saved and inspect the schedule. A casual phrase such as “check this later” may not express the operational timing your team expects.
For example, an illustrative instruction could request a weekday review at 9 a.m. Central for four weeks, with notifications only for unresolved decisions or changed deadlines. The time zone matters when colleagues work elsewhere or daylight-saving transitions occur. An end date prevents a pilot from quietly becoming a permanent obligation. Review the actual saved schedule before treating it as part of a service commitment.
Monitoring requires its own scope
Adding a dot to a Slack channel does not establish an ongoing monitoring task. State which source to watch, what events or changes matter, and when the dot should alert someone. Event-based monitoring depends on support in the connected service. Ask the dot to confirm the events it can follow instead of assuming every visible message or business event is a supported trigger.
Separate signal detection from action. A new issue might justify preparing a summary, but closing the issue, contacting a customer, or changing a deadline may need additional authority. Define the permitted response for each important condition. Include a noise policy: repeated identical findings should not create an unbounded volume of messages that makes the channel less useful for the people supervising it.
Review the actual output
Open Activity to inspect delegated tasks and results. A task marked complete is evidence that a run ended, not proof that every business requirement was satisfied. Look for the requested artifact, its sources, unresolved errors, and the delivery destination. An empty report may mean there was nothing new, or that the required source was inaccessible. The workflow should distinguish those situations visibly.
Use an operating log for accepted changes and unresolved exceptions. It need not be elaborate: a dated checklist or existing project record can work. The purpose is to make recurring work understandable outside the private conversation. When a new owner takes over, they should be able to see what runs, why it runs, and what conditions require their attention.
Stop each kind of work deliberately
The controls documentation separates three operations. Pause stops the dot's current main task. Delegated tasks are inspected and stopped in Activity. Future scheduled runs are disabled or deleted in Scheduled. Ending a call does not necessarily stop the responsibility you assigned. Stopping work also does not reverse completed actions, so inspect what already happened before deciding whether a correction is needed.
Practice this procedure during the pilot and after a meaningful workflow change. The acceptance record should include a normal run, an exception, and a confirmed stop. A recurring responsibility is ready for broader use when its owner can explain both the expected result and how to end the work without leaving unexpected tasks or future runs active.
The source record
Sources & editorial notes
Primary documentation checked September 29, 2026. Our implementation recommendations are editorial analysis. Illustrative workflows are proposed examples, not completed client case studies or performance claims.
- Message your dot OpenAI
- Tasks and memory OpenAI
- Control your dot OpenAI
- Manage dots permissions and capabilities OpenAI
Found something that needs updating? Contact the editorial team with the passage and a supporting source.