Table of Contents
Agentic AI workloads have multiple state layers: conversation history, tool call results, working memory, persistent user-level context. The architecture for managing these matters; bad state management produces incoherent agent behaviour.
Three state layers: session state (conversation + tool results, in-memory or Redis), working memory (LLM-managed scratchpad in prompt), persistent context (user history in Postgres + RAG retrieval). Most agent loops fit in session state; complex workflows need explicit working memory; long-term personalisation needs persistent layer.
State layers
- Session state: per-conversation; conversation messages, tool call results, intermediate observations. In-memory during session; Redis-backed for survival.
- Working memory: scratchpad managed by the LLM itself within the prompt. Scratchpad keys: TODO list, observed facts, working hypotheses.
- Persistent context: cross-session. User preferences, history, learned patterns. Stored in Postgres + retrieved via RAG when relevant.
Storage
- In-memory + Redis: session state survives reconnect; clears after session ends
- Postgres: persistent context with structured schema
- Vector store: persistent context retrieved by semantic similarity
- Conversation log: full append-only log for replay / audit
Verdict
For agentic AI in production, explicit state architecture beats ad-hoc context management. Session state in Redis; working memory as structured scratchpad in prompt; persistent context in Postgres + vector store. Each layer addresses different time horizons; together they support coherent multi-step agent behaviour.
Bottom line
Three state layers; explicit storage. See MCP.
