> For the complete documentation index, see [llms.txt](https://docs.uptiq.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.uptiq.ai/core-concepts/memory-and-learning.md).

# Memory & Learning

By default, an agent starts every conversation knowing nothing about who it is talking to. That is often correct: an agent processing loan documents doesn't need to remember anyone.

But some agents get better by remembering, and Qore separates that into distinct kinds — because they have different scopes, different risks, and different rules about what may enter them.

## Three kinds of memory

| Kind                    | What it carries                                                  | Default              |
| ----------------------- | ---------------------------------------------------------------- | -------------------- |
| **User persona memory** | What an individual user has asked about, preferred, or corrected | Off                  |
| **FAQ memory**          | Canonical answers to questions the agent already knows           | On                   |
| **Learning cases**      | Reviewed corrections from real production behavior               | Manual approval only |

**User persona memory** remembers what an individual user has asked about, preferred, or corrected — across conversations. Turn it on for assistant-style agents where personalization helps. Leave it off for agents handling discrete, stateless tasks, and for headless agents called by API with no persistent user identity: there, it adds noise without benefit.

**FAQ memory** lets the agent reuse a stored canonical answer when a question matches a known FAQ, rather than answering from scratch each time. On by default, and the right default for support-style agents.

{% hint style="info" %}
**Check the scope before you enable memory.** Whether persona memory is confined to one agent or shared more widely determines who can see what a user told which agent — a question worth answering explicitly in a regulated environment. Confirm the current behavior with your platform administrator before turning it on for an agent handling sensitive material.
{% endhint %}

**Learning cases** are corrections captured from real production behavior — a case where the agent got something wrong and a person recorded what the right answer would have been.

## Why learning cases require a human

Learning cases do not enter memory automatically. Each one is reviewed and approved by a person first.

{% hint style="warning" %}
**Auto-approval is intentionally disabled.** This is a deliberate design decision, not a missing feature. An agent that learns automatically from its own traffic can be taught the wrong thing by a bad input — accidentally by an unusual case, or deliberately by someone who works out that it learns. Manual approval is the boundary that makes memory a safe place to write to.
{% endhint %}

This is the clearest example of a principle that runs through the platform: the closer a mechanism gets to changing the agent's future behavior, the more a person has to be in the loop. See [Human-in-the-Loop](/core-concepts/human-in-the-loop.md).

## The improvement loop

Memory is where the operating loop closes.

1. [**Monitor**](/agent-builder/monitor.md) production behavior and score live conversations to find where the agent missed.
2. Record what the correct behavior should have been — a **learning case**.
3. **Review and approve** it. This is the gate.
4. Validate the improvement with [**Evals**](/agent-builder/test/evals.md) before rolling it out more broadly.

The agent improves from real outcomes, not just from isolated test runs — but only through a door a person opens.

## Context is not memory

A related idea, easy to confuse. **Memory** is what the agent carries across conversations. **Context** is what it holds within one — the conversation so far, retrieved documents, tool results.

Context is finite. Long conversations eventually exceed what the model can hold, which is what context compaction addresses. Retrieval — pulling only the relevant material into context rather than everything — is covered in [Knowledge & Context](/core-concepts/knowledge-and-context.md).

## Where this is configured

* [Agent Behavior](/agent-builder/build/agent-behavior.md#memory) — the Memory and FAQ memory toggles
* [Reinforcement Learnings](/agent-builder/monitor/reinforcement-learnings.md) — the learning-case approval flow
* [Monitoring](broken://pages/cD46XWa7ZwMLNvtnC3yG) and [Online-Eval](/agent-builder/monitor/online-eval.md) — where misses are found
* [Evals](/agent-builder/test/evals.md) — validating an improvement before it ships


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.uptiq.ai/core-concepts/memory-and-learning.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.