Agentic state: the data an agent keeps between steps

LangGraph's default recursion_limit is 25 super-steps: exceed it and you get a GraphRecursionError rather than a bill. That cap is only enforceable because the step counter lives in the graph's state, not in the model's head — and the same move turns up in every other framework, from the server-side threads OpenAI's Responses API shipped in March 2025 to the Mcp-Session-Id header introduced in Model Context Protocol spec revision 2025-03-26. State is what makes an agent stoppable.

Two things get called "agentic state"

Sense A — execution state. The engineering meaning. A named, typed, persisted record of a single agent run: what it was asked to do, what it has already done, what came back, where it stopped. This is the sense used in LangGraph, Temporal, the OpenAI Agents SDK and the Model Context Protocol. The rest of this entry is Sense A.

Sense B — adoption state. The GTM-deck meaning: "the agentic state of go-to-market", i.e. how far a market or a team has moved toward agents. It is a synonym for "current state of adoption" and carries no technical content. If a page uses Sense B while linking to an architecture diagram, it is two articles stapled together. I wrote about that confusion in what agentic marketing actually is.

Where the term came from

State is borrowed, not new. Reinforcement learning has used it for the observation a policy acts on since Markov decision processes; software engineering has had finite state machines for decades. Agent frameworks fused the two.

The 2023 generation of agent loops — ReAct-style scripts, AutoGPT clones — kept state in a Python list that died with the process. Then four groups formalised it, separately, in four vocabularies.

LangGraph made it a declared object: you define a State schema, nodes return partial updates, reducers merge them, and a checkpointer writes a snapshot at every super-step against a thread_id. Resume from any checkpoint, or replay from an earlier one. OpenAI's Responses API, shipped March 2025, moved conversation state server-side — set store: true, pass previous_response_id, and the platform holds the thread. The Agents SDK wraps the same idea as Session, with SQLiteSession for local runs.

MCP put sessions in the transport. Spec revision 2025-03-26 introduced Streamable HTTP with an Mcp-Session-Id header, carried forward into 2025-06-18, so a server can hold per-client state across requests. Temporal came at it from durable execution, where state is an event history replayed to rebuild the workflow — and a bounded resource, with documented warn and termination thresholds.

Same object every time.

What it is not

The neighbouring terms are not synonyms. Treating them as such is how runs become unauditable.

Prompt caching is the trap. A cached prefix that survives 5 minutes looks like durability until the TTL expires mid-run and the agent has no idea what it already did.

A worked example

Take a lead-enrichment agent over a 4,000-row export: for each row, resolve the company domain, pull headcount, write back to the warehouse. The state object — the thing a checkpointer persists — is this:

{
  "run_id": "enrich-2025-11-04-a",
  "thread_id": "acct-4417",
  "goal": "enrich 4000 rows with domain + headcount",
  "cursor": 1842,
  "written": 1836,
  "failed": [1204, 1633, 1841],
  "step": 27,
  "max_steps": 40,
  "spend_cents": 214,
  "budget_cents": 500,
  "last_tool_result": { "domain": "acme.io", "headcount": 312 }
}

Three things follow from that shape. None of them follow from a chat transcript.

Kill the process at row 1,842 and restart with the same thread_id: LangGraph loads the last checkpoint and the agent resumes at 1,843 instead of re-enriching 1,842 rows. The failed array survives the restart, so the six unwritten rows are still knowable at the end. And the cap is checkable by code — step < max_steps, spend_cents < budget_cents — with no model in the loop.

That last point matters more than resumability. Unbounded loops are the most common production failure in agent systems, and the fix is a step counter enforced outside the model, which is exactly what LangGraph's recursion_limit is. A model asked to police its own budget is being asked to reason about a number it cannot see. Same argument I made for capped, metered endpoints.

Four tests for whether it qualifies

1. Kill test. Terminate the process mid-run. Restart it. Does it continue from where it stopped, or start over? If it starts over, you have a transcript.
2. Inspection test. Can you read the current state without calling the model? If answering "how much has this run spent" requires a completion, the number is not state.
3. Schema test. Is state a declared shape — a typed dict, a Pydantic model, a table — or an append-only list of messages? A list is a log. A log is not state.
4. Enforcement test. Is there at least one hard limit read from state and enforced in code? Step cap, spend cap, row cap. Strip max_steps and budget_cents out of the JSON above and nothing is bounded any more.

Systems fail tests 1 and 4 most often, and they fail together. The same missing state store that prevents resumption also prevents a cap.

I run agents in production on my own projects and pay their bills, so this is not a balanced view: I would not give an agent spend authority until its state store can answer "how much has this run spent" without asking the model. Memory, tools, orchestration, multi-agent choreography — all of it is a layer on top of a durable record of what has already been done. If you are wiring your first one, start with the caps, then decide what you want to self-host.