An agent is designed to assist a software team continuously over several weeks, tracking which PRs it has reviewed, what architectural decisions it has recorded, and the conversational context from each daily session. Which memory architecture MOST correctly handles these different types of information?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Different types of memory have different lifetimes, retrieval patterns, and stakes. Conversational context is ephemeral and session-scoped — it lives in-context. PR review history needs structured querying ('have I reviewed this PR?') — it belongs in an external task-state store. Architectural decisions are organizational knowledge with long lifespans and need timestamps and rationale — that's a knowledge base, not a chat log.
Full explanation below image
Full Explanation
Memory architecture for long-running agents requires matching each memory type to the storage mechanism best suited to its access pattern, lifespan, and importance.
Option A (context window only, cleared weekly) is wrong on multiple fronts. First, weeks of PR review history and architectural decisions will overflow any context window. Second, clearing weekly discards organizational knowledge that should persist indefinitely. Third, context windows are ephemeral by nature and are lost on any session termination.
Option B is correct because it applies the right tier to each type: (1) Conversational context from the current daily session is naturally in-context — it's what the agent is actively using, it has a session scope, and it doesn't need to persist after the session ends. Injecting the previous session's summary as needed is the standard pattern. (2) PR review history needs structured querying (did I review PR #1234? what did I conclude?) that requires an external store with indexing — a relational database or structured vector store. (3) Architectural decisions are organizational knowledge with long-term strategic value. They need timestamps, author attribution, rationale, and searchability — characteristics of a knowledge base, not a task queue.
Option C (flat file in repository) creates an ever-growing file that becomes increasingly difficult to query. Git commit history makes PRs for memory updates noisy. Concurrent agent sessions create merge conflicts on the file. This does not scale beyond a few weeks.
Option D (external storage for everything, retrieve all at start of session) defeats the purpose of in-context memory for current session context. Loading the entire database into context at session start is expensive and may overflow the context window. More critically, conversational context is built up during the session — it cannot be loaded at the start because it doesn't exist yet.