Agent harnesses change. Memory should stay put.

Harness-specific memory turns every tool change into a migration.

Agent stacks move quickly: a workflow may start inside Claude Desktop as an MCP client, shift into a backend SDK worker, and later run inside a custom orchestration framework. If FACT and EPISODE data belong to the harness instead of a shared graph, each move forces someone to replay transcripts, remap PROVIDER_RUN state, or lose the renewal_language fact and support-ticket REFERENCE entirely, leaving the next harness to start the account context from zero.

Graph intelligence on ingest

Incoming data becomes queryable graph context.

ACCOUNT-scoped FACT, EPISODE, REFERENCE, and PROVIDER_RUN records arrive from whichever harness is active, whether that is an MCP tool call or an SDK worker. RushDB types each record on arrival and keeps accountId as the shared key, so a fact like renewal_language and an episode summary stay attached to the same ACCOUNT regardless of which runtime wrote them.

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.

Data 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.

{
  "accountId": "acme-01",
  "FACT": [{ "key": "renewalLanguage", "value": "Spanish", "active": true }],
  "EPISODE": [{ "summary": "Renewal workflow started in Claude Desktop." }],
  "REFERENCE": [{ "sourceId": "crm-note-19", "kind": "crm_note" }],
  "HARNESS_RUN": [
    { "harness": "claude-desktop", "runId": "run-mcp-01", "status": "completed" },
    { "harness": "backend-sdk-worker", "runId": "run-sdk-02", "status": "queued" }
  ]
}

Working example

Move from an MCP client to a backend worker.

An MCP-connected assistant stores a customer episode. A later SDK worker retrieves the same account facts, relevant episodes, references, and provider runs without relying on the original transcript.

ACCOUNT acme-01
  FACT renewal_language: "Spanish"
  EPISODE "Customer asked for renewal summary"
  PROVIDER_RUN claude-desktop
  REFERENCE support-ticket-884

{
  "labels": ["EPISODE"],
  "propertyName": "summary",
  "query": "How should this renewal workflow continue?",
  "where": { "ACCOUNT": { "accountId": "acme-01" } }
}

{
  "accountId": "acme-01",
  "activeFact": "Send renewal summaries in Spanish",
  "episode": "Customer asked for renewal summary",
  "nextHarness": "backend-sdk-worker"
}

TypeScript SDK

Load the same memory from any harness.

This is the core pattern from the singleton-memory demo: load schema first, retrieve scoped records and semantic episodes, then let the current harness act on durable state.

from rushdb import RushDB

db = RushDB('RUSHDB_API_KEY')

schema = db.ai.get_schema_markdown({
    'labels': ['ACCOUNT', 'FACT', 'EPISODE', 'REFERENCE', 'PROVIDER_RUN'],
}).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 this renewal workflow continue?',
    'where': {'ACCOUNT': {'accountId': 'acme-01'}},
    'limit': 5,
})

Implementation blueprint

Build the harness-portability path.

This blueprint uses the singleton-memory implementation path: provider and harness runs write to one RushDB memory graph while reusable facts, episodes, and references stay independent of the runtime.

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.

How it works

Build the smallest useful workflow first.

Know where it fits.

Questions developers ask.