Behavioral State Model: The Five Components That Decay in a Long-Running Agent

A behavioral state model is a decomposition of everything a long-running agent uses to decide its next action, broken into five components that can each be named, stored, and checked independently: context state, goal state, plan state, memory state, and tool/environment state. It is not a term from a single paper; it is a working framework for organizing a fact this site already treats as central to behavioral state decay: the "state" that decays is not one thing. It is five different kinds of accumulated data, each with its own decay mechanism, its own failure signature, and its own fix. Naming the parts separately is what turns "the agent seems off today" into a specific claim you can check: which component moved, when, and against what evidence.

Why model it explicitly

Teams that treat an agent's state as an undifferentiated blob run into the same diagnostic problem repeatedly: a session degrades, and the only available explanation is "the context got long" or "it must be drifting." Both are true often enough to sound plausible and vague enough to resist any fix. A behavioral state model forces a more specific question for every incident: was it the raw context, the stated goal, the plan, the externalized memory, or the agent's model of the outside world that went stale? Each of those has a different owner, a different repair, and, per the Agent Stability Index framework, a different telemetry signal. Splitting the state is also what makes composite drift scoring possible in the first place: a single scalar health score is only informative if you know which underlying component it is aggregating.

The five components

### 1. Context state

The raw content of the model's input window at a given turn: the system prompt, the running transcript, tool outputs, and whatever summary or compaction has replaced older turns. This is the component context rot and context poisoning act on directly. Context state is the only component that is fully visible (you can always print the literal tokens sent to the model), which makes it the easiest to audit and the easiest to over-trust: a context that looks complete and coherent can still contain a stale instruction or a hallucinated claim sitting a few thousand tokens from the parts anyone actually rereads.

A minimal schema field for this component: token count, turns since last compaction, and a hash or diff of the system prompt against its original version, so silent prompt drift across sessions is detectable rather than assumed away.

### 2. Goal state

The agent's current operative objective, as distinct from the objective it was originally assigned. This is what goal drift measures, and it is usually the component most worth externalizing first, because it is small (a sentence or a short structured objective, not a full transcript) and because everything downstream, planning, tool selection, stopping conditions, keys off it. Goal state can be poisoned by a single bad turn even when context state is otherwise healthy, which is the mechanism behind context poisoning: a hallucinated sub-goal gets promoted into this component and then re-read as settled fact.

Track it as its own field, separate from the transcript: current goal text, source (derived from original brief vs. self-generated by a summarization pass), and last-verified timestamp.

### 3. Plan state

The current multi-step plan the agent is executing against, including any assumptions about task order, dependencies, or preconditions. Plan decay is what happens when the world changes underneath a plan that was valid when formed: a file the plan expects to exist gets deleted, a ticket the plan is queued behind gets closed out of order, an API contract changes. Plan state is distinct from goal state because a plan can go stale while the goal stays perfectly correct; the objective is still right, but the recipe for reaching it no longer matches reality.

Track it with an explicit list of the plan's load-bearing assumptions and the last time each was checked against the live environment, not just the plan steps themselves. A plan without recorded assumptions cannot be diagnosed when it fails; you only learn that step 4 didn't work, not which stale premise caused it.

### 4. Memory state

Anything the agent treats as durable fact and carries across turns or sessions outside the live transcript: a knowledge base entry, a cached lookup, a fact written to a file. Memory poisoning targets this component specifically, and it is the one component where the failure mode requires an external write path rather than the agent fooling itself, which is what separates it from context poisoning even though the symptom, a false claim treated as ground truth, looks identical from the outside. State externalization is the mitigation pattern built around treating this component as authoritative and separately writable, rather than letting it live only inside a self-summarized context.

Track provenance per memory entry: where the fact came from (tool-confirmed vs. model-asserted), and whether it has been re-verified since being written.

### 5. Tool and environment state

The agent's working model of external systems: which tools are available, what their current outputs mean, and what state the outside world is actually in. This is where tool-use drift shows up, when the agent's assumptions about a tool's interface, arguments, or side effects stop matching how the tool behaves, often because the tool itself changed, a schema was updated, or an earlier call's result was misread and never corrected. It is also the component most exposed to environment divergence: the world moves whether or not the agent's model of it does.

Track tool-call success and argument-shape drift over the session, and treat any tool schema mismatch as an immediate signal to re-verify this component before trusting the plan built on top of it.

A minimal schema

You do not need a database migration to start. A single structured record, refreshed each time you inspect a session, is enough to make the five components auditable instead of implicit:

• `context`: token_count, turns_since_compaction, system_prompt_hash
• `goal`: current_text, source, last_verified_at
• `plan`: steps, assumptions (each with last_checked_at), last_revised_at
• `memory`: entries (each with provenance, last_verified_at)
• `tools`: available_set, last_schema_check_at, recent_call_success_rate

Populate it at session start as a known-good baseline, then again at whatever cadence you run drift regression tests or compute an Agent Stability Index-style score. The value of the schema is not the specific fields; it is that a degraded session now produces a diff against its own baseline, component by component, instead of a single vague "something feels off."

Using the model to route mitigation

Once a component is identified as the one that moved, the mitigation is usually already covered on this site under that component's own name, rather than a generic "fix drift" response:

• Context state degraded: apply re-anchoring to restore instruction salience without waiting for a full restart.
• Goal state degraded: re-derive the goal from the original task brief and the confirmed observation log, bypassing the summary chain that likely introduced the drift.
• Plan state degraded: re-check the plan's recorded assumptions against the live environment before executing further steps, per plan decay.
• Memory state degraded: fall back to the externalized, provenance-tagged record rather than the agent's self-summarized version, per state externalization.
• Tool/environment state degraded: re-verify tool schemas and recent call results before trusting any plan step downstream of them.

Routing this way is faster than generic remediation because it skips the diagnosis-by-guessing step: you already know which record disagreed with the baseline, so the fix targets that record specifically.

Related terms

• Behavioral state decay: the umbrella phenomenon this model decomposes into five trackable components.
• Agent Stability Index: a composite scoring approach that this model's per-component telemetry can feed into.
• Context rot and context poisoning: the two distinct failure modes that act on context state.
• Goal drift: the failure mode that acts on goal state.
• Plan decay: the failure mode that acts on plan state.
• Memory poisoning: the failure mode that acts on memory state.
• Tool-use drift: the failure mode that acts on tool and environment state.
• State externalization: the mitigation pattern this model motivates for memory and goal state specifically.

FAQ

Is "behavioral state model" a term from published research? No. This site uses it as an organizing framework, built on top of documented failure modes that are individually sourced, such as Chroma's context-rot research and Google DeepMind's Gemini 2.5 technical report. Treat the five-component split as a practical decomposition, not a citation.

How is this different from a state machine in the classical software sense? A classical state machine has a small, enumerable set of states and defined transitions. An agent's behavioral state is closer to five continuously-varying records than a finite set of named states; the model here is a way to structure observation of those records, not a claim that agent behavior is formally state-machine-shaped.

Do I need all five components tracked to get value? No. Start with whichever component your incident history implicates most, typically goal state or context state, and add the others as you find failures that the first component's telemetry does not explain.

Does this replace the Agent Stability Index? No, it feeds it. ASI-style composite scoring needs sub-metrics grouped by category; this model is one reasonable way to decide what those categories should be for a single-agent deployment where ASI's original coordination category does not apply.