The short answer
With automatic coordination enabled, RoomService commits a message, its domain event and its initial coordination item in one repository transaction. This links visible intake to durable work creation. Provider execution happens later under separate claims and controls.
The intake gap appears before an agent runs
A common application pattern saves a message and then separately enqueues processing. If the process stops between those operations, the message is visible but no corresponding work may be scheduled.
The coordination reference documents a transactional intake path when RoomServiceOptions.automaticCoordination is enabled. The message, event and initial item commit together, so a rollback does not leave that partially admitted state.
Separate transaction success from execution success
A committed item means work has entered durable coordination. It does not mean a provider has started, generated an artifact or completed the user's objective.
In an illustrative support Room, the application can acknowledge that the request was retained while showing processing as pending. Preserve this distinction in status labels and metrics. Otherwise, a healthy intake endpoint can make a stalled worker look like completed agent work.
Follow the worker after the durable boundary
The documented worker discovers ready Room-scoped work, claims it under a lease and uses revision fencing and stable operation identity. The default execution adapter creates the policy-checked task and run through its own sequence.
The operational quickstart exercises that integrated path with deterministic providers. Use its retained records to see the connection between intake, coordination and execution without adding a live model as another variable.
Test before and after the commit
- Submit one message through the configured automatic path.
- Inspect the message, event and initial work item.
- Inject an intake failure before commit in a test environment.
- Confirm the expected rollback covers the linked intake state.
- Restart processing after a successful commit and follow the same work identity.
These are suggested integration checks. Use controlled failure points in the actual repository implementation rather than assuming a client connection drop occurred at a known transaction boundary.
Keep external effects outside the atomicity claim
A repository transaction does not atomically include an arbitrary model service or business connector. The effect integration guide assigns idempotency and uncertain-outcome reconciliation to the relevant sink.
Report the guarantee narrowly: intake records committed together under the configured path. Then report worker recovery and external effects separately. This gives operators a precise place to investigate when a retained request has not yet produced its intended result.
Sources and further reading
Documentation reviewed . Consult the linked documentation for current implementation details.