Cosmos DB in Fabric as AI agent memory: vector search, partitioning, and the OneLake mirror?
I'm evaluating Cosmos DB in Fabric as the storage layer for an AI agent, for example one built in Microsoft Foundry. It would hold: Conversation history and session state per user Long-term memory: facts or summaries the agent extracts, stored with embeddings for retrieval Agent run logs (tool calls, decisions) that I'd like to analyze in Power BI or KQL My understanding is that Cosmos DB in Fabric supports vector search and automatically mirrors data to OneLake, so the same data could serve the agent at runtime and support analytics afterward. Before committing, I'd like to understand a few things. Questions: Partitioning: for agent memory, is /userId a sensible partition key, or is it better to use hierarchical partition keys (for example /tenantId/userId/sessionId)? Are there hot-partition risks with very active users? Vector search: what are the practical limits in Cosmos DB in Fabric (embedding dimensions, index types, items per container)? Is hybrid search (vector plus full-text) available here, or only in standalone Azure Cosmos DB?
