Google Puts the Message Queue Inside the Database: Spanner Queues Goes GA for Agentic Workloads

Google Cloud on Thursday announced the general availability of Spanner queues, a native transactional messaging system embedded directly inside Spanner, its globally distributed database. The feature is explicitly designed for agentic architectures, where the failure mode Google wants to eliminate is the split brain between what an agent has decided and what it has actually done.

The problem, as Google's engineering blog lays it out, is architectural: AI agents that issue refunds, manage inventory or orchestrate sub-agents typically keep internal state in an operational database while dispatching asynchronous actions through a separate messaging or event queue. Two systems with disjoint commit points destroy transactional consistency. If the database update succeeds but the dispatch fails, the agent decides to act but never executes; if the dispatch succeeds but the state transaction rolls back, the agent executes on an invalid state. Teams paper over this with outbox patterns, idempotency layers and reconciliation workers — what Google calls a heavy reliability tax on agentic architecture.

With Spanner queues, creating a message is simply another write in the transaction. An agent's state change and its intended downstream action commit as a single atomic unit, backed by Spanner's strict serializability and global external consistency. The company describes four core capabilities: an atomic decide-and-act enqueue that updates memory and enqueues tasks to peer agents in one read-write transaction; scheduled execution and delays, so retries, check-ins and SLA escalation timers can be enqueued transactionally without external cron infrastructure; streaming SQL pull, letting autonomous agent runtimes consume tasks and acknowledge completion within a transaction; and episodic memory persistence, so long-term summaries and context handoffs across sub-agents stay synchronized with execution history.

On the guarantees side, Google says the design yields at-least-once delivery combined with at-most-once acknowledgment, enabling exactly-once processing. In multi-agent systems using the agent-to-agent pattern, a handoff from a primary agent to a specialist is represented as a durable, transactionally committed message with a fully auditable lineage. Human-in-the-loop workflows get first-class timeout handling: a single transaction records the pending approval state and schedules an automated escalation, with whichever triggers first resolving the wait. Because queues are first-class relational structures, inspecting backlogs or auditing execution history is done with ordinary GoogleSQL queries rather than a separate message-store console.

Google is also positioning the feature beyond agents, as a general-purpose messaging platform for activity feeds, news publishing, retail order processing and financial services — the classic asynchronous workloads that today get routed to dedicated queuing products. The implicit target of the agentic framing, though, is the emerging stack of agent runtimes that need crash-safe, auditable execution: several vendors have spent the past month shipping exactly this layer, from durable-execution runtimes that record every model and tool call to cloud sandboxes that quarantine runaway agents.

The significance is less the feature than the pattern it signals. The database, the queue and the agent's memory are converging into one transactional surface, because the expensive failures in agentic systems are no longer bad answers — they are actions that executed without their state, or state that updated without its action. Whoever owns that atomic commit owns the reliability story for production agents, and Google has now planted its flag in the part of the stack it happens to dominate.