The 15-minute pre-launch checklist

Run five checks, starting with ownership

Work through five checks in order. Each is a plain yes/no you can answer from the dashboard in a couple of minutes, and together they cover the ways a first launch usually goes wrong. If you are short on time, do checks 3 and 4 first—output and approval are the two that reach outside the dashboard.

Check 1, in full. Start where every other check depends: a single, nameable job and a single owner. “Summarize new support emails into a Monday draft” passes; “help with support” does not, because nothing that vague can be judged right or wrong. Write down who reads the output and what a good run looks like.

Why it matters: an agent with a fuzzy job drifts, and an ownerless result is one nobody notices when it breaks. How to judge it: if you cannot describe the job and name its owner in one sentence each, the workflow is not ready—rewrite the job before touching anything else.

Where it fails: a founder launches a “research assistant” with no defined output. Three weeks later it has produced dozens of documents nobody asked for and nobody reads. The trade-off: a narrow job feels less impressive than a general helper, but narrow is exactly what makes a first launch safe to judge—and easy to trust with more later.

Only the access it needs

Open the workflow’s connections and read them as a list of permissions, not a setup step you already finished. For each one, ask two things: does this workflow actually need it, and does it need to write, or only to read? A summary agent needs to read an inbox; it almost never needs to send from it. Disconnect anything that is there “just in case.”

Why it matters: every connection is a door, and the ones you forget are the ones that cause trouble. Least privilege—granting only the access a task requires—keeps a small mistake small. How to judge it: if you removed one connection at random, would the job still make sense? If several could go without changing the work, the agent is over-connected.

Where it fails: a scheduling helper is granted full calendar and email access because both were offered on the same screen. A prompt it misreads now has a way to email people, not just move meetings. The trade-off: tighter access sometimes means a second, deliberate approval later, when the job genuinely grows—but that beats a capability sitting unused and unnoticed until the day it is misused.

Where the output lands

Follow the result to its destination and picture who is standing there. A draft in a private folder is one audience; a message in a shared channel, a public page, or a customer’s inbox is another entirely. Confirm the exact place the output goes, and every person who can see it, before the first run rather than after.

Why it matters: the content can be perfect and the launch still be a mistake if it lands in front of the wrong people. A wrong audience is not a typo you fix later—once something is seen, it is seen. How to judge it: name the destination out loud and list who has access to it. If that list includes anyone outside your team, treat the workflow as public until you have proven otherwise.

Where it fails: an internal “customer themes” summary is set to post to a shared workspace that quietly includes two contractors and a client. Nothing in the summary is wrong; the audience is. The trade-off: a private draft destination adds a step—someone has to share the result on purpose—but that step is the whole difference between an internal note and an accidental disclosure.

A gate on anything that leaves your control

List every action this workflow can take that changes something outside the dashboard, and confirm each one waits for a person. Four categories deserve a gate every time: sending a message under your name, publishing anything public, moving money, and deleting or overwriting records. Everything else—reading, sorting, drafting—can run freely, because a bad draft costs a glance to fix.

Why it matters: those four actions leave your control the instant they happen, and “undo” is not a real option for a sent email or a refunded charge. How to judge it: for each action, ask whether a reviewer could reverse it in under a minute with no outside consequence. If not, it belongs behind an approval step, not on automatic.

Where it fails: a reminder workflow is left on automatic because the drafts looked good in testing. On launch day it emails a duplicate batch to real customers before anyone reads it. The trade-off: an approval step costs you a moment each run, so spend it only where an undo button does not exist—gating harmless reads as well just trains you to approve without looking, which is worse than no gate at all.

A way to stop, and the go/no-go call

Before you enable anything, confirm you can turn it off. Find the pause control, check that you can disconnect a tool on your own, and decide in advance who you contact if the agent does something unexpected outside the dashboard. A launch without a stop is not a launch; it is a hope.

Why it matters: the value of a checklist is not that it prevents every surprise—it is that surprises stay recoverable. Knowing the off switch before you need it is the difference between a quick pause and a scramble. How to judge it: if you cannot pause the workflow and remove its access yourself, in under a minute and without help, it is not ready to run unattended.

The go/no-go rule. Launch only if every unchecked item has a named owner and a date. If the unresolved item touches money, public communication, deletion, or private data, do not launch—keep the workflow in draft, or in a “review after” mode where you see each run before it acts. The trade-off: holding a launch feels like lost momentum, but a workflow that starts in draft and graduates after three clean runs earns trust far faster than one you switch on fully and quietly turn off after the first bad surprise.