---
title: "Memory for customer support agents"
description: "Memory for customer support agents: how an assistant joins tickets, calls, email and billing into one customer, holds the current entitlement with its dated history, and cites the ticket behind every answer."
canonical: https://past.dev/use-cases/customer-support
last-updated: 2026-09-01
---
# Memory for customer support

Source: https://past.dev/use-cases/customer-support

A support assistant answers from four systems with four identifiers that never join: tickets, calls, email and billing. Memory for customer support agents has to resolve one customer across all of them, hold the entitlement they have now alongside the one they had in May, and cite the ticket behind an answer so an agent can check it before repeating it. This page describes what that takes.

## What you are building

An assistant that opens a conversation already knowing the customer: what they bought, what broke last time, what they were promised. It either drafts the reply for a human agent or answers the customer directly, and in both cases it is speaking on behalf of the company.

## Why memory decides whether it works

- **Four systems, four identifiers.** Tickets, calls, email and billing never join, so the assistant answers from one fragment and asks the customer to re-explain the rest.
- **The plan they left is quoted with confidence.** Pre-upgrade tickets sit in the record unmarked. Quoting the wrong entitlement makes a promise rather than an error.
- **Repetition goes uncounted.** A third failed export is a different conversation from the first only if something is counting, and ticket by ticket nothing is.
- **An uncited answer cannot be checked.** An agent who cannot see the source will either repeat it and be wrong, or go and read the history, which is the work the assistant was meant to remove.

## What past.dev provides

- **One customer, however they appear.** An email address, a name in a transcript and a chat handle resolve onto one entity as evidence accumulates.
- **Current entitlement with dated history**, so a plan changed in June has one current value and May is still answerable.
- **Answers that cite the ticket**, so an agent can read the source before repeating it to a customer.
- **An explicit insufficient-evidence status**, so a promise is never invented to fill a gap.
- **Deletion that reaches the derived facts.** Removing a source removes the facts derived from it and the sentences that produced them. See [security](/security).

## Cost and accuracy

Recall is not metered, so a five year old account costs about the same to query as a five day old one and support volume does not price itself out. Accuracy is what decides whether the assistant is allowed to speak to customers at all: dated evidence, supersession and an explicit insufficient-evidence status are the three properties that make a wrong entitlement quote unlikely rather than routine. See [benchmarks](/benchmarks) and [pricing](/pricing).

## Getting there

1. Send tickets, call transcripts, email and billing events to `POST /api/v1/ingest` with their original dates.
2. Load the ticket history you already hold. Backdatable timestamps keep each ticket on its original date rather than arriving as one block of today.
3. Call `POST /api/v1/recall` when a conversation opens, and add the returned evidence to the prompt.
4. Set an `audience` on restricted material so retrieval filters it inside the engine rather than afterwards.

## Frequently asked questions

### Does one customer handled by three agents become three memories?

No. Evidence from every agent and every source contributes to one entity with three sources, so the relationship is answerable as a whole.

### How do we stop the assistant quoting an old entitlement?

Each observation carries the date it happened. The current entitlement is the one supported by the most recent evidence, and the previous one keeps its date in the history rather than competing with it.

### What happens when a customer asks us to delete their data?

Removing a source removes the facts derived from it and the sentences that produced them. The security page documents deletion and the retention windows.

## Related

- [Productivity](https://past.dev/use-cases/productivity)
- [Knowledge base](https://past.dev/use-cases/knowledge-base)
- [Security](https://past.dev/security)
- [Benchmarks](https://past.dev/benchmarks)
- [Quickstart](https://past.dev/docs/memory-api/quickstart)