Learn · Article
Define "Done" Before the Bot Starts
Technically finished isn't actually finished — make the bot write the map first.
The bot says “done.”
You open the file. The summary is neat. The tone is calm. Half the checks you care about are missing. Two open questions never got asked. One source was thin and nobody flagged it. You are back in the loop — not because the model is broken, but because “done” was never defined.
Technically finished isn’t actually finished.
Bots often stop at about eighty percent and call it complete because you never told them what “done” means. Borrow the pattern from @Michael_Fenech_ (https://x.com/Michael_Fenech_/status/2105638359137763529): before an important task, make the bot write its definition of done — then compare that map to yours. Especially for research, inbox, coding, reporting, and multi-step routines — anywhere “looks finished” and “is finished” are not the same thing.
We talked a little the other day about correcting a bot versus actually teaching it — fixing this chat after a miss, versus landing a lasting rule. Related idea, different timing: that one’s reactive. This one’s proactive. Put the done-definition on the table *before* the run so you are not correcting an eighty-percent draft all afternoon.
Same desk idea as permission versus capability, too — being able to run a lane isn’t the same as being allowed, and being allowed still isn’t proving the job closed. Permission opens the door. A done-definition is the proof checklist at the exit.
Why “done” at eighty percent won’t work
An eighty-percent finish will keep training you to babysit unless you force a shared map of finished before the work starts.
If you only grade the output after the bot claims complete, you teach one habit: race to a tidy draft, then hope the human fills the gaps. Unresolved items stay quiet. Ask-gates never fire. Evidence of finish is “I produced text,” not “I met the bar.”
Small shops feel it when the inbox helper returns a digest with no parked unknowns. Solo operators feel it when research lands as a summary with no source checks. Households feel it when a multi-step routine marks itself complete while one step still needs a human yes.
The fix is not a louder “be thorough.” The fix is a definition of done — written by the bot, checked by you — before leave-alone work begins.
Make it write the six-point done map
Before the important run, ask the bot to define done. Steal this spine:
1. Outcome it thinks you want.
Plain sentence. What success looks like when the job is over — not “I will try my best.”
2. Specific deliverables.
Named outputs: file, draft, checklist, table, reply set. If it cannot name the artifact, it cannot finish it.
3. Checks before complete.
What it must verify before it is allowed to say done — sources opened, dates matched, numbers looked up, never-lines respected.
4. What would still be unresolved.
Honest leftovers. Blanks it will leave blank. Questions it will not invent answers for.
5. When it should stop and ask.
Ask-gates: money, send, delete, legal, thin source, conflicting facts. Stop lines beat polite guessing.
6. What evidence proves the job is actually finished.
Receipts: which checks passed, which files exist, which items were parked, which asks were raised. “I wrote a summary” is not evidence.
Then compare that map to yours. Edit the gaps. Agree once. *Then* let it run.
Same bots. Different finish line.
Worked example: inbox research that stopped at eighty
Without a done map
You ask for a vendor-thread research pass: who owes what, what is still open, what needs your reply today.
The bot returns a calm summary of the last ten emails. It calls the job done. You notice later: two money figures were guessed from tone, one thread with a blank attachment was skipped without a park note, and nobody asked whether “today” meant business hours or calendar day. Technically finished. Actually unfinished. You spend the afternoon redoing the checks the bot never named.
With the six-point map first
Same request. First the bot writes done:
1. Outcome: a reply-ready picture of open vendor items for *today*, with unknowns parked.
2. Deliverables: a short table (thread · status · ask · next action) plus a parked-unknowns list.
3. Checks: open each named thread; do not invent amounts; match dates to the header; flag blank attachments.
4. Unresolved: anything without a clear number or owner stays on the park list — not filled with a guess.
5. Ask-gates: stop and ask before proposing a payment, a send, or a “we agree” line.
6. Evidence: table file saved; park list non-empty when needed; each row cites a thread id or subject.
You compare. You add one line: “If tracking or attachment is blank, park — do not invent status.” You approve the map. Then it runs.
Same inbox. Different definition of finished. One version stops at a tidy eighty. The other cannot call done without the checks, the parks, and the ask-gates.
Where Grok Bot fits
A quality gate is not “give the desk more autonomy and hope finish quality rises.”
It is: name the important task, force the six-point done map in plain language, compare maps, tighten unresolved and ask-gates, then run. Soft name for the desk: Grok Bot can hold that map on a named helper — description, shared notes, or the first turn of the job — without inventing extra power you did not grant. Setup over spectacle. Done-definition over more leave-alone.
Permission without a finish bar is still a gap. A done map is how the Side Shop desk keeps quality without pretending “can run” means “did finish.”
One line to keep
Define “done” before the bot starts.
Make it write the map — outcome, deliverables, checks, unresolved, ask-gates, evidence. Compare. Then run. Technically finished is not actually finished until that bar is shared.
Your side shop for AI that actually helps the business run — and the household, too.