Migrate agent dispatch onto the conversation worker

[dcramer]

Objective

Prove the shared conversation turn workflow by migrating scheduled/plugin agent-dispatch onto it and deleting the independent dispatch execution lifecycle.

agent-dispatch is the existing second durable agent runtime: it currently owns a dispatch record version, attempt counter, slice lease, callback loop, incomplete-work index, heartbeat recovery, continuation scheduling, delivery guard, and terminalization path.

Scope

• Keep the dispatch record only for plugin-facing idempotency, request metadata, status, and result projection.
• Append each dispatch input to the normal conversation mailbox with a stable idempotency key.
• Before acknowledging that mailbox input, persist a small dispatch/task reference plus the exact actor, credential subject, execution destination, and completion behavior required to restore later slices.
• Execute new and resumed dispatch turns under the normal conversation lease and worker decision loop from Unify new and resumed turns in the conversation worker #876.
• Preserve the dispatch actor, credential subject, source, destination authority, visibility, configuration, tool context, isolated conversation identity, and stable turn identity.
• Preserve existing Slack completion behavior while expressing it as a completion target of the shared turn workflow.
• Recover timeout, worker loss, queue redelivery, and missing wakes through conversation execution.
• Remove dispatch-owned execution status/lease authority, callback continuation loop, incomplete index, and core heartbeat recovery after parity.
• Keep plugin heartbeat responsible only for discovering/scheduling plugin work.

Completion

• Dispatch input is durable mailbox work before a queue wake is sent.
• After mailbox acknowledgement, a later execution slice can restore dispatch authority and completion behavior from conversationId plus durable active-turn state; callback payloads are not runtime context.
• Provider-backed conversations and dispatches use the same lease, start/resume decision, session records, terminalization, and recovery workflow.
• Dispatch queue redelivery and stale work are idempotent.
• One dispatch produces one terminal projection and does not post its Slack result twice.
• Authorization blocking and credential delegation remain bounded exactly as before.
• Existing plugin dispatch APIs and projections remain behavior-compatible.
• The dispatch lease, callback loop, incomplete index, and heartbeat recovery are deleted.
• Integration coverage proves success, blocked authorization, timeout continuation, duplicate wake/callback compatibility during cutover, delivery fencing, and worker recovery.

Non-goals

• Subagent bindings, invocation-result delivery, or model-facing delegation.
• Keeping a generic dispatch runner after migration.

[sentry-junior]

Reevaluation (post-#1059 / #1344)

Checked against main. The migration objective is done. Remaining work is cutover cleanup, not a second execution runtime.

Completion criteria

Criterion	Status	Evidence
Dispatch input is durable mailbox work before a queue wake	done	enqueueAgentDispatch: claim append → appendAndEnqueueInboundMessage → confirmDispatchMailboxAppend
Later slices restore authority from conversation + durable state; callbacks are not runtime context	done	resolveAgentDispatchId + buildDispatchRoutingContext from the dispatch record / active turn; callback handler only enqueues
Same lease, start/resume, terminalization, recovery as provider conversations	done	createAgentDispatchConversationWorker under the conversation worker; turn checkpoints own resume
Queue redelivery / stale work idempotent	done	terminal short-circuit, durable result projection, redelivery ack without restart
One terminal projection; no double Slack delivery	done	delivery-receipt projection paths; integration tests for prior delivery / receipt recovery
Auth blocking + credential bounds preserved	done	persistBlockedDispatchTurn / AuthorizationFlowDisabledError
Plugin dispatch APIs/projections compatible	done	record + projection surface kept in store.ts / context.ts
Dispatch lease, callback loop, incomplete index, heartbeat execution recovery deleted	done (with cleanup leftovers)	runner.ts gone; callback route is enqueue-only; incomplete index is mailbox-append receipt only; heartbeat repairs appends then defers to conversation recovery
Integration coverage for success / blocked / recovery / fencing	mostly done	agent-dispatch-work + agent-dispatch-recovery cover routing, retries, delivery fencing, pre-cutover resume, mailbox-append repair

Leftovers (not the migration)

These are TODO(v0.116.0) cutover items, not an independent dispatch lifecycle:

• legacy optional fields on the dispatch record (attempt, leaseExpiresAtMs, version, …)
• incomplete-index key name retained for pre-cutover append receipts
• legacy signed callback route (handlers/agent-dispatch.ts) still enqueue-only until aged out

Recommendation

Close this issue as completed by #1059 (and reinforced by the #1344 execution rewrite). Track any remaining TODO(v0.116.0) cleanup under #1267 or a small dedicated cleanup issue if still needed after the release window.

[sentry-junior]

Closing as completed.

Migration landed in #1059. Shared execution ownership was reinforced by #1344. Remaining TODO(v0.116.0) items are cutover cleanup only (legacy record fields, incomplete-index key name, enqueue-only callback route), not a second dispatch execution runtime.

See the reevaluation comment above for the criterion matrix.