For fifteen years, we built web systems around a simple mental model: a request comes in, a response goes out, and the server forgets everything. Stateless HTTP gave us horizontal scaling, fault tolerance, and simple reasoning about system behavior.

That model is breaking under the weight of AI agents.

When AWS, Microsoft, Google, and Anthropic all independently announce that they’re rebuilding their agent runtimes around sessions rather than individual requests, it’s worth stopping to understand why — and what it means for teams building production AI systems today.

The Problem with Stateless AI

A stateless AI call is simple: send a prompt, receive a completion, done. This works for autocomplete, classification, and simple Q&A. But modern AI agents don’t work like this.

An agent tasked with “research our competitors’ pricing and draft a comparison report” might execute a chain like: search the web → read 5 pages → extract pricing data → compare against our data → identify gaps → structure findings → draft report → review for accuracy → format for Slack. That’s 20–50 tool calls, each building on the results of the last.

Under a stateless model, every tool call starts from scratch. There’s no shared working memory. The file the agent wrote in step 3 doesn’t exist in step 4 unless you explicitly pass it. The search results from step 1 have to be re-fetched or jammed into an ever-growing context window. Authorization credentials have to be re-validated on every call.

The stateless model breaks three things for multi-step agents:

• Context continuity — intermediate results can’t be shared efficiently
• Resource management — files, subprocesses, and network connections can’t span calls
• Isolation — parallel agents interfere with each other’s state

What “Session” Actually Means

A session is more than a conversation ID in a database table. In agent runtime terms, a session is a first-class execution environment with four properties:

Context persistence: The agent’s working memory — tool results, intermediate outputs, reasoning traces — persists across all tool calls within the session. The agent can write a file in tool call 3 and read it back in tool call 28. It can accumulate search results without hitting context limits.

Resource lifecycle: File system scratch space, subprocess handles, and open network connections are scoped to the session. When the session ends, resources are cleaned up. When the session resumes, resources can be restored from a checkpoint.

Identity and authorization: The session carries the user’s identity and delegated permissions. Every tool call executes in the user’s security context. An agent can’t do anything the user couldn’t do directly — and the audit trail ties every action to the session, which ties to the user.

Isolation: Session A cannot read or write Session B’s state, even when both are running on the same host. This is not optional. Shared mutable state between agent sessions is a security vulnerability and a debugging nightmare.

How Cloud Providers Are Implementing This

The convergence happening in 2026 is striking. Four major platforms have independently arrived at the session-as-primitive model.

AWS Bedrock Agents stores session state in DynamoDB and scopes execution context to S3 objects per session. IAM roles are provisioned per session, not per agent. This means you can audit exactly which actions were taken in which session, tied to which user identity.

Microsoft Azure AI Foundry backs sessions with Azure Cosmos DB with configurable TTL. Each session receives a managed identity scoped to the user’s tenant — the agent can call Azure services as the user without the user ever handing over credentials. Session context survives across container restarts via Cosmos DB checkpointing.

Google Agent Builder introduced “Playbook executions” as the session primitive. Vertex AI manages the execution graph, and each playbook execution gets an isolated context that can be inspected, replayed, or forked for debugging.

Anthropic Claude Code takes the most explicit stance: a container per session. Each session gets its own Docker container with an ephemeral filesystem. Changes are committed to a persistent workspace at defined checkpoints. The session’s container is torn down at the end, but the outputs live in the workspace. This is the highest isolation model — the session is a container.

The Architectural Implications for Your Team

If you’re building an AI-powered product and you’re still treating AI calls as stateless API requests, here’s what you need to rethink.

1. Session storage is not the same as caching

A Redis cache can hold simple key-value pairs. Agent session state is structured: it includes tool call history, file references, subprocess outputs, and potentially gigabytes of intermediate data. You need a session store with support for structured data, partial updates, TTL, and efficient retrieval of specific sub-trees.

For most teams starting out: store session metadata in Postgres, large artifacts in S3, and use Redis only for session lookup/routing. Don’t try to cram everything into Redis.

2. Session lifecycle management is an explicit concern

Sessions need to start, run, checkpoint, pause, resume, and terminate. Each transition has implications:

