[FEATURE] Add Database Session Management

[puritatemcordis]

Problem Statement

The current implementation of the Strands agent uses in-memory storage to maintain conversation history. While this is suitable for short-lived sessions, it lacks persistence across application restarts or crashes. To address this limitation, it would be valuable to implement a class that enables saving conversation history to a relational database such as PostgreSQL or MySQL. This enhancement would provide a more robust and reliable foundation for production-grade applications by ensuring conversation state can be preserved and recovered when needed.

Proposed Solution

No response

Use Case

Objective:
Enable the Strands agent to persist conversation history in a relational database to ensure continuity and resilience in production environments.

Primary Actor:
Strands Agent

Stakeholders and Interests:

Developers: Want reliable state management to build robust applications.
End Users: Expect seamless conversation experiences even after interruptions.
Operations/DevOps: Need observability and data recovery mechanisms in case of system failures.
Preconditions:

A relational database (e.g., PostgreSQL, MySQL) is available and configured.
The Strands agent is running in a production or long-lived session environment.

Main Flow:

A user interacts with the Strands agent.
The agent processes user input and generates responses.
Each turn in the conversation (user input and agent response) is saved to the relational database in real-time or at regular intervals.
If the application crashes or restarts, the agent retrieves the saved conversation history from the database.
The agent resumes the conversation with full context, ensuring continuity for the user.

Postconditions:

Conversation history is persistently stored in the database.
The agent can recover and resume sessions after unexpected terminations.

Alternative Flows:

If the database is unreachable, the agent logs the failure and continues with in-memory storage, optionally retrying persistence later.

Alternatives Solutions

No response

Additional Context

No response

[DennisTraub]

Depending on the size of individual messages, particularly if they include multimodal data or large documents, the conversation history can become quite large and difficult to handle for an RDBMS. As an alternative, I would suggest an option to store the history in the local file system with a lightweight lookup index (e.g. a JSON file or SQLLite DB), or an object store like S3, with a lookup table e.g. in DynamoDB.

[vincenzodomina]

I would definitely need to handle the messages and content blocks (also runs and sessions) as their own tables and records in a relational database (in my case especially for UI use cases and for post processing of results)

My current approach is to store short string contents directly in the content block record in a text field and store multimodal content inputs (images, files or larger texts) as files in S3 and reference them from the content block record. To distinguish small messages from file contents i work with the concept of artifacts (which are then stored as files)

That way the complete chat history can be persisted and retrieved in a performant way without loosing the structure and integrity of the RDB

[zastrowm]

Thanks for the request & use-case.

I think this might fit in with #57 and is something we're looking into how to better support. We don't have any updates to share yet, but our upcoming roadmap should provide more clarity on improvements to this area.