Case study: customer-success copilot
One customer memory. Any model provider.
Keep durable facts, prior episodes, and references in one RushDB project so changing the model does not reset the customer journey.
Provider-specific history fragments customer context.
A support conversation may start with one model and continue in another workflow later. If memory belongs to the provider session, the next assistant either starts cold or receives an oversized transcript.
Before
- Facts hidden inside provider conversation history
- A model switch resets useful context
- Whole transcripts replayed into later prompts
- Updated facts overwrite history invisibly
With RushDB
- Facts, episodes, and references stored explicitly
- Every provider reads the same memory project
- Recall filtered to the correct account
- Superseded facts remain explainable
Graph intelligence on ingest
Incoming data becomes queryable graph context.
RushDB turns structured data into graph-ready context without a separate modeling pipeline. Structure already encoded in a nested payload is linked immediately. For flat records imported from scattered sources, relationship analysis can propose stable cross-source patterns.
01
Normalize as data arrives
Import JSON or CSV. RushDB infers property types and adds new fields to the live, queryable ontology without a schema migration.
02
Auto-link nested structure
Nested objects become connected records automatically, preserving the parent-child graph structure already encoded in your payload.
03
Enrich scattered sources
After flat imports or schema changes, analyze the project ontology. RushDB can suggest join patterns and semantic relationship types for your review.
Suggested relationship analysis requires an LLM configured for the project. Suggestions stay in draft form until you approve them, so inferred domain meaning never mutates the graph silently. You can also add explicit relationships through the SDK or API.
Review suggested relationship patternsData model
One flexible graph for the workflow.
Start with the payload shape your product already produces. RushDB stores it as Records, infers typed properties, and keeps nested or approved domain relationships queryable.
Reusable facts, compact episodes, references, and provider runs stay outside any one model session.
{
"accountId": "acme-01",
"name": "Acme Corp",
"FACT": [
{ "key": "renewalLanguage", "value": "Spanish", "active": true }
],
"EPISODE": [
{ "provider": "anthropic", "summary": "Customer asked for renewal summary." }
],
"REFERENCE": [{ "sourceId": "ticket-884", "kind": "support_ticket" }],
"PROVIDER_RUN": [{ "provider": "openai", "model": "gpt-4.1", "status": "completed" }]
}Working example
Switch models without losing the account history.
One provider stores a renewal preference. A later workflow recalls that fact from the shared memory layer, independent of which model handles the request.
{
"accountId": "acme-01",
"FACT": [{ "key": "renewal_language", "value": "Send renewal summaries in Spanish.", "active": true }],
"EPISODE": [{ "provider": "anthropic", "summary": "Customer asked for renewal summary." }]
}{
"labels": ["EPISODE"],
"propertyName": "summary",
"query": "How should we prepare the renewal summary?",
"where": { "ACCOUNT": { "accountId": "acme-01" } }
}{
"accountId": "acme-01",
"activeFact": "Send renewal summaries in Spanish.",
"episode": "Customer asked for renewal summary."
}TypeScript SDK
A complete starting point.
The example includes the one-time index setup so the retrieval path is explicit.
Implementation blueprint
Build the provider-neutral memory path.
Use this sequence to keep customer memory outside any one model provider while preserving provider-run audit records.
- 01Import ACCOUNT, FACT, EPISODE, REFERENCE, and PROVIDER_RUN records
- 02Create managed indexes for FACT.value and EPISODE.summary
- 03Log each provider run as metadata, not as the source of truth
- 04Supersede changed facts instead of overwriting history
- 05Retrieve active facts and relevant episodes by account ID
Build path
- Keep reusable facts, episodes, and references in RushDB records.
- Keep provider runs as audit metadata connected to the account.
- Retrieve context through account-scoped filters and semantic episode search.
- Use SUPERSEDES-style relationships when facts change.
Relevant docs
Read the exact primitives behind this pattern.
These links point to the RushDB docs pages that map directly to this case study: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.
Records
Store durable facts, episodes, references, and provider runs as explicit records outside any one model session.
Open docsAI overview and ontology
Let each provider or agent inspect the live schema before reading or writing shared memory.
Open docsSemantic search
Recall compact episodes and references by meaning, scoped to the current account or tenant.
Open docsHow it works
Build the smallest useful workflow first.
01
Separate memory from the model
Write durable facts, episode summaries, and references through one application-owned interface.
02
Preserve revisions
Create a new fact and supersede the old one when customer context changes instead of mutating history invisibly.
03
Retrieve only useful context
Ask for the current account-specific memories needed by the active workflow.
Know where it fits.
Provider-agnostic by design
RushDB stores application memory outside any one LLM provider, so model selection can change without moving customer state.
Plan memory lifecycle rules
Archive old episodes and keep active facts easy to retrieve as the account history grows.
Questions developers ask.
Next step