Chief of Staff

Outcome

Spend less time piecing together updates from different projects. A Chief of Staff workflow gives you one home base to review priorities, follow-ups, and the decisions that need you while each project keeps its owner.

This is an optional way to organize work in ChatGPT Work, not a separate product that turns on automatically. Start with a manual review of sources you approve. Add scheduled checks only when the tool supports them and you explicitly approve the schedule.

Keep four responsibilities distinct:

• Detect: find real requests, changed plans, and commitments in approved sources.
• Incubate: find the existing owner and prepare one bounded next step for review.
• Collaborate: follow one active conversation only when you explicitly ask, for an agreed time.
• Reflect: learn from completed work and propose a useful improvement.

You get a clear next step, its supporting source, and an honest status. Finding a request does not mean the work has started or finished. You still verify the sources and approve consequential actions.

Chapter 5 describes the personal home-base experience. This chapter describes the four-role coordination pattern behind it. Chapter 7 supplies the permissions and stopping conditions. None of these patterns grants product access, creates an automation, or authorizes external action.

When to use it

Use the loop after individual workflows are already reliable. A team with unclear sources or no verified owner should fix those foundations first. Begin with a manual review queue before enabling any schedule.

If scheduling is available and approved, combine Detect and Incubate in one weekday check. Use Collaborate only for a named conversation, owner, and agreed time window. Review completed work with Reflect on Friday or when you ask; keep it separate from checks for new requests.

Not every request needs every role. A no-change detection run should not manufacture a task, and an item with an unclear owner should stop for review.

The one-time work brief is a manual starting exercise. Its Collaborate step prepares a handoff once; it does not start the time-limited conversation check described below.

Operating pattern

Use one weekly home-base task, one approved source map, and at most one scheduled weekday check (the intake controller):

1. Start with a current run record. Verify the allowed time window, approved sources, active controller, and human owner.
2. Detect. Read only the named sources and attach current evidence to each real request.
3. Check continuity. Look for the existing workstream owner without creating duplicates or treating a stale summary as proof.
4. Incubate. Prepare an approval-ready next step, or perform at most one specifically authorized internal action.
5. Record the result. Distinguish detected, blocked, waiting, review-ready, and actually advanced work.

Collaborate is started separately by the user when one active task needs one bounded conversation monitored. It defaults to reading or preparing text for review and expires when its purpose or time window ends. Reflect happens separately on Friday or on request and uses completed run records rather than scanning new sources.

Optional overnight work is a separate approved plan, not an exception to daytime safeguards. Name the exact objective, resources, allowed actions, stop condition, and morning output; do not execute until a person approves that specific plan.

Copyable implementation

# Chief of Staff run contract

Home-base task: [one existing weekly task]
Cadence/window: [when and what period]
Approved sources: [explicit list]
Routing rules: ignore | watch | review | act
Owners and escalation path: [roles]
Existing-owner lookup: [approved task or project registry]
Allowed internal action: [one explicitly authorized, reversible step]
Approval-required actions: [explicit list]

## Output
- Signals with source, date, owner, confidence, and reason
- Existing-owner decision and duplicate check for each signal
- Review-ready next step or one verified internal action
- Separate detected, actually advanced, blocked, and waiting states
- Verified completion evidence or named blocker
- No-change receipt when appropriate
- Friday or on-demand Reflect proposal, never a silent change

Keep a fresh run receipt for every wake. Do not run independent schedules for each role, ask the controller to inspect itself during a scheduled wake, or reuse yesterday's evidence to authorize a new action.

Example

For example, a team receives a request to update its monthly forecast. Detect verifies the request in an approved source and records the deadline. Incubate checks the project registry, finds an existing forecast task, and prepares the relevant source list instead of opening a duplicate.

The Chief of Staff reports one request detected and one review-ready next step. It does not claim that the forecast changed. If a person explicitly authorizes a bounded continuation, the next run records the action actually taken and leaves the request open until the project owner confirms the result.

If clarification is needed, the user may start a temporary Collaborate session for that one conversation. On Friday, Reflect reviews the completed receipts and proposes a narrower routing rule. No message is sent and no live source changes without approval.

Approval boundary

This Chief of Staff pattern is not blanket authority or a promised standalone product feature. Installing a Skill, configuring sources, authenticating connectors, granting permissions, scheduling runs, and activating a workflow are separate steps with separate evidence.

Default authority is read-only inspection and a review-ready recommendation. Any internal task advancement needs its own scoped authorization. Require explicit approval for outbound messages, commitments, calendar responses, publication, deployment, purchases, access changes, destructive actions, policy changes, and decisions assigned to a person.

Collaboration does not transfer authority merely because context was handed off. Overnight execution never follows from installing a plugin, approving a prior run, or leaving a plan unanswered.

Validation

Test the modules independently before testing the loop:

• Detect returns traceable signals and valid no-change results.
• Incubate finds the existing owner and rejects unclear or duplicate work.
• A scheduled run performs no more than one specifically approved internal action.
• Collaborate stays within one owner, one conversation, and one approved time window.
• The receipt separates completed, review-ready, blocked, and detected-only state.
• Reflect uses completed evidence and proposes changes without applying them.
• An overnight plan remains inactive without exact human approval.

Then run scenarios for stale sources, unavailable connectors, duplicate signals, conflicting owners, missed deadlines, unauthorized requests, and no material change. Confirm the system fails closed and leaves a recovery path.

Failure modes

The largest risk is confusing coordination with authority. A system that can detect a deadline should not automatically commit a person to it. A conversation relay should not strip away caveats or impersonate its owner.

Other failures include several controllers writing conflicting state, repeated scans creating duplicate work, a scheduler querying its own running task, reflection silently rewriting policy, and counting detected requests as completed work. Broad source access also increases privacy and security risk.

Keep one canonical registry, stable run identifiers, and an explicit owner for each state transition. If a module cannot verify source, permission, or ownership, it should stop, preserve evidence, and request review.