feat: Add S3 chat memory repository implementation

[ybezsonov]

Add S3ChatMemoryRepository with CRUD operations for chat history

Features:

• Implement S3ChatMemoryConfig with builder pattern and validation
• Add Spring Boot auto-configuration for integration
• Support configurable storage class, key prefix, and auto bucket initialization

Test suite (15 integration tests):

• Full CRUD operations, pagination, conversation replacement
• Metadata and message order preservation
• Unicode content, large messages (100KB), special characters handling
• Auto bucket initialization and error handling
• Storage class configuration

Documentation:

• README with usage examples and configuration options

Resolves: #5088

[akukuruza]

Great job! Thank you!

[akukuruza]

Hey @ybezsonov, I got one more follow-up question – is there any way to support dynamic key prefixes, or would that be too complex to add?

For example, if we wanted to organize chat history like /memory/{product}/{date}/{conversationId}.json where product and date are determined at runtime based on conversation metadata. Currently, the keyPrefix appears to be static configuration.

This would be helpful for multi-tenant scenarios or when we need to partition history by different business dimensions without creating separate repository instances for each combination.

Thanks!

[ybezsonov]

Hey @ybezsonov, I got one more follow-up question – is there any way to support dynamic key prefixes, or would that be too complex to add?

For example, if we wanted to organize chat history like /memory/{product}/{date}/{conversationId}.json where product and date are determined at runtime based on conversation metadata. Currently, the keyPrefix appears to be static configuration.

This would be helpful for multi-tenant scenarios or when we need to partition history by different business dimensions without creating separate repository instances for each combination.

Thanks!

Hi @akukuruza, This is an interesting idea, and multi-tenancy is a very valid use case. I don't know about the date, but I think sessionId could be useful in this case. Some time ago, I implemented short-term and long-term memory with Spring AI https://dev.to/yuriybezsonov/a-practical-guide-to-building-ai-agents-with-java-and-spring-ai-part-2-add-memory-odn and recently updated it to managed memory with AgentCore https://dev.to/yuriybezsonov/ai-agent-memory-made-easy-amazon-bedrock-agentcore-memory-with-spring-ai-3bng.

I will review them all and come up with a solution which should cover multi-tenancy and be ready for different types of memory - similar to namespaces in AgentCore, I think.

[akukuruza]

Hey @ybezsonov, I got one more follow-up question – is there any way to support dynamic key prefixes, or would that be too complex to add?
For example, if we wanted to organize chat history like /memory/{product}/{date}/{conversationId}.json where product and date are determined at runtime based on conversation metadata. Currently, the keyPrefix appears to be static configuration.
This would be helpful for multi-tenant scenarios or when we need to partition history by different business dimensions without creating separate repository instances for each combination.
Thanks!

Hi @akukuruza, This is an interesting idea, and multi-tenancy is a very valid use case. I don't know about the date, but I think sessionId could be useful in this case. Some time ago, I implemented short-term and long-term memory with Spring AI https://dev.to/yuriybezsonov/a-practical-guide-to-building-ai-agents-with-java-and-spring-ai-part-2-add-memory-odn and recently updated it to managed memory with AgentCore https://dev.to/yuriybezsonov/ai-agent-memory-made-easy-amazon-bedrock-agentcore-memory-with-spring-ai-3bng.

I will review them all and come up with a solution which should cover multi-tenancy and be ready for different types of memory - similar to namespaces in AgentCore, I think.

Appreciate your work on this! The way I see it, adding a Function<String, String> keyResolver to the config would enable users to encode tenant or runtime context into the conversation ID itself, letting the resolver transform it to the proper S3 namespace at runtime.