What Is Session State?
The per-conversation memory — chat history, tool results, retrieved context, scratchpad — that an LLM application carries between turns of a single user session.
What Is Session State?
Session state is the per-conversation memory an LLM application maintains across turns of a single user session. It typically includes chat history, tool-call results, retrieved RAG context, user preferences, and any scratchpad the agent has written. It lives outside the model — usually in a key-value store, an in-memory cache, or a database keyed by a session ID — and is rehydrated into the prompt or context window at the start of every turn. In agentic systems, session state is the substrate on which planning, tool use, and follow-up answers depend.
Why It Matters in Production LLM and Agent Systems
Lose session state and the agent loses the conversation. A common failure mode: a customer asks “book me a hotel in Lisbon,” the agent calls a tool and gets results, the user replies “the second one looks good” — and the agent has no record of what “the second one” refers to because the tool result never made it back into state. The user repeats themselves; the agent starts over; trust drops.
The pain shows up across roles. A platform engineer sees session-state corruption when two users share a key by mistake and conversations bleed into each other. A product lead watches conversion drop on multi-turn flows because the agent keeps re-asking for information already given. An SRE chases intermittent agent failures that turn out to be a state-store eviction bug.
In 2026 agent stacks, session state is no longer a single chat-history list — it is a structured object: messages, tool outputs, intermediate plans, retrieved chunks, partial form fields. Each component has its own freshness, size, and security profile. Naive concatenation either blows the context window or drops critical fields. Session state has become a first-class engineering concern, with its own schema, eviction policy, and observability surface.
How FutureAGI Handles Session State
FutureAGI does not store session state for you — that lives in your application’s database or cache. We make it observable and evaluable. At the trace level, traceAI captures every turn as a span, with a session.id attribute that lets you reconstruct the entire conversation from spans. The Agent Command Center exposes sessions as an SDK resource; every call routed through the gateway carries a session ID and is queryable in logs. At the evaluation level, the CustomerAgentContextRetention evaluator scores whether the agent correctly used information from prior turns; ConversationCoherence scores logical flow across the session; CustomerAgentLoopDetection flags when the agent revisits the same state without progress.
Concretely: a team running a multi-turn travel agent on traceAI-langchain captures session IDs on every span. They sample 200 sessions per day into an evaluation cohort, run CustomerAgentContextRetention on each, and surface the worst-performing 10 sessions on a dashboard. When a deploy drops the average retention score from 0.87 to 0.71 overnight, the team pulls the offending sessions, replays them through the trace viewer, and sees that a new prompt template overwrote the tool-result field in state. FutureAGI did not store the state, but it caught the regression in the way the model used the state.
How to Measure or Detect It
Session-state quality surfaces through a mix of trace-level and eval-level signals:
CustomerAgentContextRetention— returns a 0–1 score for whether the agent correctly used context from earlier turns.ConversationCoherence— scores logical and topical consistency across the full session.session.idspan attribute — joins every turn of a conversation in your trace viewer; missing or duplicated session IDs surface state-routing bugs immediately.- Repeat-question rate — count turns where the agent asks for information already provided; a dashboard signal for state-loss.
- Session-state size growth — track byte size of state per turn; runaway growth indicates missing eviction.
Minimal Python:
from fi.evals import CustomerAgentContextRetention
retention = CustomerAgentContextRetention()
result = retention.evaluate(
conversation_history=session.messages,
current_response=agent_output,
)
print(result.score, result.reason)
Common Mistakes
- Storing the entire chat history forever. Without eviction, state grows past the model’s context window mid-session and silently truncates the most recent turns.
- Sharing state keys across users. A bug in session-ID derivation crosses conversations and leaks PII between users — a common production incident.
- Treating tool results as ephemeral. Tool outputs are part of state. Drop them, and the next turn cannot reason about what the agent just did.
- No schema. Plain-text concatenation hides structure; downstream parsing breaks the moment a tool changes its output format.
- Skipping session-state eval. A model that scores 0.95 on single-turn benchmarks can score 0.6 on multi-turn coherence. Test the session, not just the turn.
Frequently Asked Questions
What is session state?
Session state is the per-conversation memory an LLM application carries between turns — chat history, tool results, retrieved context, preferences — typically stored outside the model and rehydrated into the prompt on each turn.
How is session state different from agent memory?
Session state is short-lived and scoped to a single conversation. Agent memory is broader: it can be long-term across sessions, semantic (vector-stored), or episodic, and may persist across users. Session state is the working set; agent memory is the long-term store.
How do you measure session state behavior?
FutureAGI's CustomerAgentContextRetention and ConversationCoherence evaluators score whether an agent uses prior turns correctly, while traceAI captures session ID and per-turn spans so you can replay state evolution.