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 in an MCP client, shift into a backend SDK worker, and later run inside a custom orchestration framework. If memory belongs to the harness, each move requires replaying transcripts, remapping state, or losing context.

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.

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 ontology first, retrieve scoped records and semantic episodes, then let the current harness act on durable state.

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 case study: 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.