Synap should make your agent better when it’s available, and not break your agent when it isn’t. Treat retrieval and ingestion as best-effort in the hot path — never let them stop the LLM from generating a response.Documentation Index
Fetch the complete documentation index at: https://docs.maximem.ai/llms.txt
Use this file to discover all available pages before exploring further.
The shape of “good enough” degradation
What to watch in production
Three metrics that should be on your dashboard from day one:| Metric | What it tells you | Page if |
|---|---|---|
synap_context_timeout_rate | Are users seeing degraded responses? | > 1% over 5 min |
synap_ingest_dropped_rate | Are you losing memory? | > 0.1% over 1 hour |
synap_correlation_ids_in_errors | Sample of correlation_id values for support | Always log; sample 5% to your error tracker |
SynapError exposes e.correlation_id — log it. When you need to ask support, they need that ID.
Don’t do these things
- Don’t fail the request on a Synap timeout. The LLM can answer without memory. The user gets a slightly worse response. Failing the request gets you an outage.
- Don’t retry permanent errors.
InvalidInputError,ContextNotFoundError,AuthenticationErrorwon’t get better with retries. Fix the input or the credentials. - Don’t block on ingestion in the hot path. Always background it. The user shouldn’t wait for memory persistence to see the next assistant message.
- Don’t catch and swallow without logging. Every catch should at minimum log the
correlation_id. Silent swallows make production debugging hopeless.
Where the SDK already retries for you
SynapTransientError subclasses — NetworkTimeoutError, RateLimitError, ServiceUnavailableError, AgentUnavailableError — are retried automatically inside the SDK using the configured RetryPolicy. By the time one of these reaches your except block, the SDK already tried 2–3 times. So your wrapper retries are belt-and-suspenders for genuinely down-for-a-while scenarios.