Google Cloud Makes Spanner Queues Generally Available for Transactional Agentic Workloads

Google Cloud Adds Native Transactional Messaging to Spanner

Google Cloud has announced general availability of Spanner queues, a native transactional messaging capability built directly into Cloud Spanner.

The feature is designed for agentic workloads where an AI agent needs to update its internal state while also dispatching an asynchronous action.

In traditional architectures, those operations often involve separate systems with separate commit points.

That creates a consistency problem.

An agent might successfully update its database state while its downstream message fails to dispatch. The opposite can also happen: a message may be dispatched while the database transaction rolls back.

Google Cloud says Spanner queues addresses this by making message creation another write within a Spanner transaction.

As a result, an agent's state change and its intended downstream action can commit together atomically or fail together.

The capability is now generally available.

Why Transactional Messaging Matters for AI Agents

AI agents increasingly perform workflows that extend beyond answering questions.

They can potentially:

• Issue refunds

• Manage inventory

• Execute multi-step handoffs

• Coordinate with other agents

• Trigger asynchronous actions

• Maintain long-term state

• Pause for human approval

• Schedule follow-up actions

These workflows require the agent to maintain state while also coordinating actions that may happen asynchronously.

Using separate systems for state and messaging introduces multiple commit points.

Consider a simple refund workflow.

An agent decides that a refund should be approved.

It needs to:

1. Update the order state.

2. Create a task for a downstream worker.

3. Ensure both changes represent the same decision.

If the order is marked as approved but the task is never created, the state says one thing while the execution system says another.

If the task is created but the state update fails, a worker could receive an action based on state that never successfully committed.

Google Cloud says these problems become more difficult in asynchronous multi-agent environments where retries, race conditions, and speculative execution can occur.

Developers may otherwise need additional patterns such as outbox implementations, idempotency mechanisms, and reconciliation workers.

Spanner queues is intended to move this coordination into the database transaction itself.

How Spanner Queues Works

The core model is straightforward:

Database state + queue message = one transaction

An agent can update application state and enqueue an asynchronous task inside the same Spanner read-write transaction.

Google Cloud says Spanner's strict serializability and global external consistency support this atomic behavior.

The queue itself is represented as a relational structure within Spanner.

Developers can therefore define, inspect, and manage queues using GoogleSQL.

This makes the queue part of the same database environment as the application state it is coordinating.

Four Key Capabilities for Agentic Workloads

Google Cloud highlights four capabilities for Spanner queues.

1. Atomic Decide-and-Act Enqueue

An agent can modify its internal state and enqueue tasks for another agent within a single read-write transaction.

This allows the decision and the intended action to become one atomic unit.

Google Cloud describes this as useful for workflows where an agent's state transition must remain synchronized with the task that follows it.

2. Scheduled Execution and Delays

Messages do not necessarily have to execute immediately.

Spanner queues can schedule messages for future delivery.

This supports patterns such as:

• Delayed retries

• Scheduled agent check-ins

• SLA escalation timers

• Follow-up workflows

• Human approval timeouts

The scheduled task can be created transactionally alongside other state changes.

Google Cloud says this removes the need for external cron schedulers or polling infrastructure for these queue scheduling patterns.

3. Streaming SQL Pull for Agent Workers

Agent workers can consume queue tasks using streaming SQL reads.

The runtime can continuously receive incoming tasks, process them as capacity becomes available, and acknowledge completed tasks within a transaction.

Google Cloud says this provides a transactional mechanism for maintaining reliable execution state across the task lifecycle.

4. Episodic Memory and Agent Handoffs

Agent memory can also be persisted through queues.

This includes:

• Long-term episodic summaries

• Reflective state transitions

• Context handoffs

• Sub-agent coordination

The idea is to persist memory updates asynchronously while keeping them transactionally connected to execution history.

For multi-agent systems, this can provide a durable representation of handoffs between agents.

Exactly-Once Agent Processing

Google Cloud describes Spanner queues as supporting transactional exactly-once agent execution.

The underlying delivery model provides at-least-once delivery and at-most-once acknowledgment, according to the announcement.

Combined with transactional state updates and task processing patterns, Google Cloud says this enables applications to achieve exactly-once processing.

This distinction matters because asynchronous systems can encounter retries and duplicate delivery.

The queue therefore needs to coordinate:

Task delivery → Agent execution → State update → Acknowledgment

The source's example uses an external API idempotency key together with transactional acknowledgment.

This helps connect the external action to the database state transition.

Multi-Agent Handoffs Become Durable Messages

Modern agentic applications may use multiple specialized agents rather than one agent handling an entire workflow.

For example, a primary agent may determine that a specialist should handle a particular task.

Spanner queues represents that handoff as a durable message.

