> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tester.army/llms.txt
> Use this file to discover all available pages before exploring further.

# Project Memory

> Store durable knowledge about your app so the QA agent reads it on every run, managed from the dashboard, CLI, API, or MCP.

Project memory is a list of short facts about your app that the QA agent reads as context: where routes live, which accounts are seeded, known quirks, how a flaky flow should be handled. Write a fact once and every run of the project can use it, instead of repeating it in each test's steps.

## How the agent uses memories

Memories you add are included in the agent's context on every test run in the project. The planner behind the [PR exploration agent](/run/pr-exploration-agent) also reads them when it decides what to test on a pull request.

Memories are context, not commands. For standing rules about how the agent should behave or judge results, use [Agent Instructions](/run/agent-instructions).

<Note>
  Entries with a **learned** badge were recorded from earlier runs. Learned memories are not
  currently sent to the agent, and the agent does not add memories on its own. Only memories added
  from the dashboard, CLI, API, or MCP are used.
</Note>

## Categories and importance

| Category (form label) | Badge     | Use for                                                          |
| --------------------- | --------- | ---------------------------------------------------------------- |
| **Site Structure**    | `site`    | Routes, navigation, where features live                          |
| **Test Insights**     | `test`    | Timing, flaky flows, what to wait for before asserting           |
| **User Preferences**  | `general` | Accounts, conventions, and other general context about your team |

The API, CLI, and MCP use the raw values `site_structure`, `test_insights`, and `user_preferences`.

Each memory also has an importance of **High**, **Medium**, or **Low**, which decides what is removed first when the project is full.

## Manage memories in the dashboard

Open the project and go to the **Memory** tab. The **Memory usage** bar shows how many of the 100 slots are in use.

* **Add:** click **Add memory**, pick a **Category** and **Importance**, fill in **Title** (up to 200 characters) and **Content**, then click **Add Memory**.
* **Search:** filter by title or content with the **Search memory...** field.
* **Delete:** hover a memory and click the trash icon, or use **Clear all** to remove every memory in the project.

Memories cannot be edited. To change one, delete it and add a new version.

## Memory limit

A project holds up to 100 memories. When a new memory goes over the limit, the oldest **Low** memories are removed first, then the oldest **Medium** ones. **High** memories are never removed automatically. If the project is full and nothing of equal or lower importance can be removed, the API rejects the new memory with a `409` error.

## CLI

```bash theme={"theme":"vesper"}
ta memories list --project <projectId> --json

echo '{"category":"site_structure","title":"Auth route","content":"Login is at /login","importance":"high"}' \
  | ta memories create --project <projectId> --json

ta memories delete <memoryId> --project <projectId> --json
```

`create` reads a JSON object with `category`, `title`, `content`, and `importance` from stdin. See [CLI commands](/cli/commands) for authentication and global flags.

## API and MCP

| Action | API                                                       | MCP tool                |
| ------ | --------------------------------------------------------- | ----------------------- |
| List   | `GET /api/v1/projects/{projectId}/memories`               | `list_project_memories` |
| Create | `POST /api/v1/projects/{projectId}/memories`              | `create_project_memory` |
| Delete | `DELETE /api/v1/projects/{projectId}/memories/{memoryId}` | `delete_project_memory` |

```bash theme={"theme":"vesper"}
curl -X POST https://tester.army/api/v1/projects/$PROJECT_ID/memories \
  -H "Authorization: Bearer $TESTERARMY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"category":"test_insights","title":"Checkout flake","content":"Wait for the payment iframe before asserting success","importance":"medium"}'
```

The create response includes `pruned`, the number of memories removed to stay under the limit. The API, CLI, and MCP list and delete only memories that were added manually. Learned memories are managed from the dashboard. Set up MCP access in [MCP server](/cli/mcp).

## What makes a good memory

* One fact per memory, with a title that says what it is about.
* Concrete details: "The admin area is under `/admin`" beats "admin is somewhere in settings".
* Mark facts that every run depends on, such as the login route, as **High** so they are never pruned.
* Keep secrets out. Store passwords and tokens as [credentials](/auth/credentials) instead.