In this analysis
A prepared draft, an attempted operation and a completed external action require different completion signals.
Proactivity made status semantics more important
Shared Claude memory expanded on August 25, 2026, before Opus 5.5 on September 22. The October 21 Duet preview introduced a proactive app that continues work while a user is absent. In that setting, a notification may be the user’s first view of an operation. Its wording therefore becomes an operational interface. “Noticed,” “prepared,” “attempted” and “completed” describe different states, and a useful signal must not collapse them into a single reassuring declaration.
Discovery is not execution
An illustrative assistant finds an overdue invoice and prepares a reminder draft. That is useful work, but it is not evidence that the reminder was sent or that payment occurred. A status should identify the actual completed artifact and the remaining consequence. Otherwise, the user may act on a false assumption about an external system. The distinction is particularly important for background work because the user did not observe the intermediate steps that might have exposed the difference in a live conversation.
An attempt needs an outcome
A request sent to a connected application can fail, remain uncertain or succeed without the expected downstream effect. Describing only the attempt leaves the user to infer the result. A useful completion signal connects the reported state to an inspectable artifact or supported application observation. This is an analytical review criterion, not a claim that Duet exposes a particular audit field. It also avoids treating every uncertain result as failure: uncertainty can be accurately reported without inventing either success or a negative outcome.
A fixture for interrupted background work
A practical illustrative scenario begins with a draft reminder, then makes the destination application unavailable before any sending action is completed. The handoff should preserve the draft and state the unresolved dependency without announcing delivery. A separate successful-path scenario checks that the reported completion corresponds to an actual supported outcome. No real message needs to be sent for the unavailable-path fixture, and no product reliability figure is claimed. The pair tests status meaning rather than merely whether the interface can display a notification.
Completion is a claim with evidence
The preview’s background-work direction makes reliable handoffs central to usefulness. A signal should let the user understand what exists now, what remains pending and which next decision is theirs. It should not require reconstructing an entire hidden session, but it should point to enough evidence to support its claim. The retrospective lesson is that proactive communication needs precise state semantics. A correctly reported partial result can be more useful than an unsupported declaration of completion, even when the latter sounds more confident.