Skip to main content
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.

The shape of “good enough” degradation

What to watch in production

Three metrics that should be on your dashboard from day one: Every 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, AuthenticationError won’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.

Going further