Spot the shift
Move from describing activity to naming the business outcome.
A practical business-training workshop
Recurring Work → Automate
Turn one repetitive workflow into a clear, reviewable agreement your agent can execute—with the right context, boundaries, and human judgment.
See the contract
Walk the Fathom intake case study from trigger to success check.
Build yours
Draft each contract piece directly with your agent in your own OS.
Set autonomy
Choose Read, Draft, Coordinate, or Act—and define approval.
Test + commit
Run one safe test, inspect the result, and choose the next repetition.
Presenter cue
Open with: “You do not need to automate your business today. You need one trustworthy contract for one recurring result.” Ask attendees to keep their OS and agent chat open beside this screen.
The whole process · Seven stages
From recurring work to a safe automation.
A dependable automation is built as a learning loop—not a single leap from idea to action.
Notice recurring work
Choose the business outcome
Write the Automation Contract
Detailed breakdown nextStart with the safest autonomy mode
Test and observe
Review what happened
Increase responsibility only with evidence
Contract = map
The Automation Contract makes the outcome, route, boundaries, checks, and recovery explicit. It guides the automation; it is not the automation itself.
Presenter cue
Trace the seven stages left to right. Pause at stage 3 and say: “This is the map we will learn to write. The automation comes later, after the map can survive a test.”
Next, we’ll sharpen the shift from recurring activity to an observable business outcome—then unpack every part of the contract.
01 · Reframe the work
Stop automating activity.
Contract for an outcome.
Activity language
“Check Fathom every day.”
Describes motion, not value. It leaves relevance, routing, and “done” undefined.
Outcome language
“Every qualified new call becomes an owned next action by 10 a.m.”
Defines a result the business can observe, inspect, and improve.
Automation is not “make it run.” It is “make the expected result, judgment, and recovery explicit.”
Observable
Someone can tell whether the result happened.
Bounded
The agent knows where its authority begins and ends.
Recoverable
When reality differs from the happy path, work lands safely.
Presenter cue
Ask for one recurring task from the room. Rewrite it aloud as “When X happens, Y is true by Z.” Point out that this is an operating promise, not a software feature.
02 · The Automation Contract · 1 of 2
Define the work.
1
Outcome
What it means
The business result that must be true—not the activity performed.
Question to askWhat becomes reliably true when this works?
Fathom exampleBy 10 a.m. each day, every new qualified call has a concise brief and a clearly owned next action.
Help me rewrite this recurring task as an observable business outcome. Use: “When [event] happens, [result] is true by [time].” Challenge vague activity words and ask only what you need to make success measurable.
2
Trigger
What it means
The event or schedule that starts the workflow.
Question to askExactly when should the agent begin—and what counts as new?
Fathom exampleAt 8:30 a.m. each weekday, find calls created since the last successful run.
Define a precise trigger for my workflow. Identify the event or schedule, timezone, how to prevent duplicate runs, and what “new” means. Return one trigger statement plus any assumptions.
3
Context
What it means
The business rules and background needed to make sound judgments.
Question to askWhat would a capable teammate need to know before deciding?
Fathom exampleKnow our ideal client profile, active clients, offer names, team owners, and what “qualified” means.
Interview me for the minimum business context a capable teammate would need to run this workflow. Separate durable rules from case-specific facts, and flag anything ambiguous or sensitive.
4
Steps
What it means
The smallest dependable sequence from trigger to finished output.
Question to askWhat must happen, in order, and where is judgment required?
Fathom exampleCollect → classify → extract decisions/actions → match owner → draft brief → route for review.
Turn my current process into the smallest dependable sequence. For each step, state the input, transformation, output, and judgment call. Remove steps that do not contribute to the outcome.
5
Tools & Sources
What it means
The approved systems and source-of-truth hierarchy the agent may use.
Question to askWhere can the agent read, write, and resolve conflicting facts?
Fathom exampleRead Fathom transcripts and CRM ownership; write a draft brief in The AI Surfer OS; do not edit the CRM.
Map the tools and sources for this workflow. Label each as read-only or writable, name the source of truth when data conflicts, and identify required access that has not been confirmed.
Presenter cue
Pause after each card. Taylor pastes the matching prompt into chat; participants answer there. The goal is a useful first draft, not perfect documentation.
03 · The Automation Contract · 2 of 2
Define the guardrails.
6
Output
What it means
The exact deliverable, destination, structure, and level of detail.
Question to askWhat should arrive, where, and in what format?
Fathom exampleA six-line brief: call, category, summary, decisions, actions with owners/dates, and open questions.
Specify the output contract for this workflow: exact format, required fields, destination, naming, tone, and maximum length. Include one compact example that is easy to inspect.
7
Approval Rule
What it means
The boundary between what the agent may do and what a human must confirm.
Question to askWhich consequences require a human decision?
Fathom exampleDraft briefs automatically. Taylor approves before any client message, task assignment, or record change.
Design an approval rule for this workflow based on consequence, reversibility, confidence, and external visibility. State what the agent may do alone and what must pause for named human approval.
8
Success Check
What it means
The evidence that proves the outcome happened correctly.
Question to askHow will we know this run is complete and trustworthy?
Fathom exampleEvery new call is accounted for; owner/date match the transcript; no unsupported claims; review queue delivered by 10.
Create a lightweight success check for every run. Include completeness, accuracy, timeliness, and one quality signal. Make each check observable without rereading the entire source.
9
Failure Path
What it means
What happens when data is missing, confidence is low, or a tool fails.
Question to askHow does the workflow stop safely and make recovery easy?
Fathom exampleDo not guess. Label the issue, preserve the transcript link, add it to the exception queue, and notify Taylor.
Write the failure path for this workflow. Cover missing input, conflicting facts, low confidence, duplicate data, and tool failure. For each, define safe-stop behavior, notification, and recovery information.
10
Starting Mode
What it means
The lowest autonomy level that creates value while earning trust.
Question to askWhat is the safest useful first version?
Fathom exampleStart in Draft: prepare the daily brief and exception list; Taylor reviews and acts.
Recommend a starting autonomy mode—Read, Draft, Coordinate, or Act—for this workflow. Explain the choice using risk and reversibility, then define what evidence would justify moving up one level.
Presenter cue
Emphasize that Approval Rule, Failure Path, and Starting Mode are not red tape. They are what let a useful automation survive real-world ambiguity.
04 · Case study
From new call to owned action.
New calls
Find recordings since the last successful run.
Transcripts
Extract intent, decisions, commitments, and uncertainty.
Qualify + route
Apply ICP, client, offer, and ownership rules.
Daily brief
Create review-ready actions with source links.
Human review
Taylor approves consequences; exceptions stay visible.
3 new calls · 2 qualified · 1 exception
Northstar discovery — Qualified. Proposal requested. Taylor owns draft by Thu. Source attached.
Acme client sync — Decision: move launch to Oct 12. Morgan owns timeline update. Approval required before client confirmation.
Untitled recording — No participant identity. Held in exception queue; no action created.
- Every call accounted for
- Claims trace to transcripts
- Ownership rules are explicit
- External actions pause
- Exceptions remain visible
Using the Automation Contract we drafted, simulate one run on a representative example. Show the output, the checks you performed, any assumptions, and anything that would pause for approval. Do not take external action.
Presenter cue
Trace one call across the arrows. Ask: “Where could this quietly go wrong?” Convert answers into context, approval, success, or failure rules.
05 · Set the agency level
Earn autonomy one rung at a time.
Move up when…
Outputs are consistently accurate, exceptions are caught, the action is reversible, and the owner understands the failure modes.
Move down when…
Rules change, source quality drops, consequences grow, errors repeat, or nobody can explain why the agent chose an action.
Presenter cue
Starting low is not timid; it shortens the learning loop. For Fathom, begin at Draft. “Act” is a promotion based on evidence, not enthusiasm.
06 · Use judgment
When not to automate yet.
The process is unstable
The steps change every time because the team has not chosen a standard.
The volume is trivial
Automation costs more to build and monitor than the repetition costs to do.
The signal is unreliable
Inputs are incomplete, inaccessible, or too inconsistent to support decisions.
The stakes are too high
A mistake is harmful, public, legally sensitive, or difficult to reverse.
Judgment is tacit
The expert cannot yet explain how good decisions differ from bad ones.
No owner exists
Nobody will inspect quality, handle exceptions, or update rules.
First simplify. Then standardize. Then document. Then automate.
Stress-test whether this workflow is ready to automate. Evaluate stability, frequency, input quality, consequence, reversibility, explainability, and ownership. Recommend: automate now, run manually with a checklist, or redesign first—and explain why.
Presenter cue
Invite one “not yet” example. This is a win: identifying a bad automation candidate prevents expensive confusion and reveals the operational work needed first.
07 · Participant build sprint
Build one contract live.
Choose the repetition
Frequent, annoying, observable, and low-to-moderate consequence.
4 minFrequent, annoying, observable, and low-to-moderate consequence.
Name the outcome + trigger
Paste prompts 1–2. Make “done” and “start” precise.
6 minPaste prompts 1–2. Make “done” and “start” precise.
Supply context, steps, and sources
Paste prompts 3–5. Separate facts from judgment.
9 minPaste prompts 3–5. Separate facts from judgment.
Set output + guardrails
Paste prompts 6–10. Choose the starting autonomy mode.
8 minPaste prompts 6–10. Choose the starting autonomy mode.
Simulate one real case
No external actions. Inspect the output and exceptions.
5 minNo external actions. Inspect the output and exceptions.
Revise one weak rule
Fix the ambiguity most likely to cause a bad run.
3 minFix the ambiguity most likely to cause a bad run.
Act as my Automation Contract editor. Review the full contract for ambiguity, missing ownership, hidden assumptions, unsafe authority, and weak success checks. Ask at most three high-value questions, then return a revised contract and a safe first test.
Presenter cue
Run a visible timer. Announce each transition and circulate. At minute 27 say: “Simulation, not activation.” At minute 32 ask everyone to improve exactly one rule.
08 · Close the loop
Your next repetition is the real test.
Before you switch it on
- The outcome is observable and time-bound.
- The trigger cannot silently duplicate work.
- Sources and write permissions are explicit.
- Approval matches consequence and reversibility.
- Success can be checked without redoing the work.
- Failure stops safely and reaches an owner.
- The starting mode is the lowest useful autonomy.
Next steps
- Run one representative case in simulation.
- Compare it with a strong human result.
- Revise the weakest contract rule.
- Run three supervised repetitions.
- Review evidence before raising autonomy.
Start with one outcome. Make the contract clear. Let trust compound.
Turn my final Automation Contract into a three-run pilot plan. For each run, define the test case, human review point, evidence to capture, and go/no-go criterion. Keep all external actions behind approval until the pilot is complete.
Presenter cue
Close by asking each person to say: workflow, starting mode, and when they will run the first test. Remind them the contract is a living operating document.