---
title: "How AI agents retain history"
description: "How AI agents retain facts across runs, track changes, preserve sources, and report when the available history does not support an answer."
canonical: https://past.dev/blog/giving-ai-a-past
date: 2026-08-30
category: Research
authors: The past.dev team
---
# How AI agents retain history

AI agents retain history in external storage because language-model calls are stateless. The storage must record dates, sources and changes when an agent needs current or historical answers.

## Why AI agents retain history outside the model

A language model does not retain state between calls. Applications commonly use one of three methods to supply previous information.

- **Chat history** replays transcripts. It grows with every turn and does not identify current facts.
- **A vector store** retrieves similar text. It does not record when a statement was valid or whether another statement replaced it.
- **Notes files** store selected information. Their treatment of dates and updates depends on conventions enforced by the application.

An agent that answers questions about changing facts needs a data model for time in addition to stored text.

## Requirements for stored history

A queryable history requires four properties.

1. **Event time.** Each fact carries the date it became true, taken from the source rather than the import date.
2. **Provenance.** Each fact points to the record that supports it: the email, the transcript, the ticket.
3. **Supersession.** When a fact changes, the old value closes and the new value opens. Both remain queryable with their dates.
4. **Evidence status.** The response indicates when the stored evidence does not establish an answer.

The structure that carries these properties is a [temporal knowledge graph](/glossary/temporal-knowledge-graph): entities, facts, validity windows, and links from each fact to what replaced it.

## Tracking changes accurately

Change must be recorded during ingestion. Overwriting removes the previous value. Append-only storage keeps both values without identifying which one is current. [Fact supersession](/glossary/fact-supersession) closes the previous fact's validity window and records its replacement. Retrieval cannot reconstruct a value that was removed during ingestion.

Evaluation should include current values, previous values, backdated records and unsupported questions. Our [benchmark methodology](/benchmarks/methodology) defines these tests. The [benchmarks page](/benchmarks) reports past.dev results and configurations.

## How AI agents retain history with past.dev

The integration uses two primary API operations.

- `POST /api/v1/ingest` accepts raw text with its original timestamp. Entity resolution links references to the same person across email, transcripts and chat.
- `POST /api/v1/recall` returns ranked evidence with dates, sources and a `status` of `Supported`, `Conflicted` or `NoKnownSupport`.

Applications can route each status explicitly. `Supported` permits an answer with citations. `Conflicted` returns evidence for the disagreement. `NoKnownSupport` indicates that the stored evidence does not establish an answer. The [quickstart](/docs/memory-api/quickstart) shows the API calls. [What is agent memory?](/what-is-agent-memory) covers the broader category.

Ingestion and recall are separate operations. The application should wait until an ingestion reports `settled: true` before querying updated facts. It should also provide a stable source identifier when records may be updated or deleted. Entity resolution should be tested across the identifiers used in production, including names, email addresses and chat handles. These steps prevent partial updates and duplicate identities from affecting recall.

## Operational requirements

Production memory needs a defined API contract, measured accuracy, source attribution, deletion controls and export support. These requirements apply independently of the model used to generate the final answer.