Agent Handoffs and progressive planning in Agent Rooms

Why a forwarded message is not a Handoff

“Ask the specialist” leaves several operational questions unanswered. Which participant owns the work now? What context may it use? Which revision of the specialist should run? Has the target agreed to receive the task?

The Handoffs and planning reference gives this transfer a typed lifecycle. A Handoff identifies participants, runs, agent revisions and scoped context. It preserves an authority ceiling rather than allowing delegation to expand the target's permissions.

Acceptance makes ownership explicit

The target must accept the Handoff. Revision fencing rejects stale updates, and depth and cycle guards bound delegation. A tool can propose a Handoff, but the proposal still needs the governed lifecycle.

In an illustrative proposal workflow, a drafting agent asks a specialist to assess an assumption. The application should display a pending transfer separately from accepted work. If the specialist becomes ineligible before acceptance, the application must resolve that state rather than treating the original tool response as execution authorization.

Progressive plans wait for real dependencies

The Planner materializes dependency-complete steps into work such as agent tasks, human contribution requests, approvals and Handoffs. This permits a plan to describe future activity without issuing every task immediately.

A research-dependent drafting step should become runnable after its required evidence exists, not merely because a model predicted that research would finish. Retaining materialized identities also means that repeated reconciliation can refer to the same logical work.

Replanning should preserve the reason for change

A new plan version needs a relationship to the predecessor and trigger event. Overwriting the old plan loses the explanation for why work was abandoned, replaced or delayed.

The operational projector can reconcile plan progress and enqueue accepted Handoffs idempotently. As the coordination documentation explains, selecting and scheduling work does not bypass Room policy. Keep the projection's bookkeeping responsibility distinct from the decision to execute.

Review the transfer as a reader and an operator

A useful Handoff view shows the source, target, status, context references and linked outcome. Operational investigation should additionally identify the revision involved in a conflict and the predecessor used for recovery.

• Verify that unaccepted work does not appear as running.
• Attempt a stale lifecycle update and inspect its rejection.
• Reconcile the same plan event twice and inspect logical task identities.
• Follow a failed target run to its explicit successor or terminal outcome.

Use the optional API service table to connect those operations through your configured host. The UI should reflect retained transfer state, not infer it from chat wording.