Problem Statement

An agent maintains a conversation in-memory today, when the python process ends or agent object is deleted, the conversation is lost. When it comes to managing the conversation beyond this scope, Strands offers a DIY approach where customers are required to write their own persistence logic (ref). The community has shared that they want:

• An in-build mechanism for strands to save an ongoing conversation to a datastore.
• An extendable and pluggable interface to bring your own database persistence provider (similar to our Model Providers)
• A way to save a conversation not only for a single agent, but a multi-agent system as well (ref)

Proposed Solution

In order to support these new use case, will add a new top level primitive called the SessionManager that will be in charge of persisting the agent to some underlying datastore:

def continue_conversation(prompt, session_id):
    session_manager = DdbSessionManager(session_id=session_id)
    agent = Agent(
      session_manager=session_manager
    )
    
    return agent(prompt) # This request and the agent response is saved to DDB

At initialization, the SessionManager will load the previous state of the Agent from the datastore, and for each user message or and LLM response, we will store the message to a datastore with the session manager.

This implementation will require that any state of an Agent can be serialized and deserialized. The addition of an AgentState object will be added to the Agent class that will be configurable by the user for storing and retrieving information that is not required in the conversation history. This will replace (or extend) the **kwargs that are currently passed into the agent's invocation. This state object will only accept json serializable data types.

What is persisted and what isn't persisted?

One extreme for persisting an Agent is to fully serialize it, store it in a datastore, and then deserialize it at startup to perfectly replicate its state. This proposal is not meant to solve the Agent serialization problem, but is meant to bridge the gap for persisting some stateful information about an agent. Specifically, persisting the messages array, AgentState, and a few other pieces of data will cover most use cases for recovering and restarting an agent.

Full agent serde will be possible with the interfaces introduced in this work, but the default implementations will focus on persisting the messages, agent state, and other necessary data.

Use Case

Use Cases

• Store an agents conversation to a datastore. This can be a new, or ongoing, conversation where each user message, assistant response, and associated state is stored to the datastore.
• Load conversation from a datastore and prime the agent’s context
• Load conversations at specific instances to allow for a re-play of the response generation, or to branch the conversation
• Storing and loading conversations for a multi-agent system (ref)

Alternatives Solutions

#57

Additional Context

No response