---
title: "Memory for LlamaIndex agents"
description: "LlamaIndex Memory manages chat history and memory blocks per session. What it stores, its limits, and a FunctionTool that adds temporal memory over HTTP."
canonical: https://past.dev/integrations/llamaindex
last-updated: 2026-09-02
---
# Add memory to LlamaIndex agents

Source: https://past.dev/integrations/llamaindex

LlamaIndex documents a Memory class for agents: a short-term queue of recent chat messages that flushes into long-term memory blocks under a token budget. It is conversation memory, scoped to a session id and stored in a database the application configures. It models no fact validity, supersession or evidence status. This page states what the documented system covers and shows a FunctionTool that connects any LlamaIndex agent to temporal memory over HTTP.

## What LlamaIndex memory covers

The [memory guide](https://developers.llamaindex.ai/python/framework/module_guides/deploying/agents/memory/) documents a `Memory` class built around a FIFO queue of chat messages. `token_limit` caps what the object holds, `chat_history_token_ratio` sets the short-term share, and when the queue exceeds its budget, batches of `token_flush_size` tokens move into long-term memory blocks. A `session_id` names the conversation. The default backing store is an in-memory SQLite database; pointing the object at a database URI makes it persistent. Agents accept the object per run: `agent.run(question, memory=memory)`.

Long-term memory is a set of blocks. `StaticMemoryBlock` holds fixed text such as a persona. `FactExtractionMemoryBlock` has an LLM extract fact lines from flushed messages, up to `max_facts`. `VectorMemoryBlock` writes flushed batches to a vector store and retrieves them by similarity. Each block carries a `priority`: zero is always kept, higher numbers are truncated first when the context budget fills.

- **Flushing is budget-driven.** Messages reach long-term blocks when token limits overflow, so what persists depends on context pressure and on the extraction prompt rather than on a decision about the fact itself.
- **Fact lines are undated.** An extracted fact records no event time, no validity window and no link to the fact it replaced. A January value and a March value are two lines of text, and similarity cannot say which one is current.
- **Scope is the session you name.** Memory persists where its database lives and under the `session_id` the application passes. Sharing across agents, products and users is left to application design.

## The integration: a FunctionTool per endpoint

LlamaIndex converts plain functions into tools. The [tools guide](https://developers.llamaindex.ai/python/framework/module_guides/deploying/agents/tools/) documents `FunctionTool.from_defaults`, which wraps a sync or async function, taking the name from the function and the description from its docstring. The [agent classes](https://developers.llamaindex.ai/python/framework/module_guides/deploying/agents/) (`FunctionAgent`, `ReActAgent`) accept a `tools` list. Two functions connect any of them to past.dev; the [API reference](/docs/memory-api/api-reference) documents all four endpoints.

```python
import os, requests
from llama_index.core.tools import FunctionTool
from llama_index.core.agent.workflow import FunctionAgent

BASE = "https://api.past.dev/api/v1"
HEADERS = {"Authorization": f"Bearer {os.environ['PAST_API_KEY']}"}

def remember(text: str, happened_at: str) -> str:
    """Store a durable fact with the time it actually happened (ISO 8601)."""
    r = requests.post(f"{BASE}/ingest", headers=HEADERS,
                      json={"content": text, "timestamp": happened_at}).json()
    return r.get("sourceId", "stored")

def recall(question: str) -> str:
    """Return ranked, dated evidence and a status value for a question."""
    r = requests.post(f"{BASE}/recall", headers=HEADERS,
                      json={"query": question}).json()
    return str(r)

agent = FunctionAgent(
    llm=llm,  # any LlamaIndex LLM
    tools=[FunctionTool.from_defaults(remember),
           FunctionTool.from_defaults(recall)],
    system_prompt=(
        "Recall before answering questions about people, decisions or history. "
        "Remember durable facts with their original timestamps."
    ),
)
```

Keep `Memory` on the run for conversational flow. The tools carry the durable record: facts stored at their original event time, recalled with dates, sources and a status the agent can cite.

## Routing on recall status

Applications can route on `status`. `Supported` means the evidence establishes the answer. `Conflicted` returns evidence from credible sources that disagree. `NoKnownSupport` means the stored evidence does not establish an answer. `UnknownBecauseDegraded` means retrieval could not complete and should be treated as an unknown result.

An agent workflow can branch on the value. `Supported` evidence becomes the answer, with its date and source in the reply. `Conflicted` evidence is presented as a disagreement between named sources. `NoKnownSupport` is reported as a gap in the record. `UnknownBecauseDegraded` triggers a retry or a fallback path rather than an answer.

## A worked example: the budget that changed

A client emails on January 8 that the renewal budget is 30k. A call on March 12 raises it to 45k. Inside `Memory`, both statements were flushed as text. `VectorMemoryBlock` retrieval returns both passages, because both are similar to the question, and neither passage carries the date it was true. A fact line extracted from either message is a sentence without a timeline.

Ingested through the tool with their original timestamps, the two statements become one fact with a history: the January value has a closed [validity window](/glossary/validity-window), the March value is current, and each carries its source. Recall returns 45k as `Supported` with dates, and it can also answer what the budget was in February, because the superseded value keeps its dates. The [quickstart](/docs/memory-api/quickstart) shows the four calls, and the [benchmarks](/benchmarks) document how recall is measured. [Session memory](/glossary/session-memory) and [cross-session memory](/glossary/cross-session-memory) define the two layers this page separates.

## Frequently asked questions

### Does LlamaIndex have built in long term memory?

Yes. The Memory class flushes older chat messages into long-term memory blocks: static text, LLM-extracted fact lines, or vector retrieval over past messages. The blocks live with the session and the database you configure.

### Do I still need the Memory class if I use a memory API?

Yes. Memory carries the conversation so the agent can follow recent turns and references. The API carries durable facts with dates, sources and an explicit status, shared across sessions, agents and products.

### Can a LlamaIndex agent remember a user across sessions?

Within the framework, persistence requires a database-backed Memory and a session design that maps to your users. A memory service moves that record outside the process, so any session or agent with the right key recalls the same user history.

## Related

- [Memory for CrewAI](https://past.dev/integrations/crewai)
- [Memory for LangGraph](https://past.dev/integrations/langgraph)
- [Memory for the Vercel AI SDK](https://past.dev/integrations/vercel-ai-sdk)
- [What is agent memory?](https://past.dev/what-is-agent-memory)
- [Quickstart](https://past.dev/docs/memory-api/quickstart)