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_idand 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_idandAgent.run()creates a newrun_idwhen called. - Messages: are the individual messages sent between the model and the Agent. Messages are the communication protocol between the Agent and model.
Single session
Here we have an example where a single run is created with an Agent. Arun_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 auser_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 librariesExport your keyRun 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 usingadd_history_to_context. You can specify this parameter on the Agent or on the run() method.
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, setenable_session_summaries=True on the Agent.
1
Session summary example
session_summary.py
2
Run the example
Install librariesExport your keyRun the example
Customize Session Summaries
You can adjust the session summaries by providing a customsession_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:
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 set
add_history_to_context=Trueandnum_history_runs=5to add the messages from the last 5 runs automatically to every message sent to the agent. - We can set
read_chat_history=Trueto provide aget_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=3andread_chat_history=Truefor the best experience. - We can also set
read_tool_call_history=Trueto provide aget_tool_call_history()tool to your agent allowing it to read tool calls in reverse chronological order.
1
Session history example
session_history.py
2
Run the example
Install librariesExport your keyRun 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 toTrueto 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 to2to include only 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 filesstore_tool_messages- Controls storage of tool requests and their resultsstore_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 theRunOutput 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
Developer Resources
- View the Agent schema
- View the Session schema
- View Cookbook