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?

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, such as enriched context from past sessions, as a hard requirement, making the entire system as fragile as the memory store. The correct architecture should implement a graceful degradation fallback: operate in a reduced-memory mode using only in-context information when the external store is unavailable, rather than failing completely. Graceful degradation means the agent continues operating at reduced capability when a non-critical dependency is unavailable. For memory store unavailability, this typically means detecting that the vector store is unreachable at startup, logging a warning and optionally notifying operators, continuing the session using only the information available in the current context window such as user messages, system prompt, and current session tool results, and skipping any features that require historical memory retrieval while surfacing a user-facing message that context from prior sessions may not be available. The approach of caching the entire vector database in local memory at startup is impractical for large vector stores, such as 40+ GB stores 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. The approach of increasing the retry interval to 30 minutes to match the maintenance window would make the agent sit idle for 30 minutes rather than operating in degraded mode, and end users still cannot get help during that window. The approach of switching to a different language model during maintenance windows is not a substitute for memory context, because different language 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.