Microsoft Drops One-Line Memory for Agent Framework — No Orchestration Code Required

Memory libraries usually promise cross-session recall, hand you a half-baked interface, and leave you wiring up background sync jobs and vector store glue. Microsoft’s latest move with the Agent Framework and Azure Cosmos DB takes a simpler approach: a single object handles the entire job.

The new CosmosMemoryContextProvider (Python, preview) plugs into the Agent Framework’s context provider abstraction—a pair of lifecycle hooks (before_run and after_run) that aren’t memory-specific. Instead of bolting memory onto your agent loop, you implement a generic extension point that happens to look up and store data. The provider delegates storage and extraction to the existing Agent Memory Toolkit, which writes turns, facts, summaries, and user profiles to Cosmos DB for NoSQL as JSON documents. Search uses Cosmos’ built-in vector, full-text, and hybrid indexes—no second database to provision or keep in sync.

What Changes Tomorrow

For anyone shipping code tomorrow, the setup looks like this:

from agent_framework_azure_cosmos_memory import CosmosMemoryContextProvider

provider = CosmosMemoryContextProvider(
    cosmos_endpoint="...",
    foundry_endpoint="...",
    embedding_model="text-embedding-3-large",
    chat_model="gpt-5.4-mini",
    credential=credential,
)

agent = Agent(
    client=...,
    context_providers=[provider],
)

The only additional step is setting a stable user_id in the provider’s session state. Cross-thread recall works immediately. Starting a new thread for the same user gives the agent access to their preferences, previous facts, and profile. No custom before_run, no get_memory glue. The provider handles everything.

Customizing What’s Worth Remembering

The default extraction rubric covers general facts, procedural information, and epics. For a coding assistant, you probably want memory focused on team decisions (“the team chose PostgreSQL over MySQL”) or response style (“always show code before explanations”), not mundane details like ordering a latte. The prompts_dir parameter points to a directory with a custom extract_memories.prompty template, and the pipeline uses your rubric instead. The retrieval and injection path stays unchanged—you only modify what qualifies as “memorable,” which is a clean approach for domain tuning without forking.

Production Realities

• Extraction is non-blocking. Turns are written synchronously; fact/summary generation runs in the background and drains cleanly when the provider context exits. Request latency stays low.
• Injected memory is safe by default. The recall is injected as a user-role message with a note that it’s untrusted reference information—not a system instruction. This reduces the risk of poisoned memory becoming a standing directive.
• Model names are explicit. No silent defaults that might point to a deployment you forgot to provision.

The Bottom Line

If you’re on Microsoft Agent Framework and want durable, Cosmos-backed memory without writing orchestration code, this is a drop-in solution that delivers on the promise. The package is preview and Python-only for now, so treat the API as unstable. But as a starting point for production-ready memory, it saves the effort of building a custom solution from scratch.

Clone the samples, attach the provider, and the agent will maintain context across sessions.