• Start: allocate resources, provision identity, initialize workspace
• Checkpoint: snapshot state to durable storage so the session can resume after interruption
• Pause: release active compute, keep storage
• Resume: restore from latest checkpoint, re-establish resources
• Terminate: run cleanup hooks, persist final outputs, revoke session credentials

If you don’t design this explicitly, you’ll end up with leaked resources, orphaned sessions, and security vulnerabilities from sessions that never properly terminated.

3. Cost attribution changes fundamentally

The per-token billing model made sense for stateless requests. Sessions change the math. A session that runs for 30 minutes, makes 50 tool calls, and consumes 100k tokens across those calls is a single billable unit — but it also consumed compute time, storage I/O, and external API quota.

You need to instrument sessions with full cost attribution: tokens consumed, tool calls made, external API calls, storage used, compute time. This is how you find the 20% of sessions consuming 80% of your AI budget.

4. Observability requires session-scoped correlation

Tracing an individual stateless API call is straightforward. Tracing a session with 50 tool calls across 10 minutes, potentially spanning multiple microservices, is a different challenge.

Session ID must be your primary correlation key, propagated through every log line, every trace span, every metric. The tooling that matters: structured logging with session_id field, distributed tracing with session-level root spans, and dashboards that let you drill from “session P99 latency degraded” to “which tool call in which session caused it.”

5. Multi-agent coordination requires session handoff

The most complex case: multiple agents collaborating on a single task. A researcher agent hands context to a writer agent. A planner agent delegates subtasks to five executor agents. This requires explicit protocols for session handoff — how does Agent B receive Agent A’s accumulated context without re-doing all of Agent A’s work?

The emerging pattern is session snapshots: Agent A produces a structured summary of its session state at handoff time. Agent B starts a new session, initialized with that snapshot. The snapshot format is becoming a de facto standard — a structured document covering: task objective, completed steps with results, open questions, resources created.

Code Pattern: Session-Scoped Tool Execution

Here’s a TypeScript pattern that makes sessions explicit in your tool layer:

interface AgentSession {
  sessionId: string;
  userId: string;
  workspaceDir: string;
  state: Record<string, unknown>;
}

async function executeToolInSession<T>(
  session: AgentSession,
  tool: (ctx: AgentSession) => Promise<T>
): Promise<T> {
  // All tool calls receive session context
  const result = await tool(session);
  
  // Checkpoint state after each tool call
  await checkpointSession(session);
  
  return result;
}

// Tools write to session workspace, not global state
async function writeResearchNotes(
  session: AgentSession,
  content: string
): Promise<void> {
  const notesPath = path.join(session.workspaceDir, 'research-notes.md');
  await fs.appendFile(notesPath, content);
  // File is scoped to session — other sessions can't see it
}

The key discipline: no global mutable state. Every side effect goes through the session context. Every file write goes to the session workspace. Every external call carries the session’s identity.

What This Means for Engineering Teams in Vietnam

Most teams I talk to are still building AI features as stateless API calls — fire a request to OpenAI or Claude, get a response, done. This works for simple features. It won’t work for agents.

The session shift means rethinking your infrastructure stack:

Before (stateless):

User request → REST endpoint → AI API call → Response

After (session-aware):

User request → Create/resume session → Tool chain in session context
             → Checkpoint state → Return to user

For teams starting this transition with limited infrastructure budget, here’s a pragmatic path:

1. Add explicit session IDs to every AI interaction — even before you build session storage, this gives you correlation for debugging
2. Use Postgres as your session store — JSON columns handle structured state well, and you already have Postgres
3. Scope files to session directories — a simple /tmp/sessions/{session_id}/ pattern gives you isolation without containers
4. Implement cleanup as a cron job first — terminate sessions older than N hours, clean up their directories

The container-per-session model that Anthropic uses is the gold standard for isolation, but it’s overkill for most teams starting out. Build toward it incrementally.

The Underlying Shift

The stateless request model gave us the web we have today. The session model will give us the AI systems of the next decade.

The reason all four major cloud providers converged on this model at the same time isn’t coincidence — it’s that they all hit the same wall trying to make complex agents work on stateless infrastructure. The wall is real. Sessions are the right response.

For engineering teams, the practical implication is straightforward: if you’re planning any AI feature that involves more than one or two sequential steps, design for sessions from day one. Retrofitting session management onto a stateless AI system is significantly harder than building it in.

The session is the new unit of compute. Design accordingly.