Session Restores — Memory Doesn't: LLM Forgets Context After Restart

[fedorovychh]

Description

After restarting the service, existing session data (events/history) is correctly loaded from storage and the session object is created. However, the LLM does not seem to have this restored context in its working memory.

As a result, even though the session exists and the past conversation events are present in the database, the agent is unable to recall previous information when the user continues the conversation. This leads to the LLM behaving as if no prior context exists.

In short: session state persists, but LLM internal memory does not refresh from the restored session.

---

To Reproduce

1. Run the service and start a conversation with the agent.
2. Provide information to the agent that it should “remember.”
3. Restart the service.
4. Continue the conversation and ask the agent about previously shared information.
5. The agent will not recall the context, even though the session and events were reloaded from storage.

---

Expected behavior

After service restart, the agent should load the previous session context not only into its session store, but also into the LLM working memory.

The agent should correctly recall previously shared information without requiring the user to repeat it.

---

Screenshots

Read lower messages first. First 2 messages are before restart. Second 2 messages are after the restart. After the restart I set the same session object, but agent already doesn't remember what is in session. Seems like after restart all objects event are needed to be added to LLM context.

---

Desktop

• OS: Linux
• Java version: 17
• ADK version 0.3.0

---

Additional context

This is especially important for long-running conversational agents where persistence and continuity across restarts are expected.

Currently, only session metadata is restored, but the conversational context is not re-hydrated into the model memory, causing loss of continuity for the user.

A possible solution could be automatically re-injecting the session history into the LLM context after service restart, before the first user message is processed.

[prasadskarmarkar]

@fedorovychh - can you share the code and steps to reproduce this issue ?

In short: session state persists, but LLM internal memory does not refresh from the restored session.

Well, session state is not persisted.

In adk-java, DatabaseSessionService is not supported yet.
https://google.github.io/adk-docs/sessions/session/#sessionservice-implementations

I am working on the implementation for the same.

[prasadskarmarkar]

Hi,

I’d like to work on this issue.
Could a maintainer please assign it to me? I’ll open a draft PR soon. Thanks!

[fedorovychh]

@fedorovychh - can you share the code and steps to reproduce this issue ?

In short: session state persists, but LLM internal memory does not refresh from the restored session.

Well, session state is not persisted.

In adk-java, DatabaseSessionService is not supported yet. https://google.github.io/adk-docs/sessions/session/#sessionservice-implementations

I am working on the implementation for the same.

Hi @prasadskarmarkar ! Here’s what actually happens.

When you start a session using a specific session ID, you can send messages and store the resulting events from the session object in your own storage. After restarting the application, you must load those stored events and restore them back into a new session object with the same session ID.

Once you run your Runner again with the restored session, you’ll notice that the LLM does not remember previous conversation details. That’s expected — the stored events don’t recreate the model’s internal long-term memory, only the session structure.

For me, code of setting an object looks like this. It is an overridden method com.google.adk.sessions.BaseSessionService#getSession:

JsonNode memories = getResultsOrThrowException(sessionResponse, error);
List<Event> events = mapToMutableEventsPerSession(memories);
State state = formState(userId, sessionId);
Session session = Session.builder(sessionId).state(state).events(events).userId(userId).build();
return Maybe.just(session);