Microsoft Agent Framework Memory

How it works

1. Install agent-framework-memorysync from PyPI.
2. Create a MemorySyncContextProvider with your API key and the end user’s id.
3. Pass it to your Agent via context_providers=[provider].
4. Done — before every run the agent recalls what it knows about this user; after every run the user’s messages are sent for fact extraction, and the agent’s replies are not stored. No per-turn code.

Before you start

1. A MemorySync API key. Create one in the dashboard under Settings → API Keys, inside a project.
2. Python 3.10+ with agent-framework-core 1.8 or newer.

Install

One package:

pip install agent-framework-memorysync

Quickstart

Step 1 — create the provider

The provider is where you say whose memories these are. user_id is required; session_id separates conversations — every distilled fact is tagged with it.

from agent_framework_memorysync import MemorySyncContextProvider

provider = MemorySyncContextProvider(
    api_key="ms_...",        # or set MEMORYSYNC_API_KEY in the environment
    user_id="customer-42",   # required — the end user these memories belong to
    session_id="support",    # optional — tags this conversation's facts
)

Step 2 — attach it to your agent

Hand the provider to the agent. The framework now calls it around every run: recall lands in the instructions layer (never disguised as a fake user message), and the user’s messages are sent to MemorySync after the run completes. The server extracts the durable facts they contain and stores only those; filler such as “ok” yields none.

from agent_framework import Agent

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

result = await agent.run("Which seat should I book?")

Per-run identity — the documented gap, solved

Both competitor adapters bind identity at construction and document it as a framework limitation: multi-tenant servers must build one provider per user. This provider adds a three-rung ladder, resolved fresh on every run and pinned in the provider’s session-state slice so recall and capture can never diverge within a run:

Built-in safety guarantees

Configuration

Choosing a user_id

The user_id is a stable string you pick to identify whose memories these are: your app’s internal user ID, an email address, or a UUID. Use the same value across runs or recall returns nothing. One user_id drives both storage and retrieval — there is no separate search_user_id to forget.

Quotas and plan limits

Hitting a monthly plan limit never breaks a run. On free and paid plans, over-limit writes are accepted without storing and reads return empty — the agent keeps working. Evaluation keys instead surface a truthful 429, so you find out during testing, not in production.

Troubleshooting

• `ModuleNotFoundError: agent_framework` — the framework itself isn’t installed: pip install agent-framework.
• Recall returns nothing right after storing — extraction is asynchronous; give it a moment. Also confirm store and recall use the same user_id.
• The agent ran without memories once — that’s the latency budget working: a slow lookup is skipped rather than delaying the run. The next run recalls normally.
• Multi-tenant identity — don’t build one provider per user; pass options={"memorysync_user_id": ...} per run (rung 1 of the ladder).
• A crash after a successful run — not from this provider: capture is entirely fail-open by design. Check the model client.

Supported versions

How it compares

Where to go next