Stop, retry, or recover a response
Respond to a slow, empty, partial, or interrupted response without creating a duplicate.
In this article
Use Stop when active processing is no longer useful or uses the wrong context.
Wait for the interface to confirm the stop before sending a new request.
Retain any useful portion, but treat an interrupted result as incomplete.
Use Retry only when the request and context remain correct.
Start a new conversation when the subject, project, or scope changed.
If no renderable content is received, note the visible message and time before reporting the problem.
Identify what is still running
Read the activity state and any clarification card before deciding to retry. A request waiting for your answer needs that answer; an operation still processing needs time or an explicit stop. A response can also contain usable files even when the overall work did not finish. Review each file separately.
Stop and verify before resubmitting
Stop asks the service to stop the active work; closing a tab or losing the connection is not the same action. Wait for the displayed outcome. If the state is uncertain, return to the saved conversation and inspect its latest status before creating another request. Stopping does not undo a document change already applied or delete a file already created.
Advanced tips
- When correcting scope, list what remains valid and what changes: “Keep the table, exclude file R1, and use R2 for the next revision.” Answer any clarification instead of assuming the change was applied.
- Before retrying an operation that changes Word or Outlook, inspect the document or draft for an existing result. A lost acknowledgment does not prove that insertion failed.
- For support, record the conversation, approximate time, visible state, last action and expected result. Share only the minimum authorized diagnostic information.