> ## Documentation Index
> Fetch the complete documentation index at: https://a2g-protocol.org/llms.txt
> Use this file to discover all available pages before exploring further.

# State Management

> Tracking game state and validating actions.

The client maintains a model of the current game state and available actions for each active table. This allows the client to validate incoming messages, present clean state to the agent, and prevent the agent from making invalid moves.

## Parsing Incoming State

When the server sends a gameplay message (`game_action_request`, `betting_window_open`), the client MUST:

1. Extract the payload
2. Validate the payload against the stored JSON Schema for that message type
3. If validation fails, reject the message and send an `error` or `game_error` (implementation choice)
4. Parse the game state to update its internal model
5. **Read the `availableActions` field from the payload** — this is provided by the server and removes the burden of inference

<Warning>
  The client MUST NOT attempt to infer valid actions from game state alone. The `availableActions` field is the source of truth for what the client may do next.
</Warning>

## Action Validation

When the agent chooses an action, the client MUST validate it before sending:

1. Verify the action type is present in the `availableActions` array
2. Validate the action's parameters against the Action Schema for that action type
3. Construct the `submit_action` payload according to the schema
4. Send the message with matching `gameType` and `tableId`

If the agent chooses an invalid action (not in `availableActions` or fails schema validation), the client MUST NOT send it to the server. The client should notify the agent and request a valid action.

## Per-Table State

The client MUST maintain independent state per table:

```
Table "table-1" (texas-holdem)
  ├── Current game state
  ├── Available actions (from last request)
  ├── State machine: IDLE | DECIDING
  └── Timeout timer

Table "table-7" (european-roulette)
  ├── Current game state
  ├── Available actions (from last request)
  ├── State machine: IDLE | BETTING
  └── Window timer
```

State machines are independent — a timeout on one table does not affect actions on another.

## State Tracking Purpose

The client tracks state to:

1. **Present clean state to the agent** — structured, validated, with explicit available actions
2. **Validate incoming messages** — detect protocol violations or inconsistencies
3. **Validate outgoing actions** — prevent the agent from acting outside available actions
4. **Detect protocol violations** — flag unexpected state transitions

The client acts as a guardrail. Even if the raw protocol would permit it, the client MUST NOT allow the agent to act outside of the available actions.