Docs/Customer support

Example

Customer support

Build a support fleet that keeps customer conversation memory local while sharing approved policy knowledge across workers.

Estimated time: 12 minutes

Level: Intermediate

Prerequisites:Installation·Quick Start·Fleet & Shared Memory

Overview

This example uses MemoGrafterFleet to separate customer-specific context from shared support policy. A support worker uses memory mode both, allowing it to recall its own conversation and the fleet’s shared policy session.

What this demonstrates

Shared fleet policy ingestion.

Worker-local customer conversation memory.

The local, fleet, and both memory scopes.

A response that combines customer context with company policy.

Why shared recall is different from copying or grafting memory.

Architecture

Customer facts remain attached to the support worker. Approved policies live in the fleet’s synthetic shared session and are available to workers configured to use fleet memory.

Customer context

Support worker

Shared policy

Combined response

Memory design

Local worker memory: case details, communication preferences, and conversation history.

Shared fleet memory: refund rules, support procedures, and approved product policy.

Application database: customer identity, authorization, case status, and ticket ownership.

Tags: policy source and version metadata for review—not authorization.

Project structure

files

src/
  memory-config.ts
  support-fleet.ts
  support-example.ts
.env

Step 1: Configure the fleet

src/memory-config.ts

import {
  OpenAIEmbedAdapter,
  OpenAILLMAdapter,
  type MemoGrafterConfig,
} from "memo-grafter";

export const config: MemoGrafterConfig = {
  db: { connectionString: process.env.DATABASE_URL! },
  llm: new OpenAILLMAdapter("gpt-4o"),
  embedder: new OpenAIEmbedAdapter("text-embedding-3-small"),
};

Step 2: Ingest shared policy

src/support-fleet.ts

const fleet = new MemoGrafterFleet(config, {
  id: "support-fleet",
  name: "Customer Support",
  defaultWorkerMemory: "both",
});

await fleet.initialize();

await fleet.ingestToFleet(
  "Refund policy: customers may request a refund within 30 days.",
  {
    tags: ["policy", "policy:refund", "version:2026-07"],
    source: "support-handbook",
  },
);

Step 3: Create a support worker

src/support-example.ts

const support = await fleet.createWorker({
  color: "case-42",
  memory: "both",
});

await support.invoke(
  "The customer prefers email updates and purchased the item 12 days ago.",
);

const answer = await support.invoke(
  "Is the customer eligible for a refund, and how should we contact them?",
);

console.log(answer);

Complete example

src/support-example.ts

import "dotenv/config";

import {
  MemoGrafterFleet,
  OpenAIEmbedAdapter,
  OpenAILLMAdapter,
} from "memo-grafter";

const fleet = new MemoGrafterFleet(
  {
    db: { connectionString: process.env.DATABASE_URL! },
    llm: new OpenAILLMAdapter("gpt-4o"),
    embedder: new OpenAIEmbedAdapter("text-embedding-3-small"),
  },
  { id: "support-fleet", defaultWorkerMemory: "both" },
);

await fleet.initialize();

try {
  await fleet.ingestToFleet(
    "Refund policy: customers may request a refund within 30 days.",
    { tags: ["policy:refund"], source: "support-handbook" },
  );

  const support = await fleet.createWorker({
    color: "case-42",
    memory: "both",
  });

  await support.invoke(
    "The customer prefers email and purchased the item 12 days ago.",
  );

  console.log(
    await support.invoke(
      "Is the customer eligible for a refund, and how should we contact them?",
    ),
  );
} finally {
  await fleet.close();
}

Expected interaction

Local memory contributes the purchase timing and email preference.

Fleet memory contributes the 30-day refund rule.

Expected result: the assistant identifies likely eligibility and recommends email contact.

Exact wording varies, and the application remains responsible for final policy enforcement.

What gets stored

Policy topics and memories in the synthetic shared fleet session.

Customer conversation topics and memories in the worker’s local session.

Fleet and worker metadata used to preserve scope and color identity.

No automatic copy of shared policy into the worker graph; the worker reads both scopes at response time.

Inspect it in Studio

Inspect the fleet shared session to confirm the refund policy and source tags.

Inspect the case-42 worker session for purchase timing and contact preference.

Use Prompt Preview against each scope when debugging missing context.

Confirm private customer facts were not written to shared fleet memory.

Production considerations

Create separate authorized worker/session boundaries for unrelated customers.

Keep policy changes versioned and review them before ingestion.

Do not treat worker colors or tags as access-control mechanisms.

Use application code to validate eligibility and execute refunds.

Close the fleet once; avoid independently closing its underlying core.

Common mistakes

Putting customer-specific private facts into shared fleet memory.

Using the reserved conductor worker color.

Assuming both copies fleet memories into the local worker graph.

Using one worker for unrelated customers without an application isolation policy.

Allowing generated text to make final financial decisions without deterministic checks.

Extensions

Add billing and technical workers with different local scopes.

Use a conductor to transfer selected case context during escalation.

Add conflict/version maintenance for policy changes.

Add user-directed lifecycle controls for incorrect customer memory.