Google Cloud says the message can contain the state needed by the specialist agent while maintaining an auditable lineage of interactions.

The architecture can therefore look like:

Primary Agent

↓

Transactional Handoff

↓

Spanner Queue

↓

Specialist Agent

The handoff is committed alongside the relevant state change rather than being maintained independently in a separate messaging system.

Human Approval and Timeout Workflows

Not every agent action should happen immediately.

Some workflows require a human decision.

For example, an agent may submit an approval request and wait for a manager.

If the manager does not respond within a defined period, the workflow may need to escalate automatically.

Spanner queues supports this pattern through scheduled messages.

A single transaction can record:

Pending approval state + future escalation message

If the human approves the request before the timeout, the application can update the state and remove the pending escalation task in another transaction.

This creates a transactional mechanism for workflows that combine automation with human decision-making.

SQL-Native Queue Observability

Because Spanner queues are represented as relational structures, Google Cloud says developers can use standard SQL to inspect queue activity.

This can be used to examine:

• In-flight agent workloads

• Task backlogs

• Queue state

• Agent execution history

• Transactional workflow data

The approach keeps queue information in the same database environment, so developers don't have to inspect a separate messaging system.

For teams already using Spanner, this provides a unified way to work with application state and transactional task data.

Under the Hood: Creating a Transactional Queue

Spanner queues uses a queue table defined directly in Spanner.

Google Cloud provides the following example for an order-processing workflow.

-- Assume parent table:
-- CREATE TABLE Orders (
--   OrderId STRING(64) NOT NULL, ...
-- )
-- PRIMARY KEY (OrderId);

-- Define the transactional queue table
CREATE QUEUE OrderAgentTasks (
  OrderId STRING(64) NOT NULL,
  TaskId STRING(64) NOT NULL,
  TaskType STRING(64) NOT NULL,
  Payload JSON NOT NULL
) PRIMARY KEY (OrderId, TaskId, TaskType), INTERLEAVE IN Orders;

The queue is associated with the Orders table.

The application can then update the business state and create a task in the same read-write transaction.

-- Inside a Read-Write Transaction:

-- 1. Update business state atomically

-- BEGIN TRANSACTION;

UPDATE Orders
SET Status = 'REFUND_APPROVED',
    UpdatedAt = PENDING_COMMIT_TIMESTAMP()
WHERE OrderId = @orderId;

-- 2. Enqueue the asynchronous agent action in the same transaction

INSERT INTO OrderAgentTasks (OrderId, TaskId, TaskType, Payload)
VALUES (
  @orderId,
  @taskId,
  'EXECUTE_REFUND',
  JSON '{"action": "execute_refund", "amount": 49.99}'
);

-- COMMIT;

Google Cloud explains that this means the EXECUTE_REFUND task exists if and only if the order status successfully changes to REFUND_APPROVED.

This is the central transactional property of the feature.

Scheduling a Future Agent Action

Spanner queues also supports delayed delivery.

Google Cloud provides an example where an automated escalation check is scheduled 72 hours into the future.

-- Schedule an automated escalation check-in 72 hours in the future

INSERT INTO OrderAgentTasks (OrderId, TaskId, TaskType, Payload, DeliverTime)
VALUES (
  @orderId,
  @escalationTaskId,
  'ESCALATE_UNAPPROVED_ORDER',
  JSON '{"action": "escalate_to_supervisor"}',
  TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 72 HOUR)
);

The DeliverTime value determines when the message becomes visible for delivery.

If the manager approves the request before the scheduled escalation, the application can update the order and remove the pending queue entry in the same transaction.

-- BEGIN TRANSACTION;

UPDATE Orders
SET Status = 'MANAGER_APPROVED',
    ApprovedBy = @managerId
WHERE OrderId = @orderId;

-- Atomically cancel the pending delayed escalation task.

DELETE FROM OrderAgentTasks
WHERE OrderId = @orderId
  AND TaskId = @escalationTaskId
  AND TaskType = 'ESCALATE_UNAPPROVED_ORDER',
ASSERT_ROWS_MODIFIED 1;

-- COMMIT;

Google Cloud notes that ASSERT_ROWS_MODIFIED 1 can act as a safeguard if the queue entry has already been deleted.

The application can capture the resulting statement-level error and abort the transaction if necessary.

Streaming Consumption and Lease Management

Downstream workers consume tasks through the RECEIVE_<QueueName> table-valued function over a streaming SQL connection using ExecuteStreamingSql.

For the example queue, the source uses:

-- Step 1: Consume tasks via a long-lived streaming SQL query

SELECT
  OrderId,
  TaskId,
  TaskType,
  Payload,
  SpannerLeaseToken,
  SpannerLeaseExpirationTimestamp
