Memory 2: Compatibility and Configuration

[gotsysdba]

Before building endpoints:

• Pin oracleagentmemory to the exact initially validated release rather than the current open-ended >=26.6.0 dependency in pyproject.toml. The repository generally pins server integrations, and the SDK already documents upcoming API removals.
• Prove against the real Oracle database that:
  • The existing async oracledb pool works with the SDK's async APIs.
  • The configured database meets the SDK's required database capabilities.
  • Schema creation and upgrades work under the intended schema owner.
  • Existing LiteLLM model and OCI authentication settings can initialize the SDK LLM and embedder.
• Prefer MemoryExtractionConfig; do not use the SDK's deprecated top-level extraction arguments.
• Verify shutdown behavior for background extraction through close_async().

Add a server-level AgentMemoryConfig, defaulting to disabled, containing:

• Enabled flag.
• Database alias.
• Memory LLM identity.
• Embedding model identity.
• OCI profile where applicable.
• Schema policy and table prefix or store ID.
• Semantic versus hybrid search strategy.
• Inline, background, or disabled extraction.
• Default and maximum TTL.
• Context-card and retrieval limits.

The database, embedding model, schema policy, and retention rules should remain operator-owned because changing them per browser session can create schema or index incompatibilities. Per-client settings may contain only consumption controls such as "use memory" and "automatically extract memories."

Use separate least-privilege identities:

• Migration or schema owner: permitted to create or upgrade the managed schema.
• Runtime user: only the DML and query privileges required for memory operations.
• Do not let every application startup perform opportunistic DDL. The SDK warns that schema upgrades can be long-running and that expiry cleanup may require scheduler privileges.

References:

• Stores and schema
• Time-to-live guide