Frequently Asked Questions

Seizn Memory is an AI memory infrastructure that provides persistent, searchable memory for AI applications. Unlike vector databases that only store/search vectors, Seizn includes the full product layer: memory extraction, policy management, key management, deletion, audit logs, and SDKs. It solves the problem of maintaining context across AI sessions and enabling personalized AI experiences.

Vector databases are storage/search infrastructure for vectors. Seizn is a complete memory system built on top of that, providing: automatic memory extraction from conversations, memory type classification, namespace/scope management, API key rotation, audit logging, SDKs, and governance features. Think of it as 'memory infrastructure' vs 'search infrastructure'.

No. The most common starting point is: store memory -> search -> inject into prompt. RAG (automatic context composition + response generation) is the next step. You can start simple and add complexity as needed.

1) POST /api/memories to store a user preference. 2) GET /api/memories to search. 3) Inject the results into your LLM prompt. 4) Later, add /api/extract for auto-extraction and /api/query for memory-augmented responses.

Store information that remains valid across conversations: preferences (tone, language, format), facts (job, tools, project structure), instructions ("always summarize in tables"), relationships ("Alice is the team lead"). Avoid storing temporary or session-specific data unless using session scope.

Never store: passwords, API keys, tokens, session cookies (auth info), SSN, passport numbers, bank accounts (PII), credit card info (payment data). For temporary data, use session scope with TTL if needed.

Namespace separates memories by project/tenant/environment. Without it, data gets mixed, search quality drops, and deletion/export becomes painful. Recommended: 'org:acme/app:chat/env:prod' or 'project:myapp/env:staging'. Never use just 'default' in production.

user: Preferences that apply to a user globally. session: Goals or context valid only for this conversation. agent: Rules specific to one agent in a multi-agent system. Using scope properly reduces prompt length and improves response consistency.

memory_type classifies memories: fact (unchanging info), preference (user choices), instruction (rules to follow), relationship (people/org connections), experience (past events). This is the most powerful axis for filtering, deletion, and policy application.

limit: Number of candidate memories to retrieve (too low = miss relevant ones, too high = noisy context). threshold: 0-1 similarity cutoff (higher = stricter). Start with limit=10, threshold=0.7. If missing memories, lower threshold to 0.6 and raise limit to 20. If getting irrelevant results, raise threshold to 0.75-0.8.

Usually one of: 1) namespaces are mixed, 2) too many memories stored (noise), 3) threshold too low, 4) content is too abstract ('likes things' vs specific facts). Fix: separate namespaces, make content specific, raise threshold.

Add importance scoring and keep only high-importance memories. Use TTL to auto-expire old memories. Periodically merge similar memories into summaries. Separate namespaces to reduce search scope.

Recommended flow: 1) Call with auto_store=false to preview extracted memories. 2) Show results to user for confirmation. 3) Store only approved memories. 4) Once extraction quality is proven, switch to auto_store=true for automation.

haiku: Faster, cheaper, good for most cases. sonnet: More accurate, better for important extractions (onboarding, contracts, policies). Use haiku for bulk/initial extraction, sonnet for high-stakes scenarios.

Yes, but the recommended pattern is: create new memory + delete/archive old one. This approach is better for audit trails and prevents regression issues.

Two approaches: 1) Delete by ID (precise), 2) Delete by namespace (bulk cleanup). For enterprise/compliance, ensure 'complete deletion + audit log'. Document your deletion policy clearly.

You've hit the rate limit. Solutions: 1) Implement exponential backoff (1s -> 2s -> 4s). 2) Queue requests server-side. 3) Reduce request frequency: cache duplicate queries, batch operations, lower extract frequency.

Biggest cost drivers: 1) Extract frequency - reduce calls. 2) Search scope - use namespace to narrow. 3) Model choice - use haiku for routine, sonnet for important. 4) Caching - cache repeated queries. 5) Batch operations when possible.

Not recommended - high risk of key exposure. Call Seizn from your server (Next.js Route Handler, Cloudflare Worker, serverless function) and have the browser call your server. Never expose API keys to client-side code.

They'll want: 1) Data scope (what's stored/not stored), 2) Encryption (at rest: AES-256, in transit: TLS), 3) Tenant isolation method, 4) Deletion/retention policy, 5) Audit log access, 6) Key rotation/expiration policy. Keep a Security & Governance page in your docs.

We provide official SDKs for TypeScript/JavaScript (npm install seizn), Python (pip install seizn), and REST API for any language. All SDKs include TypeScript types, automatic retries, and streaming support.

Basic integration (store/search memories) takes 1-2 hours. Adding extraction takes another 2-4 hours. Full production deployment with governance policies typically takes 1-2 weeks including testing and security review.

Seizn's embeddings support 100+ languages. Store content in any language and search will work cross-lingually. For best results, keep a 'language' metadata field and filter by it when you want language-specific results.

Yes. Use the 'filters' parameter to narrow by metadata (namespace, scope, memory_type, custom fields) before semantic ranking. This hybrid approach gives you both precision and recall.

Check the 'status' field in the response. If extraction fails: 1) Verify input format is correct, 2) Check if content is too short (<50 chars often fails), 3) Try a different model. Set up retry logic with exponential backoff for transient errors.

Yes. Use the 'extraction_prompt' parameter to guide the model. You can specify: which memory types to extract, minimum importance threshold, specific fields to look for, and custom output schema.

Export your existing data to JSON with fields: content, metadata, created_at. Use our bulk import API (POST /api/memories/import) with batches of 100-500 items. Run a parallel validation query set to ensure quality matches.

Use the export API (GET /api/memories/export) to create periodic backups. Schedule daily exports for critical namespaces. Store exports in your own object storage (S3, GCS) with versioning enabled.

Seizn is built on SOC 2 Type II compliant infrastructure (Supabase). Our own SOC 2 certification is in progress (ETA Q3 2026). EU region deployment is available for Enterprise customers by request. Contact our sales team for security questionnaires or compliance documentation.

Use DELETE /api/memories with user_id filter to remove all memories for a user. Enable audit logging to prove deletion. Set retention policies to auto-delete after a period. Export user data with GET /api/memories/export?user_id=xxx for data portability requests.