Begin with a real repeated task

Do not begin by connecting every account or trying to automate an entire business. Choose one task that occurs at least weekly, takes enough time to matter, and has an output you can verify. Good first examples include preparing an inbox summary, drafting a follow-up from approved facts, organizing documents into a standard folder structure, or checking a website for a defined change.

1. Write the workflow in plain language

If two people would interpret the workflow differently, clarify it before adding automation. Ambiguity becomes harder to spot once software begins moving quickly.

2. Mark the human-only actions

List every step that could create a commitment or be difficult to reverse. Sending messages, publishing, purchasing, changing prices, deleting records, modifying account settings, signing documents, and making regulated decisions should remain behind explicit approval. A first version can stop at a draft or preview and still save substantial time.

3. Prepare the computer

4. Create narrow account access

Use dedicated credentials and least-privilege permissions. Give the system access to one approved mailbox label, folder, calendar, or service role instead of an owner's entire digital life. Store credentials in a password manager, Keychain, or another approved secret store. Never place passwords, recovery codes, private keys, or tokens in prompts, project notes, screenshots, or logs.

5. Decide what stays local

Identify information that should remain on the business-controlled computer, information that may pass through an approved cloud service, and information the workflow does not need at all. Local operation can reduce unnecessary exposure, but connected services still have their own retention and security terms. The local AI privacy checklist covers the questions to ask before connecting data.

6. Test with copies and reversible actions

  1. Run the workflow on sample or copied data.
  2. Compare the result with the expected output.
  3. Test missing information, duplicate triggers, expired sessions, and unavailable websites.
  4. Confirm that a failed run stops safely and reports what remains unfinished.
  5. Repeat the test before allowing any live action.

A successful demonstration is not the same as a reliable workflow. The system also has to behave safely when inputs are incomplete or a connected service changes.

7. Define the operating record

Keep a concise log of when the workflow ran, which source record it used, what it proposed, whether a person approved it, and what the downstream system confirmed. Avoid copying sensitive content that is not needed for troubleshooting. Write a recovery note that a different person can follow if the original builder is unavailable.

8. Review after two weeks

Measure time saved, corrections required, missed edge cases, and how often the approval step changed the result. Expand access only when the evidence supports it. If the workflow produces frequent exceptions, simplify it or return the judgment-heavy step to a person.

Your one-page project brief

Record the workflow name, business goal, trigger, allowed sources, expected output, forbidden actions, approver, completion proof, failure alert, backup location, and owner. That one page is enough to begin a disciplined conversation with a builder. Use the local AI developer buyer checklist to evaluate ownership, security, support, and handoff terms.