Blueprint: customer-success copilot
One customer memory. Any model provider.
A support account accumulates FACT records like a renewal-language preference, EPISODE summaries of past conversations, and REFERENCE links, all scoped by accountId. RushDB keeps that memory in one project outside any single provider's session, so when a workflow moves from one model to another, the new provider reads the same active FACT and EPISODE records instead of starting cold or replaying an entire transcript.
Shared LLM memory is a RushDB blueprint that stores customer FACT, EPISODE, and REFERENCE records in one provider-agnostic project, so switching the underlying LLM does not reset an account’s context.
Provider-specific history fragments customer context.
When memory belongs to a provider session, switching from one LLM to another for the next workflow either resets the account's context or forces the application to replay an oversized transcript just to reconstruct facts the system already learned. Overwriting a changed FACT in place also erases the history of what was true before, so nobody can explain why the assistant behaved differently last month.
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.
Account data arrives as ACCOUNT, FACT, EPISODE, and REFERENCE records — for example a renewal_language FACT or an anthropic-sourced EPISODE summary — and RushDB writes each independent of which provider produced it. A managed index on EPISODE.summary makes prior conversations searchable immediately, while PROVIDER_RUN records stay attached as audit metadata rather than as the source of truth.
01
Normalize as provider events land
RushDB infers types for FACT, EPISODE, and REFERENCE fields regardless of which LLM provider generated the underlying interaction.
02
Auto-link nested structure
A nested account payload with facts, episodes, and references becomes traversable child records under one accountId automatically.
03
Enrich scattered provider history
Suggested-relationship analysis can surface SUPERSEDES links between facts that changed over time or episodes discussing the same topic.
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.
from rushdb import RushDB
db = RushDB('RUSHDB_API_KEY')
schema = db.ai.get_schema_markdown({'labels': ['ACCOUNT', 'FACT', 'EPISODE', 'REFERENCE']}).data
facts = db.records.find({'labels': ['FACT'], 'where': {'active': True, 'ACCOUNT': {'accountId': 'acme-01'}}, 'limit': 20})
episodes = db.ai.search({
'labels': ['EPISODE'],
'propertyName': 'summary',
'query': 'How should we prepare the renewal summary?',
'where': {'ACCOUNT': {'accountId': 'acme-01'}},
'limit': 5,
})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 blueprint: 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 schema
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