A first recurring workflow you want to roll out without surprises
7 days
Run one read-only job by hand before automating anything
Day 1: prove the output
Before the details, the whole week at a glance—so the plan is easy to hold in your head:
- Day 1: run one read-only job by hand and judge the output.
- Days 2–3: repeat it on new inputs; fix instructions, add nothing.
- Day 4: break it on purpose and confirm it stops with a clear reason.
- Day 5: turn on the lowest useful schedule, still delivered as a draft.
- Day 7: review the evidence and decide to keep, revise, or pause.
Today you do the first step only. Pick one job the agent can do without changing anything—research, a summary, a draft—and run it once, manually, over a small input set you can read in full. You are testing the quality of the output, not the reach of the agent.
How to judge it: every claim traces back to a named source, the facts are right, and you can review the whole thing in a few minutes. A failure here is subtle: the brief reads beautifully but one statement points to a source that never said it. Polished prose is not the same as a correct answer, and a confident-but-wrong first run is worse than an ugly one. The trade-off of a small input set is that it can miss edge cases—but it is the only size you can actually inspect line by line, and inspecting closely is the entire point of day one.
Day 2–3: repeat without expanding
Run the same job twice more, each time with fresh inputs. Change only the instructions and the output format; resist adding any new tool or connection. One good run can be luck—consistency across different inputs is the thing you are actually buying.
How to judge it: the format holds, the accuracy holds, and the corrections you make are shrinking rather than repeating. If you are fixing the same mistake on run three that you fixed on run one, the instruction is not clear enough yet. The classic failure of these two days is scope creep: “if it can research this, it could also email it to me.” Every tool you bolt on is another thing that can fail quietly and another variable hiding whether the core job is reliable. Staying narrow feels slow and unimpressive—that is the trade-off—but a workflow you can trust is built by subtracting surprises, not adding features.
Use case: one founder’s first week
Nadia runs a solo analytics tool and wants a Monday market brief drawn from five named sources. The tempting version is to wire it into her inbox and team channel on day one and let it post on its own. Instead she runs the seven-day plan.
Day one is a single manual pass: three of the items are genuinely useful, but one links to a page that does not support the claim, so she tightens the instruction. Days two and three are two more manual runs, and her corrections fall from three to zero. On day four she deletes one source URL to fake a broken feed; the agent reports “source unreachable” instead of quietly dropping it—exactly the behaviour she needed to see. Day five turns on a weekly schedule, Monday 7 a.m. in her timezone, delivered as a dashboard draft rather than a post.
On day seven she reviews the week: six clean items, one correction across all four runs, roughly forty minutes saved. She keeps the workflow—but leaves posting to her channel behind an approval step, because a public post is the one action she cannot take back. The lesson: the week did not make her agent more powerful, it made Nadia sure. She expanded nothing she had not watched work three times.
Nadia’s first week, checkpoint by checkpoint
Illustrative figures from the worked example above—a way to picture a calm rollout, not a customer result.
One read-only pass over an input set small enough to inspect in full.
Fixes shrink as the instructions settle; that downward trend is the signal to continue.
Access to send, pay, or delete waits for evidence, not enthusiasm.
Day 4: test an exception
So far you have only watched the happy path. Today you break it on purpose: delete one of the source URLs, feed an ambiguous request, or point it at an expired connection in a safe setting. Real inputs go wrong eventually, and the first time that happens should not be the first time you learn how the agent reacts.
How to judge it: the workflow should stop and tell you exactly what went wrong—“source unreachable,” “instruction unclear”—not paper over the gap. The dangerous pass is the one that looks fine: the agent fills a missing source with a plausible-sounding guess and hands you a confident answer built on nothing. That is the failure to hunt for, because it is invisible on a good day and expensive on a bad one. Engineering a failure feels wasteful when the week has gone smoothly, but a workflow you will trust unattended has to prove it fails loudly before you look away from it.
Day 5: enable the schedule
Now the job becomes a worker. Turn on the lowest useful frequency—weekly if weekly is enough—confirm the timezone and any quiet hours, and keep delivery as a draft or a dashboard entry rather than anything that leaves your control. A schedule converts a manual test into unattended work, so switch it on only after the manual runs have become boring.
How to judge it: it fires at the right time, in your timezone, and lands somewhere you will actually see it. Two failures are common. The first is over-scheduling: a weekly-worthy job set to run hourly buries you in output until you stop reading it—the same fatigue that makes people rubber-stamp approvals. The second is a timezone slip that fires the run at 3 a.m. and greets you with stale drafts. The trade-off is that a lower frequency gives you slower feedback, but a scheduled job you have started ignoring is worse than no schedule at all.
Day 7: decide what to change
The week was an experiment; today you read the result instead of your enthusiasm. Look back at the accepted outputs, the corrections you made, the times you had to step in, and a rough estimate of the time saved. Then make one decision: keep the workflow, revise it, or pause it. Add write access—the power to send, pay, or delete—only when the evidence asks for it.
How to judge it: three consecutive clean runs with shrinking corrections is a workflow that has earned a small next step; rising corrections or repeated interventions mean you revise or pause, not expand. The failure to avoid is rewarding a shaky week with new permissions because it was “mostly fine”—expansion should follow evidence, not hope. The trade-off is that keeping the job draft-only for another week costs you some automation, but write access is the single hardest thing to walk back, so it should be the last thing you grant and the first thing you can justify.
Try this next
- Pick one read-only job and run it by hand on a small input set—check every claim against its named source.
- Repeat it twice more on fresh inputs; fix only the instructions and format, and add no new tools.
- Break it on purpose—missing source or ambiguous request—and confirm it stops with a clear reason.
- Enable the lowest useful schedule as a draft; after seven days keep, revise, or pause, and add write access only if the runs earned it.
Sources and further reading
These primary references support the article’s approach: roll out in stages, grant the least access needed, design for graceful failure, and measure real outcomes before scaling.
A framework for governing, mapping, measuring, and managing AI risk—the basis for treating week one as a measured rollout rather than a launch.
OWASP GenAI Security ProjectLLM06:2025 Excessive AgencyWhy to grant an agent only the functionality, permissions, and autonomy it needs—support for holding write access back through the first week.
Google PAIRFeedback + ControlGuidance on keeping people in control and designing for graceful failure, behind the day-four exception test.
Google SREMonitoring Distributed SystemsMeasuring user-visible outcomes and meaningful signals—behind the day-seven review of corrections and time saved.
Ready to put one useful workflow to work?
Start with one clear job, a result you can review, and boundaries you understand.
See launch pricing