The short answer
Agent Rooms hold the collaboration record and domain decisions. A workflow engine can provide durable scheduling and retries around coordination. The optional Rooms Temporal adapter handles operational wakeups and history while Room services and their stores retain domain authority.
Separate the work record from its scheduling
A proposal can wait for a reviewer overnight while its application processes restart. Two things need to survive: the proposal and review state, and the mechanism that notices when work can continue.
The first belongs to the collaboration domain. The second is an operational scheduling concern. The Room coordination guide explains how persisted messages and accepted Handoffs can enter a durable coordination loop without bypassing Room policy.
What does the optional Temporal adapter do?
The documented @agentplat/rooms-temporal adapter provides wakeup, retries, signals and history rollover. The canonical coordination runtime and PostgreSQL stores remain authoritative. Temporal history is not a separate Room aggregate.
That boundary matters when investigating a retry. A workflow-engine event can explain why an activity ran again, while the Room and coordination records explain whether the logical task already completed and which actor owned it. Inspect both rather than interpreting repeated activity delivery as proof of duplicated domain work.
An in-process worker is another composition
The same coordination guide describes an in-process worker and permits other adapters that preserve leases, fencing, stable identities and authority boundaries. Selecting a workflow engine is therefore an operational choice, not a prerequisite for representing human review.
For an illustrative internal app with modest scheduling needs, start by measuring whether the standard worker meets your restart and operations requirements. If your organization already operates Temporal, evaluate how its established monitoring and worker lifecycle fit this integration. Neither choice removes the requirement for durable Room state.
Do not confuse adapter families
The maturity matrix also lists Governed Durable Workflows and their core, PostgreSQL, Rooms and Temporal integrations. That broader capability is distinct from the specifically named Rooms coordination adapter.
Use the package catalog and the exact package README to identify the intended surface. Do not substitute a similarly named adapter or assume source availability proves that the selected package version is distributed through your registry.
Test scheduling and effects separately
In your integration tests, stop a worker while a human decision is pending, restart it, and verify that the same logical work resumes. Then test a retry after an effect has an uncertain outcome. The second scenario needs effect-specific idempotency or reconciliation; workflow history alone cannot settle a remote service's state.
The work-model selection guide helps distinguish shared collaboration from a predefined sequence of steps. Choose the domain representation first, then the scheduling machinery that can operate it reliably.
Sources and further reading
Documentation reviewed . Consult the linked documentation for current implementation details.