Requires Python 3.11+.
Overview
This guide shows how to add Synap to a MAF application to build agents that:- Inject the most relevant memories as a system message at the start of each turn
- Record completed turns back to Synap for future retrieval
- Persist and replay the full verbatim conversation history when full transcript visibility is needed
context_providers slot and handles one axis of memory.
Setup
Install the package alongside MAF:The pip package is
maximem-synap-microsoft-agent, but the import drops the maximem- prefix and uses underscores: from synap_microsoft_agent import .....env
Basic integration
The smallest useful integration wiresSynapContextProvider into a MAF agent. Each turn now starts with the most relevant Synap memories injected as a system message, and ends with the completed turn ingested back into Synap:
SynapHistoryProvider; see below.
Core concepts
Context provider
SynapContextProvider runs on MAF’s before_turn and after_turn hooks:
- Before each turn: fetches relevant memories for the incoming message and appends them as a
systemcontext message. - After each turn: ingests the full user/assistant exchange back into Synap.
History provider
SynapHistoryProvider handles the verbatim conversation transcript. Use it when the model needs to see the full prior message history (not just semantic snippets):
SynapHistoryProvider is orthogonal to SynapContextProvider: one stores semantic memory, the other stores the literal transcript. Most production agents use both.
Complete example: agent with both memory axes
The pattern below combines the two providers so the agent gets both semantic context and full transcript replay:- The two providers serve different needs. Semantic memory tells the agent what’s relevant; verbatim history tells it what was said.
conversation_idonly matters to the history provider. The context provider pulls user-level memories regardless of thread.- Failure semantics split. Reads (context fetch, history load) degrade gracefully; writes (turn ingest, history save) raise on failure so silent data loss is impossible.
Advanced patterns
Multi-tenant scoping
Both providers accept the standard scoping triple:user_id (required), optional customer_id, optional conversation_id. customer_id is required on B2B Synap instances and ignored on single-tenant ones. See Memory Scopes.
Choosing between context-only and history-only
Some agents don’t need both:- Context only: concise agents that benefit from semantic recall but where full transcripts would blow the context budget.
- History only: short-lived agents (single session) that need verbatim replay but no long-term memory pool.
- Both: production agents that maintain ongoing relationships with users across many sessions.
Failure semantics
The integration follows the Synap-wide contract:SynapContextProviderreads degrade gracefully: empty context is injected and the error logged.SynapContextProviderwrites surface failures: turn ingestion raisesSynapIntegrationErrorso callers know persistence failed.SynapHistoryProvider.loaddegrades gracefully: returns an empty message list and logs the error.SynapHistoryProvider.savesurfaces failures: raisesSynapIntegrationError.
Going further
- Patterns overview: reusable memory patterns across frameworks.
- Cookbook overview: end-to-end worked examples.
Next steps
Semantic Kernel
Kernel plugin for Microsoft Semantic Kernel.
NeMo Agent Toolkit
MemoryEditor for NVIDIA NeMo workflows.Context Fetch
The retrieval API behind
SynapContextProvider: modes, scopes, and response shapes.Memory Scopes
How
user_id, customer_id, and conversation_id interact across reads.