Customer Support Schema

How MemoryOS remembers customer support context for support bots, copilots, and helpdesk platforms.

The Customer Support Schema is for support chatbots, agent-assist copilots, CRM AI, and helpdesk platforms.

The SDK stays the same. Enable domain_schema: "support" and MemoryOS adds a structured support overlay to every add() and get() call.

What it stores

Field	Meaning
support_type	Active support vertical for this customer
customer_identity	Account hints, tier, name, verified status
communication_preference	Channel, tone, detail level, technical comfort
language_profile	Preferred language and regional style
current_open_issue	The issue future replies should start from
issue_history	Useful prior issues without dumping every ticket
resolution_preference	Refund, replacement, callback, workaround, escalation, or self-serve
sentiment_pattern	Frustration, repeat complaint, escalation risk, or easy-to-resolve
risk_signals	Fraud, churn, legal, compliance, VIP, or safety signals
support_context	Vertical-specific context: orders, invoices, bookings, plans, transactions

Support types

saas, ecommerce, banking_fintech, travel, telecom, edtech_support, general_info

Enable

From the workspace dashboard: Settings → Domain Schema → Customer Support Schema, or via API:

PATCH /v1/tenant/domain-schema
Authorization: ApiKey mem_...
Content-Type: application/json

{ "domain_schema": "support" }

Routing modes

Mode	Use when
single	One vertical — SaaS, ecommerce, banking, travel, telecom
multi	Helpdesk platform serving many verticals
auto	Early testing or broad demos

Single vertical:

{
  "support_type_mode": "single",
  "support_type": "banking_fintech",
  "support_types_allowed": []
}

Multi-vertical helpdesk:

{
  "support_type_mode": "multi",
  "support_type": null,
  "support_types_allowed": ["saas", "ecommerce", "banking_fintech", "travel", "telecom", "general_info"]
}

Classification happens inside the extraction pass — no separate detection call.

Retrieval safety rules

Support retrieval prepends guardrails to system_prompt_addition:

Support memory usage rules:
- Treat this as remembered customer context, not live system truth.
- Do not claim you checked, changed, refunded, cancelled, verified, located, or triggered anything
  unless your own tool/API result confirms it.
- If live system data is needed, say you need to check the relevant support system.

For banking_fintech:

- Never ask for or repeat OTPs, passwords, full account numbers, full card numbers,
  Aadhaar, or PAN values.

These add no extra LLM call — just a few deterministic prompt tokens.

MemoryOS vs. your support tools

Belongs in MemoryOS	Belongs in your systems
Customer prefers refunds over replacements	Current order status
Unresolved billing issue from last session	Current invoice status
Customer contacted support three times	Account owner verification
Escalation risk signals	Refund creation
Communication style preference	Ticket SLA timer

The recommended flow:

1. mem.get() — remembered support context
2. your tools — live truth (orders, invoices, tickets)
3. combine both in the model call
4. mem.add() — store the conversation

PII guidance

Prefer stable internal IDs for external_user_id. Keep ticket IDs in metadata. Never send raw card data, OTPs, passwords, Aadhaar, PAN, full account numbers, or full passport numbers to MemoryOS. PNR values for travel are fine — they’re operational references, not financial credentials.

Dashboard endpoints

Need	Endpoint
Customer support memory list	GET /v1/tenant/customers
Aggregate support stats	GET /v1/tenant/support-stats
Configure routing	PATCH /v1/tenant/support-type
Current domain config	GET /v1/tenant/domain-schema

Use SDK get() for model calls, not dashboard endpoints.

Related pages

• Cookbook: support agent memory
• Domain schemas