Control State vs Data State in AI Agents: From Turing Machines to LangGraph

Control State vs Data State

In AI agent frameworks such as LangGraph and Google ADK, the State object stores large data fields (e.g., messages, tool_calls, user_preferences). This differs from the traditional software notion of “state” as a simple enum indicating the current execution phase.

Two meanings of “state” in computer science

Control State – the current position in a state‑transition table (the program counter of a Turing machine). It determines which rule matches next and drives the execution flow.

Data State – the concrete content written on the tape of a Turing machine, i.e., the raw data and intermediate results being processed.

Analogies in other sub‑domains

Operating systems (process level) : control state = lifecycle stage (NEW, READY, RUNNING, BLOCKED, TERMINATED); data state = memory image, open file descriptors, register values.

Databases & transactions (ACID level) : control state = transaction phase (ACTIVE, PARTIALLY COMMITTED, COMMITTED, FAILED, ABORTED); data state = rows, field values, index leaf nodes affected by the transaction.

Compilers & interpreters (execution level) : control state = program counter and call‑stack frame; data state = variable environment (locals on the stack, heap objects).

Software‑engineering perspective

Architecturally, control state and data state are often physically separated, which is the essence of the State Pattern and MVC. In the TCP protocol stack, connection states (CLOSED, SYN_SENT, ESTABLISHED, FIN_WAIT) are control states, while the receive‑window byte stream is the data state. In web back‑end development, a session stores the data state (shopping‑cart, login ID) while boolean flags indicate the control state (logged‑in, has‑permission).

Why a data‑heavy state exists in agents

LLMs are stateless functions; each API call receives the entire conversation history as input. Therefore the system must manage the state externally. The State container holds messages, tool outputs, user preferences, and other intermediate results, enabling the LLM to reason with the full context.

Three‑layer state architecture

Control State Layer – Enum values: IDLE, THINKING, TOOL_CALLING, WAITING_USER, DONE, FAILED. Read by the framework routing engine.

Context Data Layer – Structured fields: messages[], draft, selected_items, user_preferences. Read by the LLM (via prompt) and node functions.

Metadata Layer – Timestamp, version, error info, retry count. Read by operations, monitoring, and recovery systems.

The control‑state layer answers “where are we now?” for the machine; the context‑data layer answers “what have we seen?” for the LLM and developers.

LangGraph implementation details

In LangGraph, State is defined as a shared data structure representing the current snapshot. Example:

from typing import TypedDict, Annotated
from langgraph.graph.message import add_messages

class MyAgentState(TypedDict):
    messages: Annotated[list, add_messages]  # conversation history, appended
    temperature_unit: str                     # user preference, overwritten
    tool_call_count: int                     # number of tool calls

Each node receives the current State as input and returns an incremental update. The framework uses a reducer (e.g., add_messages) to merge updates; messages are appended, other fields are overwritten.

Node functions do not handle control flow; conditional edges decide the next node based on the control state encoded in the graph structure.

Common pitfalls

Some developers treat the messages list itself as the sole state and infer the next step by inspecting the last message. This creates tangled if‑else logic and loss of determinism because there is no explicit control state.

Explicitly maintaining a small control‑state field (e.g., phase: "TOOL_CALLING" | "RESPONDING" | "WAITING_CONFIRM") allows conditional edges to route reliably, keeping control logic separate from the large data payload.

Why frameworks do not expose a built‑in status field

Control state is business‑specific; different agents need different lifecycle values.

The graph structure already encodes control flow; duplicating it in a data field would be redundant.

Separating concerns follows the single‑responsibility principle: nodes process data, edges control flow.

Engineering practices

Separate control and data fields in custom State definitions, using naming or comments.

Match state granularity to recovery granularity : persist only the states needed for crash recovery (e.g., WAITING_USER_CONFIRM) while keeping transient token streams in memory.

Design the state‑transition diagram before coding . A visual diagram clarifies allowed control‑state transitions and avoids ambiguous logic.

Example AgentState definition:

class AgentState(TypedDict):
    phase: str            # "idle" | "thinking" | "tool_calling" | "done"
    retry_count: int
    messages: Annotated[list, add_messages]
    tool_results: list
    user_preferences: dict

Conclusion

AI agent frameworks treat State as a data snapshot because LLMs need data to reason, while the framework needs a separate control mechanism to navigate the workflow. Data state records “what happened”; control state records “what to do next”. Both are essential for building robust, recoverable, and debuggable agent systems.