Storage

Use Storage to persist Agent sessions and state to a database or file.

Why do we need Session Storage?

Agents are ephemeral and stateless. When you run an Agent, no state is persisted automatically. In production environments, we serve (or trigger) Agents via an API and need to continue the same session across multiple requests.

Storage persists the session history and state in a database and allows us to pick up where we left off.

Storage also lets us inspect and evaluate Agent sessions, extract few-shot examples and build internal monitoring tools. It lets us look at the data which helps us build better Agents.

Adding storage to an Agent, Team or Workflow is as simple as providing a DB driver and Agno handles the rest. You can use Sqlite, Postgres, Mongo or any other database you want.

Here’s a simple example that demonstrates persistence across execution cycles:

storage.py

from agno.agent import Agent
from agno.models.openai import OpenAIChat
from agno.db.sqlite import SqliteDb
from rich.pretty import pprint

agent = Agent(
     model=OpenAIChat(id="gpt-5-mini"),
    # Fix the session id to continue the same session across execution cycles
    session_id="fixed_id_for_demo",
    db=SqliteDb(db_file="tmp/data.db"),
    # Make the agent aware of the session history
    add_history_to_context=True,
    num_history_runs=3,
)
agent.print_response("What was my last question?")
agent.print_response("What is the capital of France?")
agent.print_response("What was my last question?")
pprint(agent.get_messages_for_session())

The first time you run this, the answer to “What was my last question?” will not be available. But run it again and the Agent will able to answer properly. Because we have fixed the session id, the Agent will continue from the same session every time you run the script.

Benefits of Storage

Storage has typically been an under-discussed part of Agent Engineering — but we see it as the unsung hero of production agentic applications.

In production, you need storage to:

• Continue sessions: retrieve session history and pick up where you left off.
• Get list of sessions: To continue a previous session, you need to maintain a list of sessions available for that agent.
• Save session state between runs: save the Agent’s state to a database or file so you can inspect it later.

But there is so much more:

• Storage saves our Agent’s session data for inspection and evaluations, including session metrics.
• Storage helps us extract few-shot examples, which can be used to improve the Agent.
• Storage enables us to build internal monitoring tools and dashboards.

Storage is such a critical part of your Agentic infrastructure that it should never be offloaded to a third party. You should almost always use your own storage layer for your Agents.

Session table schema

If you have a db configured for your agent, the sessions will be stored in the a sessions table in your database.

The schema for the sessions table is as follows:

Field	Type	Description
session_id	str	The unique identifier for the session.
session_type	str	The type of the session.
agent_id	str	The agent ID of the session.
team_id	str	The team ID of the session.
workflow_id	str	The workflow ID of the session.
user_id	str	The user ID of the session.
session_data	dict	The data of the session.
agent_data	dict	The data of the agent.
team_data	dict	The data of the team.
workflow_data	dict	The data of the workflow.
metadata	dict	The metadata of the session.
runs	list	The runs of the session.
summary	dict	The summary of the session.
created_at	int	The timestamp when the session was created.
updated_at	int	The timestamp when the session was last updated.

This data is best displayed on the sessions page of the AgentOS UI.

Developer Resources

• View the Agent schema
• View Examples
• View Cookbook