Skip to main content
When we call Agent.run(), it creates a stateless, singular Agent run. But what if we want to continue this conversation i.e. have a multi-turn conversation? That’s where “Sessions” come in. A session is collection of consecutive runs. In practice, a session is a multi-turn conversation between a user and an Agent. Using a session_id, we can connect the conversation history and state across multiple runs. Here are the core concepts:
  • Session: A session is collection of consecutive runs like a multi-turn conversation between a user and an Agent. Sessions are identified by a session_id and house all runs, metrics, state and other data that belong to the session.
  • Run: Every interaction (i.e. chat or turn) with an Agent is called a run. Runs are identified by a run_id and Agent.run() creates a new run_id when called.
  • Messages: are the individual messages sent between the model and the Agent. Messages are the communication protocol between the Agent and model.
See Session Storage for more details on how sessions are stored.

Single session

Here we have an example where a single run is created with an Agent. A run_id is automatically generated, as well as a session_id (because we didn’t provide one tot yet associated with a user.

Multi-Turn Sessions

Each user that is interacting with an Agent gets a unique set of sessions and you can have multiple users interacting with the same Agent at the same time. Set a user_id to connect a user to their sessions with the Agent. In the example below, we set a session_id to demo how to have multi-turn conversations with multiple users at the same time.
1

Multi-user, multi-session example

2

Run the example

Install libraries
Export your key
Run the example
For session history and management, you need to have a database assigned to the agent. See Storage for more details.

History in Context

As in the example above, we can add the history of the conversation to the context using add_history_to_context. You can specify this parameter on the Agent or on the run() method.
Learn more in the Context Engineering documentation.

Session Summaries

The Agent can store a condensed representations of the session, useful when chat histories gets too long. This is called a “Session Summary” in Agno. To enable session summaries, set enable_session_summaries=True on the Agent.
1

Session summary example

session_summary.py
2

Run the example

Install libraries
Export your key
Run the example

Customize Session Summaries

You can adjust the session summaries by providing a custom session_summary_prompt to the Agent. The SessionSummaryManager class is responsible for handling the model used to create and update session summaries. You can adjust it to personalize how summaries are created and updated:
See the Session Summary Manager reference for more details.

Session history

Agents with storage enabled automatically have access to the message and run history of the session. You can access these messages using:
  • agent.get_messages_for_session() -> Gets access to all the messages for the session, for the current agent.
  • agent.get_chat_history() -> Gets access to all the unique messages for the session.
We can give the Agent access to the chat history in the following ways:
  • We can set add_history_to_context=True and num_history_runs=5 to add the messages from the last 5 runs automatically to every message sent to the agent.
  • We can be more granular about how many messages to add to include in the list sent to the model, by setting num_history_messages.
  • We can set read_chat_history=True to provide a get_chat_history() tool to your agent allowing it to read any message in the entire chat history.
  • We recommend setting all 3: add_history_to_context=True, num_history_runs=3 and read_chat_history=True for the best experience.
  • We can also set read_tool_call_history=True to provide a get_tool_call_history() tool to your agent allowing it to read tool calls in reverse chronological order.
Take a look at this example:
1

Session history example

session_history.py
2

Run the example

Install libraries
Export your key
Run the example

Search the session history

In some scenarios, you might want to fetch messages from across multiple sessions to provide context or continuity in conversations. To enable fetching messages from the last N sessions, you need to use the following flags:
  • search_session_history: Set this to True to allow searching through previous sessions.
  • num_history_sessions: Specify the number of past sessions to include in the search. In the example below, it is set to 2 to include only the last 2 sessions.
It’s advisable to keep this number low (2 or 3), as a larger number might fill up the context length of the model, potentially leading to performance issues. Here’s an example of searching through the last 2 sessions:

Control what gets stored in the session

As your sessions grow, you may want to decide what data exactly is persisted. Agno provides three flags to optimize storage while maintaining full functionality during execution:
  • store_media - Controls storage of images, videos, audio, and files
  • store_tool_messages - Controls storage of tool requests and their results
  • store_history_messages - Controls storage of history messages

How it works

These flags only affect what gets persisted to the database. During execution, all data remains available to your agent - media, tool results, and history are still accessible in the RunOutput object. The data is scrubbed right before saving to the database.This means:
  • Your agent functionality remains unchanged
  • Tools can access all data they need during execution
  • Only the database storage is optimized
Important considerations when using store_tool_messages=False:
  • Tool message pairs are removed together: To maintain valid message sequences, when tool messages are removed from storage, the corresponding assistant messages that contains tool calls for that tool message are also removed. Most model providers require a strict “tool call pair”
  • Metrics will still consider the tokens spent on the deleted messages: Your run metrics will still reflect the actual tokens used during execution, including the tool calls and results.

Usage example

See more examples in Disable Storing History Messages and Disable Storing Tool Messages.

Developer Resources