ChatAgent persistent memory through Synap. CAMEL exposes a first-class pluggable memory interface (ChatAgent(memory=...) accepts any AgentMemory), and SynapAgentMemory plugs Synap in there, plus @tool functions and a short-term context helper.
Requires Python 3.11+ and
camel-ai>=0.2.90.Overview
Three surfaces, mapped onto CAMEL’s own extension points. Adopt only the ones you need.
All three take an already-constructed
MaximemSynapSDK. Your app owns the SDK and its credentials.
Setup
Basic integration
Register Synap as the agent’sAgentMemory; CAMEL then calls it for context on every turn.
Core concepts
SynapAgentMemory
Unlike a bolt-on store, CAMEL’sAgentMemory.get_context() is the sole source of the model’s input: it returns whatever the memory’s retrieve() yields. So Synap augments CAMEL’s history rather than replacing it: SynapAgentMemory subclasses ChatHistoryMemory (which keeps the live conversation) and adds two things.
- Recall.
retrieve()returns the real conversation (system + user + assistant) with Synap’s long-term memories prepended as a system context block, fetched viasdk.fetchusing the latest user turn as the query. A Synap blip degrades to the plain local history; recall never crashes the turn. - Persistence. When a turn completes, the accumulated transcript is ingested via
sdk.memories.create(server-side extraction) under a stabledocument_id, so future sessions remember it.
ChatAgent(memory=...)). Do not assign agent.memory = ... afterward; that path re-runs retrieve/clear/write and would amplify the injected context.
create_synap_tools
For agents that want model-driven memory instead of, or alongside,SynapAgentMemory. Returns search_memory and store_memory as CAMEL FunctionTool objects.
synap_st_system_message
CAMEL’ssystem_message is a static string, so short-term context is folded into it once at construction.
conversation_id is required. Empty context is a no-op; SDK failures are swallowed by default (on_error="fallback"), or set on_error="raise" for strict environments.
Complete example: multi-user support agent
Advanced patterns
Sync interface, async SDK
CAMEL’sAgentMemory methods are synchronous, so SynapAgentMemory bridges to the async Synap SDK internally (via the shared run_async helper). This works whether you drive the agent with agent.step(...) (sync) or agent.astep(...) (async), but construct the SDK, the memory, and run the agent on one asyncio event loop.
Error policy
- Reads (recall,
search_memory) degrade: a Synap failure returns no recall and the turn continues. - The persistence write runs inside the agent loop, so it is best-effort by default (
on_error="fallback"): a transient outage never discards the model’s just-produced response. SetSynapAgentMemory(..., on_error="raise")for strict environments. - The explicit
store_memorytool raisesSynapIntegrationErroron failure.
Not a vector store
SynapAgentMemory deliberately does not reduce Synap to a VectorDBBlock behind CAMEL’s storage. It owns both the recall shape (Synap’s formatted context) and the write pipeline (server-side extraction), which a dumb vector backend would throw away.
Going further
- Scoping.
user_idandcustomer_idflow straight to Synap; per-user isolation and B2C/B2B scope are derived server-side from the ids you pass.
Next steps
SDK: Ingestion
How
memories.create extraction differs from conversation recording.Integrations overview
Every framework Synap plugs into.