Before you ask AI to act, define what done means
Give AI a clear goal brief: outcome, constraints, evidence and a review owner. A worked onboarding example and reusable template for founders.
Before you ask AI to act, define the outcome, the constraints and the evidence that will show the work is done. A useful goal brief describes a change someone can verify. It also says what the system may do, what it must leave alone and who decides when the result is good enough.
“Sort out onboarding” is an instruction. It leaves the finish line open to interpretation. Does it mean write a checklist, send a welcome email, create accounts or confirm that a new employee can actually start work?
That ambiguity matters before you choose an AI tool. A polished output can still solve the wrong problem. At Always Running, the starting discipline is simple: give the work a destination before adding more execution.
Describe the change, not just the document
Start with the person who needs the result. What should they be able to do afterwards? What prevents that today? A document is useful only insofar as it helps make that change happen.
For example, “produce an onboarding checklist” names an output. “Make sure a new starter knows their first-week priorities, has an accountable contact and has a verified path to required access” describes an outcome. The second brief exposes several dependencies that a checklist alone can hide.
Then separate preparation from execution. Asking AI to prepare an access list is different from authorising it to create accounts. Do not leave that difference buried in an assumption about what “sort it out” means.
A worked goal brief
The following is a hypothetical teaching example. It is not a customer case study or a reported Walter result. The deadline and checks are illustrative choices.
Imagine a small professional-services business expecting a new project coordinator on Monday. Its operations manager wants a usable preparation pack by Friday afternoon. The first trial uses a fictional starter, so the team can inspect the process before introducing personal information.
| Field | Example brief |
|---|---|
| Outcome | The manager can see what is ready, what is missing and who owns each remaining onboarding action. |
| Deadline | Prepare the draft pack by Friday at 2pm for manager review. |
| Inputs | Use the current approved role description, onboarding policy and access checklist. Identify each source and its date. |
| Allowed work | Draft the pack, compare required items with supplied evidence and flag gaps. |
| Constraints | Do not create accounts, change permissions or send messages. Do not invent missing policy or assume access has been tested. |
| Evidence of completion | Every item has a source, owner and status; unverified items are labelled; the manager has reviewed the pack. |
| Stop condition | If sources conflict or the current policy is unavailable, return the specific question to the manager. |
This brief is deliberately modest. It does not promise that AI will onboard someone independently. It creates a useful, bounded unit of work and a clear point at which a person checks the result.
Make “done” hard to misread
Write acceptance checks as things a reviewer can observe. “High quality” is difficult to inspect. “Each access request names the system, role, owner and supporting policy” is concrete. “Everything complete” is vague. “Unverified access is listed as unverified” makes a missing fact visible.
Do not ask the system to mark its own guess as evidence. A generated statement that an account is ready is not a successful login test. Record the source of the claim and distinguish a proposed next action from an action someone actually completed.
Also make room for an honest partial result. A pack that clearly exposes three missing inputs may be more useful than a complete-looking pack that fills the gaps with assumptions.
Copy this goal brief for your next task
We want [person or team] to be able to [observable outcome] by [time]. Use [approved inputs]. You may [permitted actions]. Do not [excluded actions]. Treat [important uncertainty] as unknown until verified. Return [deliverable] with [evidence]. Ask [owner] when [specific trigger]. We will call this done when [acceptance checks] pass.
Read it as if you had just joined the business. Could you tell what the task is for? Could you explain when to stop? Would two reviewers reach roughly the same conclusion about whether the work passed?
Test the brief before expanding the task
Use one small example and inspect the result against the checks. Note which instructions were misunderstood and which inputs were missing. Improve the brief before increasing the volume or extending permissions. The goal is to find ambiguity while the cost of correcting it is small.
This is an operating method, not a guarantee that a prompt can enforce access restrictions. Use the actual permissions and controls available in your tools as well as clear instructions. The founder still owns the outcome and the boundaries.
For your next AI task, spend five minutes defining the finish line. Then ask for the first test, not the whole business.
Explore Always Running: visit AlwaysRunning.ai to learn more.
