Hi Reader,

A clear job description is not yet a working responsibility.

In Part 1, we defined an ongoing job for ChatGPT Dot: the result it should maintain, the workflow it should follow, the sources it may use, the actions it may take, and the evidence that proves completion.

Now comes the more important question:

Can the complete workflow actually succeed—without exceeding the authority you intended to give it?

A responsibility that sounds plausible may still fail in practice.

The Dot may have access to the wrong account. A required computer may be offline. A permission may allow less—or more—than expected. A process that sounds complete may be missing a date, field, filename rule, or verification step.

That is why the next step is not scheduling.

It is making the workflow prove itself.

Start with the actual working environment

We will continue with the fictional workflow from Part 1: Northstar Supply’s Weekly Sales Data Readiness responsibility.

Its Dot retrieves a specified sales report, preserves the original, runs Northstar’s established local import and validation process, and reports whether the data is Ready, Incomplete, Blocked, or Failed.

Northstar, its portal, accounts, and files are entirely fictional.

As we established in Part 1, this workflow crosses two environments: approved online sources and a connected computer running the existing local process.

This time, the question is not what each environment can theoretically do.

It is whether the correct accounts, folders, permissions, and computer are actually available for this responsibility.

Before testing a similar workflow, open the Dot’s profile and review the areas available in your account: connected computers or devices, activity, scheduled work, plugins, permissions, and custom rules.

Then connect only what the workflow actually needs.

Features and interface labels can vary by plan, region, workspace policy, and product release. Confirm the options and permissions visible in your own account.

Qualify access without changing anything

A connection is not proof that a workflow is ready.

The Dot may be able to reach Google Drive but not the intended folder. It may see the sales portal but need a new login. The correct computer may be connected but currently unavailable.

The safest first step is a read-only qualification:

QUALIFY ACCESS

Inspect the answer source by source.

“Google Drive is connected” does not establish that every other dependency is ready.

If login, multifactor authentication, a CAPTCHA, a password, or a security confirmation is required, complete that step yourself. Never paste credentials or verification codes into a prompt.

Turn authority into operating boundaries

Part 1 established an important distinction: access is not authority.

Before testing, turn that principle into specific operating boundaries:

• Access: Can the Dot reach the required source, account, app, website, or computer?
• Permission: Does the connected product allow the intended action?
• Authority: Have you approved that action within this responsibility?

A connected service does not create unlimited authority.

For the fictional Northstar workflow, routine and verifiable actions can be handled differently from consequential or ambiguous ones.

Classify the actions into four categories:

• May proceed without asking.
• Must ask first.
• Must hand off to the user.
• Prohibited.

This prompt makes those boundaries explicit:

DEFINE AUTHORITY

Review the restatement carefully.

Custom rules can reinforce an approved boundary, but they do not create access, expand permissions, or override safeguards.

A useful operating principle is:

Allow independent action only when the work is routine, reversible, verifiable, and clearly within the approved scope.

Decide how problems should stop the workflow

Do not wait for the first failure to decide what should happen.

For the Northstar responsibility, the normal workflow stops if:

• The approved account cannot be confirmed.
• The required report, date, or field is missing.
• A nonidentical file would be replaced.
• The connected computer is unavailable for local work.
• The import fails.
• Dates or record counts do not reconcile.
• The next action exceeds the approved authority.

Stopping safely does not mean discarding everything.

Preserve valid completed work, identify the exact step where the workflow stopped, and report the smallest action required from the user.

The Dot should not report Ready merely because the task finished running.

Ready requires evidence: the correct account and reporting period, an unchanged source file, a successful import, reconciled dates and record counts, and a source-linked summary.

Make the complete workflow pass one controlled test

This is the most important safeguard.

Run the complete workflow once before making it recurring.

Choose a bounded reporting period, remain available for required handoffs, and make it explicit that this is a test—not a schedule.

CONTROLLED FIRST RUN

Do not judge the test only by the final message.

Inspect:

• The source account and reporting period.
• The unchanged source file and its destination.
• The local import result.
• The source and imported dates.
• The source and imported record counts.
• The approval requests and human handoffs.
• The final status and the evidence supporting it.

The test passes only when:

• The result is correct.
• The evidence is inspectable.
• Approvals occur at the right moments.
• Exceptions stop safely and are reported clearly.
• The workflow avoids duplicate or conflicting files.
• The process can be repeated without undocumented intervention.

If the test exposes a hidden dependency or missing rule, fix the responsibility itself and run the controlled test again.

Do not turn a one-time workaround into permanent authority.

Only then make it recurring

After the test passes—or after the specification has been corrected and the revised test passes—create the schedule.

SCHEDULE THE RESPONSIBILITY

Then inspect the saved schedule yourself.

Do not rely only on a confirmation message. Confirm the actual time and time zone, especially if you work across regions or your local time changes seasonally.

Also confirm:

• Whether a connected computer is required and must remain online.
• Where routine updates and urgent handoffs will appear.
• Whether future runs continue in the same conversation or create new ones.
• Where you can inspect task activity.
• How to stop delegated work already in progress.
• How to disable future recurring runs.

Pausing the Dot, stopping the current task, and canceling future schedules are separate controls.

Stopping future work does not undo actions that have already been completed.

Try This Today

Return to the responsibility you defined in Part 1.

Do not schedule it yet.

First, ask the Dot to qualify every required source and destination in read-only mode. Then classify each intended action as:

• May proceed without asking.
• Must ask first.
• Must hand off to you.
• Prohibited.

If you did not complete Part 1, choose one repeated process and perform only this qualification step.

Even if you never automate it, you will understand the process—and its hidden dependencies—more clearly.

The complete guide brings both parts together with the full framework, prompts, testing checklist, and scheduling safeguards:

​Read the complete ChatGPT Dot Guide​

— Mastering AI Team

Make AI work for you