---
title: "Memory for productivity tools and workspace assistants"
description: "Memory for productivity tools: how an assistant inside a workspace answers from meetings, documents and chat, resolves one colleague across all of them, and keeps the current decision separate from the one it replaced."
canonical: https://past.dev/use-cases/productivity
last-updated: 2026-09-01
---
# Memory for productivity tools

Source: https://past.dev/use-cases/productivity

An assistant inside a productivity tool answers questions about a workspace: what a team decided, who owns a project, what changed since last month. Memory for productivity tools has to join meetings, documents and chat into one record, resolve a colleague across all of them, and keep a superseded decision from answering as the current one. This page describes what that takes.

## What you are building

An assistant that sits inside the tool a team already works in and answers from the team's own record. The questions are ordinary: what did we decide about the pricing change, who is running the migration now, what did this customer ask for in June. Every one of them is answered from material spread across meeting transcripts, documents, chat threads and email.

## Why memory decides whether it works

- **The decision is outranked by the discussion.** Twenty passages resemble the pricing decision. The message that settled it is one of them, and similarity ranking has no way to prefer it.
- **One colleague appears six ways.** A calendar invite, a speaker label, an email address and a chat handle are four records of one person. Until they resolve, every question about them answers from part of the record.
- **Last quarter's answer is still current.** A decision reversed in June sits beside the reversal with nothing recording their order.
- **The team stops trusting it once.** An assistant that answers a workspace question wrongly in front of five people is closed and not reopened, whatever it gets right afterwards.

## What past.dev provides

- **One entity per person, company and project**, resolved across every source you send, including after somebody changes team or employer.
- **A current value with its dated history.** The reversal answers the question and the reversed decision keeps its date for historical ones. See [fact supersession](/glossary/fact-supersession).
- **Evidence with every answer**, so a reader can open the message a claim rests on.
- **An explicit insufficient-evidence status**, so the assistant reports that the workspace does not record something rather than composing an answer.
- **Audience filtering inside the search.** A data point carries an `audience` list and retrieval filters on it in the engine. Audiences are configured with past.dev during early access.

## Cost and accuracy

Ingestion is metered by the size of what you send. Recall is not metered, so questions are free and a workspace with four years of meetings costs about the same per question as one opened last week. The alternative, resending history into the context window on every question, grows with the workspace and still leaves the model to choose between a decision and its reversal. Accuracy is published on [benchmarks](/benchmarks), with the method at [how to reproduce it](/benchmarks/methodology). See [pricing](/pricing) for the credit rules.

## Getting there

1. Send transcripts, documents and messages to `POST /api/v1/ingest` with the time each happened.
2. Backfill what you already store. Timestamps are backdatable and ingestion is idempotent by content hash, so a replay that crashes can re-run from the start safely.
3. Call `POST /api/v1/recall` before any answer that depends on workspace state, and add only the returned evidence to the prompt. [Context engineering](/context-engineering) covers assembly.
4. Branch on the returned status: answer with dates when the evidence supports it, surface the conflict when it does not agree, and say so when there is no support.

## Frequently asked questions

### Does one person's memory leak into another's?

Evidence accumulates across a workspace onto shared entities, which is what makes a team question answerable at all. Where material must stay restricted, a data point carries an audience list and retrieval filters on it inside the engine.

### Do we design a schema first?

No. Ingestion takes text and a timestamp. Extraction, entity resolution and temporal storage run inside the API, so there is no field mapping exercise before the first useful answer.

### Can we load the history we already have?

Yes. Timestamps are backdatable, so existing transcripts keep their original dates rather than all arriving today, and idempotent ingestion makes the load safe to repeat.

## Related

- [Knowledge base](https://past.dev/use-cases/knowledge-base)
- [Customer support](https://past.dev/use-cases/customer-support)
- [What is agent memory?](https://past.dev/what-is-agent-memory)
- [Benchmarks](https://past.dev/benchmarks)
- [Quickstart](https://past.dev/docs/memory-api/quickstart)