Put an Agent to Work

A chat is a conversation you have to show up for. An agent is a job that runs whether you show up or not. That is the whole difference, and most operators never cross it — they get good at prompting and stay stuck re-typing the same request every week. The cross isn't technical. It starts by being honest about which of your tasks is actually a recurring job wearing a one-off costume. Take Dana, who runs a 4-person brand & marketing studio: every week she re-pastes the same raw client-kickoff notes into a chat and asks for them rewritten as a branded project recap — that's a recurring job, not a one-off. You can't automate what you can't describe, so before any tooling you write the job down the way you'd hand it to a new hire on day one: here's the trigger, here's what you'll need, here's the steps, here's what done looks like. If you can't write that page, the task isn't ready — and that's a finding, not a failure. Note on load: this opening module is the heaviest in the course (you're picking the right job AND writing it down), so it's budgeted at ~9 minutes. Every module after this one is shorter — the work compounds, the effort doesn't.

• →You will name three recurring jobs in YOUR business that currently die in a chat window, and pick the one with the highest weekly time-cost to convert into an agent.
• →You will write a one-page job brief (trigger, inputs, steps, output, done-looks-like) for that task that a fresh assistant could execute without you in the room.

Do thisOpen the job you do most by pasting the same thing into ChatGPT or Claude every week — the way Dana re-pastes client-kickoff notes for a recap. Time yourself doing it once, by hand, with a stopwatch. Write the minutes and how many times a week you do it. Then fill the one-page Job Brief template against THAT exact task — not a hypothetical, the real one you did this week. Submit the brief plus your before-time log.

Every job an agent can do is one of four shapes, and the shape tells you how to build it, how to test it, and how it fails. Fetch jobs gather — a Monday competitor-price pull, a digest of overnight form fills. Transform jobs convert — Dana's client-kickoff notes into a branded project recap in her studio's format, raw reviews into a tagged list. Decide jobs judge against your rules — is this new inbound lead worth a callback for a 4-person studio's capacity, does this invoice need a flag. Route jobs deliver — file this, reply to that, escalate the other. The shape isn't trivia. A Transform job is graded on format fidelity; a Decide job is graded on whether it matches the call you'd have made. Name the shape wrong and you'll test for the wrong thing and trust an agent that's quietly broken. So you name it, then you spec it the way that shape demands — including where it breaks, because the edge cases are where unattended jobs go silently wrong.

• →You will classify your chosen job into one of four shapes (Fetch, Transform, Decide, Route) and explain in one sentence why it is that shape and not another.
• →You will redraw your job brief as a shape-specific spec — adding the inputs, the pass/fail check, and the edge cases that shape demands — so the build step has no ambiguity left to invent.

Do thisTake your Module 1 brief and run it through the Four Shapes decision tree in the worked example. Tag your job: Fetch, Transform, Decide, or Route. Then rewrite your brief in that shape's template, and list at least two edge cases where a naive agent would get YOUR job wrong. Submit the shaped spec.

Trust is a result, not a setting. You earn it by trying to break the thing on purpose, on your own data, before you ever leave it alone. The mechanism is a single-point check: one rule that makes a run unambiguously right or wrong — 'every project recap ends with the three next actions in the studio's format,' 'no lead is flagged worth-a-callback without a stated budget and timeline.' Vague standards produce vague trust, and vague trust is how operators end up rubber-stamping garbage. The part that matters most is what you do when a run fails: you don't shrug and fix it by hand, you fix the INSTRUCTIONS so the next run is right. That loop — catch, correct, re-run — is the actual skill. An operator who can redirect an agent owns it. An operator who can only watch it is renting overreliance.

• →You will build a single-point check for your job — one explicit, testable rule that tells you a given run passed or failed — and run your agent against it on three real inputs.
• →You will redirect the agent at least once: catch a failing run, write the correction into the agent's INSTRUCTIONS (not by hand), and re-run until it passes — so you have evidence you can DIRECT it, not just watch it.

Do thisBuild your agent (platform of your choice — the worked example uses a project-style agent, the same one Dana stands up for her studio's recap job, but the spec is portable) and feed it three real inputs from your actual business. Score each run against your single-point check: pass or fail, no maybes. When one fails — and one will — diagnose why, edit the agent's INSTRUCTIONS to fix it, and re-run that input until it passes. Submit a log of all three runs showing the before/after on the one you corrected.

A job you have to launch by hand is still a chore with extra steps. A skill is a job that fires on its own and lands the result where it belongs while you do something else. The move from one to the other is a trigger — a clock, an inbound email, a new row, a single saved command you run on a fixed beat — plus proof it works without you in the loop. For Dana, the trigger is a clock: the recap agent fires the morning after every studio kickoff call and drops the branded recap in her inbox before she's at her desk. Three clean unattended runs is the line: one could be luck, three is a system. And the last piece isn't technical, it's ownership: you write down who owns this task now and how many hours a week it just gave you back. That note is the receipt. It's what turns 'I learned to use an agent' into 'I installed one,' and it's the thing that's still true after the course is closed. This is your Execution gate — and it feeds the track capstone, where you'll bundle it with the rest of your installed role. You build it once, here; the capstone assembles it, it does not rebuild it.

• →You will move your verified agent onto a trigger so it runs on its own (a schedule or an inbound event) and capture timestamped proof of three successful unattended runs.
• →You will write a one-paragraph accountability-transfer note stating who owns this job now (the agent, on what cadence, with what human-check fallback) and log the hours it gives back per week.

Do thisPut your verified agent on a trigger — a scheduled run, an email/form hook, or a saved one-click job on a fixed cadence (Dana's runs on a clock after each kickoff call) — and let it run three times without touching the output mid-run. Screenshot or export each run with its timestamp. Then fill the Accountability Transfer note: owner, cadence, fallback if it misbehaves, and weekly hours recovered (Module 1 before-time minus the new near-zero, × frequency). Also record a 60-90s screen capture of one run firing and producing its result. Submit the three timestamped runs, the screen recording, and the note.

<h3>The Superman moment is exactly where the trap springs</h3><p>You just shipped a system that does a job without you. That is real. Take the win. Now — before the week refills — this is the one question worth asking: where does the time go?</p><p>The treadmill's only move is to ask for that hour back. More capacity. A faster output. Triple the work behind the same screen. The Jevons trap doesn't wait for you to invite it; it moves the moment you look away.</p><h3>Log the real number first</h3><p>The automation you just built is a measurable multiple — not a story, not an estimate. Before-time minus after-time, times weekly frequency. That is a real number. Go to your Inflection KPI from Earn the Shorter Week and log it there. Recompute the multiple.</p><p>Then name one place this specific recovered hour goes this week. A real customer. A real idea. An hour off the screen. The agent earned you an hour. Decide who gets it before the default does.</p>

• →You will update your Inflection KPI with the real hours your new automation just bought back — and decide, on purpose, where that time goes before it refills.

Do thisTake the task your new automation now runs. Log the real before/after minutes into your Inflection KPI, recompute the multiple, and write the one place this specific recovered hour goes this week.