Memory in AI systems is a deliberate design choice that saves conversation context so each new message builds on what came before, turning a stateless request-response loop into a genuine back-and-forth conversation.
Picture this: you are practicing for a Java interview on EngineerPrep. You ask the AI tutor, 'Explain recursion to me like I am a beginner.' The tutor does a great job. You feel good. So you follow up: 'Now show me a trickier example.' The tutor responds with a definition of recursion — the same one it just gave you. Your first instinct: the model is not smart enough. Your second instinct: maybe the prompt is broken. Both guesses feel reasonable. Both are wrong. The real answer is simpler and more fixable than either. But to see it, you need to understand one small thing about how AI conversations actually work under the hood — and why 'memory' is not magic, it is just code. That is exactly what this lesson is about.
Every time your Spring Boot service calls Claude through Amazon Bedrock, it sends an HTTP request and gets an HTTP response. That is it. The model itself keeps nothing between calls. It is stateless — meaning it retains no information from a previous request once that response is returned. Think of it like a whiteboard that gets erased after every conversation. The model is fully capable while the whiteboard is full. The moment the request ends, the board is wiped clean. So when the learner types a follow-up question, EngineerPrep's backend sends a brand-new HTTP request to Bedrock. That request contains only the new question — nothing from before. The model has no idea there was a 'before.' Memory is just the solution to this problem.…
Imagine a simple timeline. On the left is the learner's browser. On the right is Claude running on Amazon Bedrock. In the middle is EngineerPrep's Spring Boot service. Step 1 — First message, no history yet. The learner types: 'Explain recursion.' The Spring service bundles that single message into a request and sends it to Bedrock. Claude replies: 'Recursion is when a function calls itself…' The service shows the answer. So far, so good. Step 2 — What happens without memory. The learner types: 'Give me a harder example.' The Spring service sends only that new message to Bedrock. Claude sees a message that says 'Give me a harder example' with zero context. It has no idea what 'harder' is relative to. It guesses — and usually guesses wrong or starts over. Step 3 — Adding a conversation history.…
Below is a minimal, runnable example of how EngineerPrep's tutor service stores and replays conversation history using Spring AI's ChatClient and InMemoryChatMemory . Line by line: InMemoryChatMemory is Spring AI's built-in implementation that stores the conversation as a plain Java list in the JVM heap — straightforward and sufficient for a demo, but lost on restart. ChatClient is the Spring AI object that wraps the call to Bedrock/Claude. Think of it as a smart HTTP client that knows about LLM requests. The conversationId is just a string — it is the unique key that separates one learner's history from another's. EngineerPrep uses the learner's session ID here. .advisors(new MessageChatMemoryAdvisor(memory, conversationId, 10)) is the key line. An advisor in Spring AI is a small piece of logic that runs just before or after the LLM call.…