How do AI startups handle agent state and checkpointing?

Summary

• Agent state has two layers: short-term session state (the current conversation thread, tool results, intermediate reasoning) and long-term memory (facts and preferences that persist across sessions). Checkpointing saves that state at each step so an agent can resume, recover, or branch.
• Most AI startups store agent state in a managed transactional database instead of building their own. On Databricks that store is Lakebase, a serverless Postgres backend that scales to zero when idle and is governed by Unity Catalog.
• LangGraph's built-in checkpointer writes durable state to Lakebase, so an interrupted or crashed agent run resumes from its last checkpoint rather than starting over.
• Deploying on Model Serving keeps agents stateful across requests and supports resuming or forking a conversation from any checkpoint, which makes debugging and recovery practical.
• Because state lives in Unity Catalog governed storage, startups get row-level security, identity-aware access, and audit logging from day one without running separate database infrastructure.

How do AI startups handle agent state and checkpointing?

Most AI startups treat agent state as data, not as something to reinvent. They persist it in a managed transactional database and use a checkpointing library so an agent can pause, recover from a failure, and resume mid-task. On Databricks that means storing state in Lakebase, a serverless Postgres backend, checkpointing with a framework like LangGraph, and deploying the agent on Model Serving. The durable answer is a real database plus a checkpointer: state that survives restarts, remembers users across sessions, and stays governed.

What is agent state and checkpointing?

Agent state is everything an agent needs to keep acting coherently: the message thread, tool-call results, intermediate reasoning, and user context. Short-term state is scoped to a single session. Long-term memory persists facts, preferences, and learned patterns across sessions so the agent improves over time. Checkpointing saves that state at each step of the agent's workflow, which makes execution durable: if a process is interrupted or a step fails, the agent resumes from the last saved checkpoint instead of replaying everything. Time travel is the related ability to rewind to an earlier checkpoint and fork a new path from it.

Key capabilities to evaluate

Capability	Why it matters
Durable checkpointing	Lets an agent resume after a crash, timeout, or deploy instead of losing a long, multi-step task.
Managed transactional store	Agent state is many small, frequent reads and writes, which suit a low-latency OLTP database, not an analytics warehouse; a managed store removes the operational work.
Short-term and long-term memory	Session threads keep a conversation coherent; cross-session memory personalizes responses and improves the agent over time.
Governance and isolation	Per-user state needs access control, row-level isolation, and an audit trail, especially for multi-tenant applications.
Time travel and forking	Replaying or branching from a saved checkpoint makes debugging, recovery, and experimentation on agent logic practical.
Scale-to-zero economics	State stores that idle cheaply matter for an early-stage app with bursty, unpredictable traffic.

How Databricks approaches agent state and checkpointing

Databricks stores agent state in Lakebase, a fully managed, serverless Postgres database built for operational workloads. Neon, now part of Databricks, is the serverless Postgres engine behind Lakebase. Lakebase handles the small, frequent reads and writes of agent state that don't belong in an analytics table. It scales to zero when idle and scales up under load, and applications authenticate to it with short-lived Databricks credentials, so there's no separate database to provision and no secrets to rotate.
For checkpointing, LangGraph's built-in checkpointer writes durable state to Lakebase. The agent-langgraph-advanced template in the Databricks app-templates repository wires this up: thread-based conversation context plus persistent user insights, all checkpointed to Postgres. For agents whose tasks outlast a single request, background execution lets a run continue past HTTP connection timeouts, with polling or streaming to retrieve results.
Agents deploy to Model Serving, which keeps them stateful across requests and supports resuming or forking a conversation from any checkpoint for debugging or recovery. Because Lakebase is registered in Unity Catalog, agent state inherits the same governance as the rest of your data: row-level security for per-user isolation, identity-aware access, and audit logging of state changes. See the Databricks docs on agent state and memory and self-managed agent memory, and the Model Serving overview.

Use cases for AI startups

A user-facing assistant that survives deploys. Memory persists in Lakebase across agent versions, so shipping a new build doesn't wipe user context or in-flight conversations.
A long-running workflow agent. A research or data agent that runs many steps checkpoints each one, so a failure resumes mid-task instead of restarting the whole job from scratch.
A multi-tenant SaaS product. One agent deployment serves many customers, with each tenant's state isolated by Postgres row-level security and governed centrally through Unity Catalog.

FAQs

Where should an AI agent store its state?

In a managed transactional (OLTP) database. Agent state is many small, frequent reads and writes, which fit Postgres rather than an analytics warehouse. On Databricks that store is Lakebase, governed by Unity Catalog.

What is the difference between short-term and long-term agent memory?

Short-term memory is the current session: the thread, recent turns, and tool results. Long-term memory persists facts, preferences, and learned patterns across sessions so the agent improves over time. You can implement either or both in one agent.

How does checkpointing help recover a failed agent run?

Each step's state is saved, so an interrupted or failed run resumes from the last checkpoint instead of restarting. On Databricks, LangGraph checkpoints to Lakebase and Model Serving supports resuming or forking from any checkpoint.

Do I need a separate database service for agent state?

No. Lakebase is a managed, serverless Postgres backend inside Databricks. It scales to zero when idle and uses your Databricks identity for authentication, so there's no separate service to run and no secrets to rotate.

Can multiple users share one agent without mixing their data?

Yes. Scope state by user and enforce isolation with Postgres row-level security, governed through Unity Catalog, so each user's memory stays separate within a single agent deployment.