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
Agent memory dies when the session ends, so you need durable state. Store the findings in a persistent external place like GitHub Issues, a repo JSON file, or a database, then load that state when the next session starts. That lets the new agent pick up where the prior review left off.
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 storing findings in a persistent external store 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 appending all findings to the system prompt 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 keeping the original agent session alive indefinitely 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 re-running the full code review at the start of each new session 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.