An agent relies on an external vector database for all its long-term memory retrieval. During a 30-minute database maintenance window, the agent fails completely — it cannot start new sessions, cannot recall any prior context, and surfaces errors to end users. The agent has no fallback behavior for memory store unavailability. What should the architecture include to prevent this?
Select an answer to reveal the explanation.
Short Explanation and Infographic
An agent that crashes completely when its memory store goes offline has a single point of failure in a place that should be handled gracefully. Even without long-term memory, the agent can still do useful work using what's in the current conversation — that's graceful degradation. A partially working agent beats a broken one every time.
Full explanation below image
Full Explanation
External memory stores — vector databases, key-value stores, or document databases used for agent long-term memory — are infrastructure dependencies with their own availability characteristics including maintenance windows, outages, and transient failures. An agent that has no fallback for memory unavailability treats an optional enhancement (enriched context from past sessions) as a hard requirement, making the entire system as fragile as the memory store.
Graceful degradation means the agent continues operating at reduced capability when a non-critical dependency is unavailable. For memory store unavailability, this typically means: (1) detect that the vector store is unreachable at startup; (2) log a warning (and optionally notify operators); (3) continue the session using only the information available in the current context window (user messages, system prompt, current session tool results); and (4) skip any features that require historical memory retrieval, surfacing a user-facing message that context from prior sessions may not be available.
Option A (cache entire database in local memory at startup) is impractical for large vector stores (40+ GB as seen in earlier scenarios) and creates a long startup time plus a stale cache problem. It also does not solve mid-session unavailability if the connection is lost after startup.
Option C (retry every 30 minutes) would make the agent sit idle for 30 minutes rather than operating in degraded mode. End users still cannot get help during that window.
Option D (switch LLM during maintenance) is not a substitute for memory context. Different LLM models do not have access to the agent's past session data — that data lives in the memory store, not the model weights.
Graceful degradation with in-context-only operation is the standard resilience pattern for external dependency unavailability.