---
title: "Giving AI agents a past"
description: "AI agents start every run without a past. What giving AI a past means: event time, sources, supersession, and how agents track the past accurately."
canonical: https://past.dev/blog/giving-ai-a-past
date: 2026-08-30
category: Research
authors: The past.dev team
---
# Giving AI agents a past

An AI agent begins every run without a past. Language-model calls are stateless, so giving AI a past means building an external record: facts with dates, sources, and the history of how they changed. This article defines that record and the architecture that keeps it accurate.

## Why AI has no past by default

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.

## What a past is, technically

A queryable past 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.

## Can AI track the past and changes accurately?

Yes, under two conditions. Change must be recorded during ingestion: overwriting removes the previous value, and 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.

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

## Giving your AI a past, concretely

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` requires an identity and returns ranked documents with dates and source excerpts.

Applications apply their own answer and sufficiency policy to the returned documents, and handle HTTP failures separately. 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 `GET /api/v1/ingest/{ingestionId}` reports `status: "completed"` for that send 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.

## The past as infrastructure

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. The facts an agent has accumulated, with their dates, sources and changes, are the part users cannot rebuild elsewhere and the part audits ask about.

The model does the reasoning. past.dev keeps the past.