docs: say the acknowledgement no longer waits, not that handlers run after it

Deferred handlers launch at acknowledgement time and may start before the
2xx is written, so "runs after the acknowledgement" overstated the order.

_Generated with [`xum`](https://github.com/coder/xum) • Model: `anthropic:claude-opus-5-5` • Thinking: `high`_

Author: ThomasK33

docs/how-to/deferred-dispatch.md

@@ -5,8 +5,8 @@ expects a first agent activity within about 10 seconds. By default the runtime
 runs your handler *before* it acknowledges the webhook, so a handler that
 calls an LLM can easily miss those deadlines.
 
-Deferred dispatch fixes this. The runtime acknowledges the webhook first and
-runs your handler afterwards on a detached context
+Deferred dispatch fixes this. The acknowledgement no longer waits for your
+handler, which runs on a detached context
 ([ADR 0002](../adr/0002-async-dispatch.md)).
 
 ## Enable It
@@ -41,9 +41,9 @@ Dispatch runs in two parts:
 
 1. **Before the acknowledgement**, on the request context: signature
    verification, normalization, dedupe marking, and thread lock acquisition.
-2. **After the acknowledgement**, on a runtime-managed detached context: your
-   handler. It runs concurrently with the webhook response and may start
-   just before the 2xx is written. While it runs, the runtime renews the
+2. **Launched at acknowledgement time**, on a runtime-managed detached
+   context: your handler. It runs concurrently with the webhook response and
+   may start just before the 2xx is written. While it runs, the runtime renews the
    thread lock lease in the background.
 
 If the lease is lost — the state backend fails to extend it, it expires, or

docs/how-to/interactive-components.md

@@ -117,7 +117,8 @@ mention, post Block Kit content with an `mrkdwn` text element containing
 Under the default `DispatchSync`, the adapter sends Slack its empty 2xx only
 after your handler returns, so a slow handler can miss Slack's 3-second
 budget. Enable [deferred dispatch](deferred-dispatch.md), usually with
-`chat.ConcurrencyQueue`, so the handler runs after the acknowledgement.
+`chat.ConcurrencyQueue`, so the acknowledgement no longer waits for your
+handler.
 
 ## Open A Modal
 

docs/how-to/linear-agent-sessions.md

@@ -53,8 +53,8 @@ sections).
 
 Linear expects a first activity within about 10 seconds of a session event,
 and more activity within about 30 minutes. Enable
-[deferred dispatch](deferred-dispatch.md) so the real work runs after the
-webhook is acknowledged. Then, in the handler:
+[deferred dispatch](deferred-dispatch.md) so the webhook acknowledgement no
+longer waits for the real work. Then, in the handler:
 
 1. Post a quick **thought** (`PostThought`) right away. Not a response: a
    response ends the session.

examples/linear-agent-hello-world/README.md

@@ -143,6 +143,6 @@ Expected behavior:
   (`chat.AdapterAs[*linear.Adapter]`) rather than a generic runtime API.
 - Inbound signals (including `stop`) and structured session context are preserved
   on `Message.Raw`; read them with `linear.RawMessageFrom`.
-- This example runs under `chat.DispatchDeferred`, so follow-up work runs
-  after the webhook is acknowledged, while the runtime holds and renews the
-  thread lock.
+- This example runs under `chat.DispatchDeferred`, so the webhook
+  acknowledgement does not wait for follow-up work, and the runtime holds and
+  renews the thread lock while that work runs.