Let ChatGPT Work help without giving up control

Outcome

Choose a recurring check, the sources it may read, and the draft or next step you want it to prepare. Review the result before approving further action.

A bounded proactive system knows its sources, cadence, permitted actions, stopping conditions, and owner. It can return “no change” when nothing deserves attention. It also leaves enough evidence that another person, or a fresh task, can understand what happened.

Proactivity is an explicitly configured pattern, not proof that any particular account supports scheduled tasks, connected applications, background monitoring, or unattended work. Confirm the available capability and obtain approval before activating it.

When to use it

Use bounded proactivity when a workstream has recurring signals and a predictable safe response: reviewing an intake queue, spotting unanswered requests, preparing a meeting packet, checking whether a deliverable is stale, or advancing the next internal step in a documented workflow.

It works best when inputs have a canonical location and the next step can be made reversible and reviewable. Keep the human closer when the work involves ambiguous ownership, legal or personnel judgment, sensitive data, external communication, publication, spending, access control, or irreversible changes.

Do not automate a process merely because it occurs often. First make sure that a competent person can explain the process, exceptions, and proof of completion.

Operating pattern

Define a compact control loop:

1. Detect: Read only the named sources and identify eligible signals.
2. Verify: Confirm currentness, ownership, and whether the signal has already been handled.
3. Prioritize: Rank by consequence, deadline, dependency, and reversibility, not by how alarming the language sounds.
4. Advance: Take one bounded internal action, such as drafting, organizing, calculating, or assembling evidence.
5. Review: Present the result, sources, uncertainties, and proposed next action to the accountable human.
6. Close or checkpoint: Record what changed, what remains, and when the loop should run again.
7. Reflect: Capture repeated corrections as a candidate improvement to instructions or a Skill.

Set a work-in-progress limit. One completed, reviewable intervention is usually more valuable than six partially explored opportunities. A scan that finds nothing actionable should say so and stop.

Treat a heartbeat as a bounded check-in, not permission to watch everything. Name one task or source, its cadence, expiry, owner, and stopping condition. Prefer one controller for a workstream, keep owner lookup separate from the running scheduler, and write a fresh receipt for each run. A prior receipt may explain history; it cannot prove the current source or authorize a new action.

Screenshots, an active application view, and computer-history context are optional and capability-dependent. Use them only when the person explicitly approves the application, question, and time window; never expand into unrelated activity, background collection, credentials, or private conversations.

Copyable implementation

# Proactive loop contract

Objective: Keep [workstream] moving without external or irreversible action.
Owner: [human role]
Cadence: [manual / daily / weekly / event-triggered]
Expiry or stop condition: [exact time, completed decision, or user stop]
Existing-owner lookup: [approved workstream registry]

Canonical sources:
- [source and what it proves]
- [source and what it proves]

Eligible signals:
- [specific condition]
- [specific condition]

Allowed actions:
- Read and organize source material.
- Draft an internal artifact for review.
- Advance at most one explicitly authorized, reversible step named in this contract, including its target and scope. If that approval is missing, return a draft or proposed next step only.
- Create a checkpoint when the work cannot finish safely.

Always require approval for:
- Sending or posting messages.
- Publishing or deploying.
- Changing access, permissions, or records.
- Spending money or making commitments.
- Destructive or hard-to-reverse changes.

Output:
- Signal found, or "no change."
- Evidence and currentness.
- Existing owner and duplicate-check result.
- Run receipt, observed time window, and approval state.
- Action taken.
- Open questions and risks.
- Approval-ready next step.

Stop when:
- Ownership is unclear.
- Sources conflict or are stale.
- The next action crosses an approval boundary.
- The intervention limit has been reached.

Example

For example, a strategy team reviews a weekly request queue. The loop finds three open items. One is already answered in the canonical tracker, one has no named owner, and one has a deadline in two days with all required inputs present.

ChatGPT Work ignores the completed item, flags the owner gap without assigning it, and advances the third item by assembling the relevant sources and drafting an internal recommendation. It does not send the recommendation. Its output identifies the deadline, links the evidence, labels one assumption, and asks the accountable manager to approve or revise the draft. The scan closes with one intervention and a clear no-action explanation for the other two.

Approval boundary

Read and prepare only within the scope the user has approved. Urgency never expands authority. A looming deadline may change prioritization, but it does not authorize an external message, a production change, a financial commitment, or a deletion.

Write the boundary in operational terms. “Use good judgment” is not a control. “Draft the reply, cite its sources, and wait for approval before sending” is.

Validation

Test the loop with normal, empty, duplicate, stale, conflicting, and urgent inputs. Confirm that it:

• Uses only named sources and reports their currentness.
• Uses one explicitly approved heartbeat or controller with a real stop condition.
• Finds the responsible owner rather than silently becoming the owner.
• Selects no more than the permitted number of interventions.
• Separates detected requests from actions actually completed.
• Produces a useful “no change” result.
• Stops before every approval-gated action.
• Leaves a checkpoint that a new task can resume.

Review false positives and missed signals after several runs. Adjust the signal definition before increasing autonomy.

Failure modes

Common failures include treating every unread item as work, confusing urgency with permission, scanning indefinitely, creating duplicate tasks, reusing stale receipts, inspecting the scheduler from inside its own run, and producing activity without a decision-ready result.

Another failure is “helpful” ownership drift: ChatGPT Work starts filling gaps that belong to a named person or team. Prevent this by requiring an owner field and a stop condition for unclear ownership. Finally, do not reward the loop for always finding something. A trustworthy system is allowed to conclude that nothing needs intervention.