---
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-10-16
---
# 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

- **Identity-aware context.** Supply a consistent identity across integrations and retain the source details needed to interpret each record.
- **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.
- **Evidence for grounded answers.** Your application assesses whether the returned sources support an answer and abstains when they do not.
- **Audience-aware access.** A data point names an audience slug, and reads return the memory visible to the requested identity. Audiences are managed in the console or with the API.

## Cost and accuracy

Plan for both ingestion and recall volume against the published allowances. Evaluate answer quality with dated source evidence and an application-level abstention policy. See [pricing](/pricing) and [benchmarks](/benchmarks) for current limits and measured results.

## 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. Inspect the returned documents and excerpts before answering. When the selected page does not support an answer, ask for clarification or say that the available memory is insufficient.

## Frequently asked questions

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

Evidence from multiple sources can be recalled within a project. An audience slug restricts a data point to the identities that can access it.

### Do we design a schema first?

Ingestion accepts text and an original timestamp. Your application can also supply source ids, identity and audience information; see the API reference for the current fields.

### 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)