Google Cloud made Spanner queues generally available, allowing database state changes and queued messages to commit atomically.

Google Cloud announced the general availability of Spanner queues, embedding transactional messaging directly within Spanner. Creating a message becomes another write within a transaction, so an agent’s state update and intended downstream action either commit together or fail together.

The article contrasts this with a separate database and messaging system, where a state update can succeed while dispatch fails, or dispatch can succeed while the state transaction rolls back. It identifies outbox patterns, idempotency layers, and reconciliation workers as mechanisms developers use to handle those inconsistencies.

Spanner queues support updating state tables and enqueuing peer-agent tasks in a single read-write transaction, backed by Spanner’s strict serializability and global external consistency. Messages can be delivered immediately after commit or scheduled for later, including delayed retries, agent check-ins, and service-level-agreement escalation timers.

Workers consume tasks using streaming Structured Query Language (SQL) reads and acknowledge completion within a transaction. Google also describes transactional persistence of episodic summaries, reflective state changes, and sub-agent handoffs; the atomicity claim concerns state and queued execution intent, not a blanket guarantee that every external action completes successfully.