Before you configure a load balancer or scale a multi-agent system, you need to answer a fundamental question: where does the agent's memory reside?
This code-level decision shapes everything that follows—from client payload size to horizontal scalability to the complexity of your deployment architecture.[reference:95]
Stateless Agents: Simplicity and Scale
Stateless agents treat each request as completely isolated and independent. The agent reads the user prompt, invokes the LLM, delivers the output, and forgets everything.[reference:96]
Advantages:
- Horizontal scaling is trivial. Since no user memory is stored on any backend server, incoming requests can be forwarded to any available instance
- Simple implementation. No database layer, no session management, no cache invalidation
The catch: In multi-turn conversations, the frontend must re-send the entire conversation history with every new request. This creates a snowballing effect—payloads grow linearly with each turn, driving up token usage and latency.[reference:97]
Stateful Agents: Memory and Continuity
Stateful agents take on the memory burden themselves. The client sends only the new user prompt plus a session identifier. The agent retrieves the conversation history from a database, appends the new message, processes the inference, and updates the stored state.[reference:98]
Advantages:
- Small client payloads on every turn
- Server-side history management—conversations can be trimmed or summarized without client involvement
- Supports complex workflows where agents pause and resume execution
The catch: Scaling is much harder. You need a persistent database layer. In horizontally scaled infrastructures, strategies like centralized memory caching with Redis become necessary to avoid "localized amnesia"—where a session's history is stranded on the instance that happened to serve earlier turns.
When to Choose Which
The choice between stateful and stateless design boils down to matching infrastructure to workflow[reference:99]:
Choose stateless for:
- Simple pipelines focused on specific tasks (text extraction, summarization, single-turn classification)
- Applications where each request is truly independent
- Teams that prioritize architectural simplicity and seamless horizontal scaling
Choose stateful for:
- Long-running assistants, coding assistants, or multi-turn bots
- Customer service applications where context continuity matters
- Complex workflows where agents need to pause and resume execution
The Hybrid Reality
In practice, most production systems mix these patterns. A customer service platform might use stateless agents for FAQ lookups, stateful agents for ongoing support conversations, and event-driven agents for complex case investigations.[reference:100]
The key is understanding the tradeoffs before you commit. Once your architecture is built around one pattern, switching is expensive. Choose the pattern that fits your use case today—and your scale tomorrow.