The rendered briefing shows up for review and you end up rewriting half of it — the ask is fuzzy, an assumption is stated as fact when it was really a guess, the one open question you actually had has been smoothed into a confident answer. The instinct is to blame the draft. Usually the problem started earlier: something that needed saying during the session got left for the assistant to reconstruct at the end, and it reconstructed the wrong thing.
The fix isn't a better instruction at draft time. It's four small habits during the session itself — the private work with your own assistant that becomes a briefing once you have it call draft_package. Get these right while you're working the problem through, and the draft that comes out needs a light edit. Skip them, and review turns into a rewrite, which defeats what review is for.
Say the ask out loud partway through, not at the end
It's tempting to let the ask emerge naturally and only state it once the session winds down, as if naming it early would cut the thinking short. In practice the opposite happens: the assistant spends the session not knowing what shape the ending needs, and reconstructs the ask from whichever thread you spent the most words on — not always the thing you actually need answered.
Say it as soon as you know it, even mid-session: "I need a decision on this by Friday," or "I actually just want your read, not a decision." A briefing's ask carries a response shape — decision, opinion, review — and an honest urgency, and both are easier for an assistant to hit if you've stated them once in plain language than if it has to infer them from tone. If the ask changes as you keep working, say the new version out loud too. Restating costs a sentence; a wrong ask baked into a full draft costs a rewrite.
Flag the question you actually don't know the answer to
An assistant under pressure to be useful fills a gap with its best guess rather than leave a hole, smoothly enough that the guess can read like settled fact by the time you see it drafted. If you have a real open question — you don't know whether the vendor will renegotiate, you're not sure the deadline is firm — say so in the moment, not as a caveat for later.
This matters because the assumptions in a briefing aren't decoration; each one is labeled either stated by sender or inferred by sender's AI, and that label is only accurate if the boundary was drawn while it was still true. An assistant that never heard you flag the uncertainty has no way to know it should mark that assumption as an inference rather than treat it as something the two of you already agreed on.
Correct a wrong assumption immediately, not once it compounds
The most expensive kind of rework isn't a wrong sentence — it's a wrong number or fact that got reused. Let the assistant assume the budget is still $10k while you're mid-thought about something else, and that figure doesn't stay isolated: it folds into the options considered, maybe the recommendation, maybe the context brief. By review, fixing the budget isn't a one-line edit; it's tracing every place the wrong number went.
Correct it the moment you notice, even if it interrupts what you were saying. A correction mid-session costs one sentence. The same correction caught at review costs a rewrite of everything built on top of it.
Before it drafts, ask it to show its work
One habit is worth adding as a fixed step, right before you'd normally say "put this together": ask the assistant to list, in plain language, what it's treating as something you said versus something it has inferred. Not the whole draft — just the ledger.
This is the cheapest possible place to catch a miscategorized assumption, because you're correcting a bullet list instead of a rendered paragraph. If something on the list is wrong — it treated a passing thought as something you'd confirmed — you fix it before a single sentence of the briefing exists. Skip this step and the same error surfaces later, dressed up in finished prose, which is harder to catch precisely because it reads well.
What review is supposed to check
None of this replaces the review step, and it shouldn't try to. confirm_send still comes after you've read the rendered package exactly as it will arrive — that moment is where accountability attaches, and no session hygiene substitutes for actually looking. What these habits change is what review has to find: on a well-run session, review means confirming the ask, the labels, and the note are right — a check. On a session where the ask stayed implicit, guesses went unflagged, and an assumption compounded, review means starting over, with the rendered package standing in as a rough draft instead of a final one.
The difference isn't the assistant's skill. The same model drafts both. The difference is what it had to work with.
One thing this doesn't fix
Good session habits catch misrepresentation, not bad judgment. If your read on the situation was wrong to begin with, a perfectly labeled briefing just delivers your wrong read clearly instead of confusing it with a guess — which is still better, but it isn't the same as being right. Worked examples show what a well-built briefing carries field by field, and once the session itself is in good shape, the note you write in your own words is a separate skill worth getting right too.
If you want to see the difference, connect your assistant and notice what review feels like the next time you say the ask out loud early.