An agent completes a code review task and produces findings. When a new agent session starts the next day to act on those findings, the new session has no knowledge of the prior review. Which memory architecture solves this cross-session continuity problem?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Agent memory lives and dies with the session — like a conversation that ends when you close the tab. To survive across sessions, findings need to live somewhere permanent: a GitHub Issue, a file in the repo, or an external store. The next session reads that store and picks up exactly where things left off.
Full explanation below image
Full Explanation
Agent memory has two fundamental categories:
Ephemeral (in-context) memory: exists only within the active session's context window. When the session ends, all ephemeral memory is gone.
Persistent (external) memory: stored in a durable external system — a file, a database, a GitHub Issue, a task management tool — that exists independently of any agent session.
Why B is correct: Persisting findings to an external store (GitHub Issues, a structured JSON file committed to the repo, or a purpose-built database) creates durable state that survives session boundaries. The next session's initialization step loads the relevant stored state, giving the agent continuity.
Why A is wrong: Appending all findings to the system prompt works only if findings fit in the context window and only for the single session. It also requires manual re-injection for every new session, which is brittle and does not scale.
Why C is wrong: Keeping sessions alive indefinitely is not a practical or supported pattern. Sessions consume resources and are designed to be finite. LLM APIs do not maintain indefinite stateful sessions.
Why D is wrong: Re-running the full code review wastes compute, introduces risk of different results, and does not scale as the codebase grows. It is also not idempotent — a second review pass may find different or conflicting issues.
The correct pattern: agent session ends → write state to external store → new session starts → read from external store → continue task.