FROM RECEIVE_OrderAgentTasks(max_duration => '20m');

Spanner automatically manages message leases.

Each leased task includes a lease token and expiration timestamp.

This allows the system to track which worker currently has ownership of a task.

Renewing a Lease During Long-Running Agent Work

AI agent workflows may take longer than a default lease period because an agent can perform multiple reasoning steps or interact with external APIs.

Google Cloud provides a lease-renewal function for these situations.

-- Step 2: Extend lease ownership during long-running agent execution

SELECT *
FROM RENEWLEASE_OrderAgentTasks(lease_tokens => [@leaseToken]);

The worker can extend ownership while it continues processing the task.

Once the external operation has completed, the worker can update the business state and acknowledge the queue message in a transaction.

Atomic Acknowledgment After Agent Execution

Google Cloud's example records the external refund identifier, changes the order status, and deletes the queue message in the same transaction.

-- Step 3: Atomically checkpoint agent results and ACK the message

-- BEGIN TRANSACTION;

UPDATE Orders
SET RefundTransactionId = @externalRefundId,
    Status = 'REFUND_COMPLETED'
WHERE OrderId = @orderId;

DELETE FROM OrderAgentTasks
WHERE OrderId = @orderId
  AND TaskId = @taskId
  AND TaskType = @taskType
ASSERT_ROWS_MODIFIED 1;

-- COMMIT;

The use of ASSERT_ROWS_MODIFIED 1 is important in the source's lease-expiration example.

If a worker stalls and its lease expires, another worker could process and delete the task.

When the original worker resumes, its deletion attempt can detect that the queue row no longer exists.

Google Cloud says catching this error and aborting the transaction prevents the stale worker from overwriting newer database state.

Spanner Queues vs. Spanner Change Streams

Spanner already provides change streams, but Google Cloud distinguishes them from queues.

Spanner Change Streams

Change streams capture database changes such as:

• Inserts

• Updates

• Deletes

They are designed for near-real-time change data capture and downstream integration.

Google Cloud positions them for use cases such as data streaming, analytics, and storage integrations.

Spanner Queues

Spanner queues are designed for transactional task orchestration.

They provide:

• Message leases

• Scheduled delivery

• SQL-based task consumption

• Transactional acknowledgments

• Atomic coordination with database writes

The distinction can be summarized as:

Change streams: "What changed in the database?"

Queues: "What task should be executed?"

This makes queues more directly suited to asynchronous task execution and agent orchestration.

Spanner Queues Beyond AI Agents

Although the announcement focuses heavily on agentic workloads, Google Cloud says Spanner queues is a general-purpose messaging capability.

Potential applications described in the source include:

• Real-time activity feeds

• Live publishing updates

• Retail order processing

• Inventory workflows

• Financial transaction notifications

• High-throughput asynchronous task processing

• Event-driven architectures

The common requirement is the coordination of database state and asynchronous events.

This means the feature is not limited to AI.

Traditional event-driven applications can also use transactional queues where database consistency and message delivery need to remain connected.

What Spanner Queues Adds to Agentic Architecture

The announcement highlights a broader architectural issue in agentic applications.

An agent is not simply a model generating an answer.

It may need to:

Reason → Update state → Trigger an action → Wait → Receive a result → Update state again

Each transition creates an opportunity for inconsistency if state and actions are stored or managed independently.

Spanner queues brings the message into the same transactional environment as the application state.

For developers, that could reduce the need to build separate coordination layers for certain asynchronous workflows.

The practical value depends on the application's architecture and whether Spanner is already the system responsible for its operational state.

General Availability and Getting Started

Google Cloud says Spanner queues are now generally available.

The capability is available as part of Spanner and can be used by creating a queue table inside a Spanner database.

Google Cloud also provides a Spanner 90-day free trial and public documentation for the feature.

The source specifically points developers toward the Spanner queues documentation for building transactional and agentic workloads.

Conclusion

Google Cloud's general availability of Spanner queues adds native transactional messaging to Cloud Spanner.

The central idea is to bring database state and asynchronous execution into the same transaction.

For agentic systems, this can connect an agent's decision with the action that follows it.

A state transition and queue message can be committed together. Scheduled actions can be associated with transactional state. Workers can consume messages through streaming SQL, renew leases for longer-running tasks, and acknowledge completed work transactionally.

The same model also supports multi-agent handoffs, human approval workflows, delayed escalation, and SQL-based queue observability.

Beyond AI agents, Google Cloud positions Spanner queues as a general-purpose option for event-driven architectures where transactional state and asynchronous messaging need to remain coordinated.

The broader architectural shift is toward treating messaging as part of the transactional data model rather than as an entirely separate infrastructure layer.

For applications built around Spanner, that creates a unified path from data and state to asynchronous action.