Production Patterns
Use a small set of repeatable rules for scope, failures, observability, and model safety. These rules apply whether you call MemorySync from Python, Node.js, or direct HTTPS.
Build every request from trusted state
- 01
Authenticate
Verify the user and action in your own application.
- 02
Resolve scope
Select the project and stable opaque end-user ID on the server.
- 03
Call
Use the matching client with credentials loaded from a secret store.
- 04
Inspect
Branch on the documented result or typed error.
- 05
Return
Expose only fields your application authorizes.
Treat interrupted writes as uncertain
A write timed out or lost its response. What next?
You received a documented success response
The SDK returned a created, skipped, updated, or deleted result.
Use: Use that operation-specific result.
The server rejected the request
Authentication, validation, or not-found failures need correction or a user-facing state.
Use: Do not retry the same request unchanged.
The result is unknown
A timeout or network failure does not prove whether the server applied a mutation.
Use: Reconcile through a safe read before repeating the write.
Classify failures before retrying
Correct the credential, session, permission, or selected scope.
Correct fields or state; do not retry unchanged.
Show a normal unavailable state without revealing other scopes.
Use the typed retry delay when present and bound attempts.
Reads can be retried with bounded backoff; reconcile uncertain writes.
Keep the product state recoverable and avoid blind write retries.
Log enough, but not secrets
| Log | Avoid |
|---|---|
| Operation name, safe application correlation ID, status class, latency | API keys, bearer tokens, passwords, refresh tokens |
| Server request ID when the error provides one | Raw memory text or complete response bodies by default |
| Project alias or internal safe identifier when policy permits | Email addresses or arbitrary end-user identifiers |
| Retry attempt and final outcome | Webhook secrets or credential-bearing URLs |
Treat retrieved memory as untrusted data
Trusted instructions
Owned by your application.
- System policy.
- Tool authorization.
- Output and safety rules.
Retrieved memory
May contain user-controlled text.
- Delimit it as context.
- Select only relevant records.
- Never let it override trusted instructions.
Production checklist
- Keep every credential in trusted server code.
- Test that one project or end user cannot access another scope.
- Branch on created and skipped Add responses.
- Bound read retries and reconcile uncertain mutations.
- Close clients deterministically where the language provides lifecycle hooks.
- Review logs, exports, deletion, token handling, and support escalation before launch.