You will understand what conversation memory is, why LLMs need it explicitly supplied, and how to build it in a Spring Boot service using Spring AI — the exact pattern powering the EngineerPrep AI tutor.
Picture this: you open a JIRA ticket — EP-841: AI tutor loses context between messages . Users are complaining that every follow-up question feels like the first question. The tutor forgets everything. You look at the code. It calls the LLM, gets an answer, returns it. Looks fine. You test it. Ask a question. Get a great answer. Ask a follow-up. The AI is lost. You add some logging. The request going to Amazon Bedrock contains exactly one message: the follow-up question. Nothing else. No history. No context. Suddenly it clicks: the AI never saw the previous messages. You never sent them. So the question is: how do you give an LLM the history of a conversation — and how do you do it without reinventing the wheel every time?
An LLM — a Large Language Model, the AI model behind the tutor — is stateless. Every time you send it a message, it reads only what you put in that one request and replies. When the request is done, it retains nothing on your behalf. Think of it like a very knowledgeable consultant who joins each call with no notes from the last one. If you want them to remember what you discussed, you have to bring the notes yourself — "Last time we talked about consistent hashing, here's what we covered." That's exactly what conversation memory does. Before sending the user's new message to the LLM, you attach the history of the conversation — previous questions and answers — to the request. The LLM reads all of it and responds as if it was present for the whole chat.…
Imagine the EngineerPrep AI tutor as a chat window. Here is what happens behind the scenes for a three-message conversation. Step 1 — The first message arrives. The learner types: "What is consistent hashing?" The memory store is empty — this is a brand-new session. Spring AI assembles a request containing just this one message and sends it to Claude on Amazon Bedrock. Claude replies: "Consistent hashing is a technique for distributing keys across nodes…" The app saves both the user message and the AI reply into the memory store. The store now holds two entries. Step 2 — The follow-up arrives. The learner types: "How would I use that in a distributed cache?" This time, before calling Bedrock, Spring AI loads the two saved messages from the memory store and prepends them to the new user message.…