AI Agent - Aug 12, 2026

Agent Executor Session Consistency and Connection Recovery

Quick answer

Agent Executor addresses two different distributed-system problems. Single-writer session state reduces conflicting updates inside a conversation. Connection recovery lets a disconnected client reconnect and receive responses after the last sequence it saw. These behaviors help preserve an ordered user experience for long-running execution.

They do not automatically make every client request idempotent, every cancellation effective, or every external action exactly once. Build the client and tool protocol around ambiguity.

The three timelines to keep separate

TimelineExamplesWhat can diverge
Client deliveryrequest sent, stream frame received, reconnect cursor advancedA frame may be unseen even though it was produced
AX executionpending, outputs, terminal completed/failed/canceled stateExecution may continue after the client disappears
External actiontool request, remote commit, status read, compensationA side effect may complete before its result is logged

Reliable UX requires correlating all three. “The connection closed” is not a business outcome.

What the current protocol exposes

The repository’s current protobuf is explicitly marked active development. It defines conversations, interactions, executions, steps, output streaming, terminal states, and cancellation reasons. A conversation cannot continue until its last execution is completed or failed. The harness connection accepts one start message, may accept a cancellation during execution, streams zero or more output frames, and ends with one terminal response.

That is useful implementation evidence for the pinned revision, not a stable public contract. Generated clients, stored events, and proxies should be versioned together. Do not hard-code assumptions from this guide without checking the current protocol.

Reconnect test matrix

For each client type, test:

  1. Disconnect before the server acknowledges a new execution.
  2. Disconnect after acknowledgement but before the first output.
  3. Disconnect between two output frames.
  4. Reconnect with the correct last-seen sequence.
  5. Reconnect with a stale, future, malformed, or another session’s sequence.
  6. Open two clients for the same conversation and submit competing inputs.
  7. Request cancellation while a tool call is pending.
  8. Reconnect after completion, failure, cancellation, controller restart, and actor resume.

Verify ordering, missing or duplicated outputs, terminal state, authorization, backpressure, timeout, and operator trace. The UI should display “outcome unknown” when the runtime cannot establish whether an external action completed.

Single writer reduces one class of race

A single controller for session mutation can serialize conflicting updates and prevent some state corruption. It does not eliminate every race:

  • two user interfaces can still submit competing intentions;
  • a tool can mutate its own database outside the AX writer;
  • stale reads can drive a later invalid action;
  • leader failover can expose an ambiguous commit point;
  • retries can repeat a call whose first result was lost;
  • branches can deliberately diverge from a shared checkpoint.

Use optimistic versions or preconditions at external systems, stable operation IDs, and explicit state transitions. Confirm the current session status before accepting a new mutation.

Client design rules

  • Persist conversation and interaction identifiers in a trusted application store.
  • Bind reconnect and cancellation authorization to the verified caller.
  • Advance a resume cursor only after the client durably accepts a frame.
  • De-duplicate display events using protocol identifiers or a stable local mapping.
  • Separate “request received,” “execution running,” “tool committed,” and “response delivered.”
  • Reconcile ambiguous tool results before automatic retry.
  • Expire abandoned sessions and make cleanup observable.
  • Preserve a manual takeover path for consequential workflows.

The event log and snapshots guide covers runtime recovery. The security and multitenancy guide covers cross-session access. Use the readiness checklist before a rollout.

Frequently asked questions

How does AX maintain session consistency?

Google documents a single-writer architecture intended to serialize session-state updates.

What does connection recovery backfill?

The announcement describes responses after the client’s last seen sequence. Recheck the current implementation and protocol before depending on exact behavior.

Does reconnect make tool actions exactly once?

No. Delivery recovery and external side effects need separate idempotency and reconciliation controls.

Official sources

Source check: August 12, 2026; AX revision 2bcc1637b3c106c16963c5c5464aedb46c6da031. Recheck protocol messages, sequence semantics, states, cancellation, and compatibility before implementation.