A project is genuinely stuck — waiting on another team, missing a dependency, two days behind where it should be — and the weekly async update is due. Typing “blocked, behind schedule, need help” feels blunt, so the temptation is to ask AI to “write this up nicely.” What comes back often reads like “made great progress this week” with the blocker mentioned as a minor footnote, because a model asked to phrase something “nicely” will reach for confident, upbeat language by default, regardless of whether the underlying status supports it.
This is a narrower problem than general writing quality. An async update is not a piece of prose to be polished — it is a status signal that other people plan around. A manager reading “on track” allocates their attention elsewhere. A dependent team reading “nearly there” schedules their own work assuming your part lands on time. If the actual status was blocked and the update said otherwise, the cost of that gap shows up later, downstream, in someone else’s plan — not to you first.
Why this happens by default, not by accident
Generative models are tuned on human feedback, and that tuning can push output toward what sounds agreeable rather than what is accurate — OpenAI publicly described and rolled back exactly this drift in an April 2025 GPT-4o update (OpenAI, “Sycophancy in GPT-4o”). Left with a vague or brief input, a model will often fill the gap with generic positive framing rather than flag the gap itself. Ask for “a status update on the migration project” without specifying the actual status, and a model has no way to know whether the honest answer is “on track” or “two weeks behind” — it will produce something plausible-sounding either way, and plausible is not the same as accurate. The failure is not that the tool lies; it is that a vague prompt gives it room to guess in the direction of sounding helpful.
Never let an AI-drafted update round a blocked or behind-schedule status up into language that implies things are on track. If the honest status is “blocked” or “behind,” the update needs to say that plainly, with what is needed to unblock it — softening this for the sake of a smoother-sounding message shifts a real problem downstream to whoever is planning around your update.
A workflow that keeps the status honest
Step 1: State your actual status in plain words, before opening AI
Answer these four questions for yourself, honestly, in your own words, before drafting anything:
- What actually shipped or is done?
- What is blocked, and specifically on what?
- What is next?
- What is your honest confidence level that the next milestone lands on time?
This step matters because it is the only place the real information enters the process — AI can format this well, but it cannot supply the honest answer to “am I actually on track” if you have not stated it first.
Step 2: Ask AI to format, not to editorialize
Turn this status into a clean async update for my team channel:
Shipped: [what actually shipped]
Blocked on: [specific blocker, or "nothing" if true]
Next: [what's next]
Confidence: [your honest assessment, e.g. "on track," "at risk,"
"blocked — need X by [date] to stay on track"]
Keep the tone plain and factual. Do not add phrases implying more
progress or more confidence than what I stated above. If I said
something is blocked, keep that as the headline, not a footnote.
Step 3: Check the draft for spin words
Read the output back and look specifically for language that implies more certainty or progress than your actual status supports:
| Watch for | Ask instead |
|---|---|
| ”Great progress” / “crushing it” | Does this match what I said shipped, specifically? |
| ”Nearly there” / “almost done” | Do I have a specific, honest estimate, or is this vague reassurance? |
| ”On track” (when a real blocker exists) | Is the blocker mentioned first, clearly, with what’s needed? |
| ”Should be fine” | Is this my honest confidence level, or a hope? |
If any phrase in the draft would make a manager or dependent team plan differently than your actual status justifies, revise it before sending.
Step 4: Escalate a pattern, don’t let updates absorb it
If a project has been “at risk” or “blocked” for several updates in a row without resolution, that is a signal worth raising directly — in a 1:1 or a direct message — rather than letting each individual async update quietly carry the same unresolved tension. Preparing your 1:1 agenda covers how to raise a recurring blocker as its own topic rather than letting it disappear into a status line every week.
A useful habit: if your honest confidence level has been “at risk” for more than two consecutive updates, treat that as a trigger to have a direct conversation about the blocker, not just another async update repeating the same status.
Why this is different from meeting notes and 1:1 prep
Async updates share a family resemblance with meeting notes and 1:1 agenda prep — all three involve using AI to structure real information rather than generate it — but the specific failure mode differs enough to call out separately. Meeting notes fail when AI compresses a real discussion and drops accuracy in the process. An async update fails when AI, working from a vague prompt, fills the gap with generic positive tone that was never actually your input. The fix is the same in spirit — supply the real content yourself, verify the output against it — but the discipline for async updates specifically is upfront: state the honest status in your own plain words before AI ever sees the task, so there is no gap left for it to fill with optimism.
This also matters more in async communication specifically than it might in a live conversation, because an async update has no immediate back-and-forth to catch a misleading impression. In a meeting, someone can ask a follow-up question on the spot if a status sounds off. In a written update read later, by someone who was not in the room to ask, the words on the page are the entire signal — there is no tone of voice or hesitation to notice, only the text itself. That makes precision in the text more load-bearing than it would be in a live conversation covering the same ground.
Why plain beats polished here
It is tempting to think a plainly worded “blocked” update looks worse than a softened one. In practice, the opposite tends to be true over time — a consistent pattern of honest, specific updates builds credibility, because people learn your “on track” actually means on track. A pattern of upbeat-sounding updates that later turn out to have concealed a real problem does the opposite: it teaches people to discount your status reports and verify independently, which costs you more trust than an honest “blocked” ever would.
The related trap is treating brevity as the same thing as honesty. A short update can still spin — “blocked” buried at the end of three sentences of unrelated positive framing is technically present but functionally hidden. Say the actual status first, plainly, then add context.
Draft your next update
Use the async update facts card to state your real status before you draft anything, then let AI format it cleanly without adding confidence you did not state. The same say-the-real-status-first discipline applies directly to meeting notes that stay accurate, where the same drift toward smoothed-over optimism can creep into a summary of a decision that was actually still contested.
