> For the complete documentation index, see [llms.txt](https://docs.nerovasystems.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nerovasystems.com/guides/operate-the-digital-employee/memory.md).

# Manage employee memory

Memory is the set of durable facts the employee uses when serving a tenant's customers: client preferences, routines, house rules, and corrections. This guide builds a memory surface in your platform where a merchant can review facts, add new ones, correct a wrong one, or delete one.

> **Experimental.** The `/api/v1/**` operations on this page are callable with your Live key (`nrv_live_`), which runs on the free testing allowance until a commercial agreement is signed or a card is saved. See [Lifecycle and availability](https://docs.nerovasystems.com/documentation/api/lifecycle).

## What you'll build

A memory editor: list what the employee knows, record facts on the merchant's behalf, and run the correction flow without ever editing a fact in place.

## Prerequisites

* An activated tenant and an API key with `memory:read` and `memory:write`; see [Authentication](https://docs.nerovasystems.com/documentation/getting-started/authentication).

## 1. List what the employee knows

```bash
curl --request GET \
  --url "https://api.nerovasystems.com/api/v1/tenants/{tenantId}/memory" \
  --header "Accept: application/json" \
  --header "Authorization: ******"
```

The response is not paginated: it returns all retained facts, each with a `group` (`Clients`, `Routines`, `Corrections`, or `HouseRules`), a `source` (`merchant_operator`, `host_platform`, or `customer_correction`), an optional `sourceReference` you supplied, and a `version` you must send with any mutation of that fact. Facts are retained until the merchant deletes them (`"retention": "merchant_managed_until_deleted"`).

## 2. Record a new fact

```bash
curl --request POST \
  --url "https://api.nerovasystems.com/api/v1/tenants/{tenantId}/memory" \
  --header "Accept: application/json" \
  --header "Authorization: ******" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: memory-crm-note-33017" \
  --data '{
    "group": "HouseRules",
    "text": "Never book grooming appointments after 16:00 on Saturdays.",
    "source": "merchant_operator",
    "sourceReference": "crm-note-33017",
    "actor": {
      "actorReference": "operator:jane.d",
      "delegationReference": null
    }
  }'
```

The `Corrections` group is reserved for the corrections flow: to amend an existing fact, use the corrections endpoint below instead of creating a fact in that group.

## 3. Correct a wrong fact

Corrections never overwrite: the correction is stored in the `Corrections` group and references the corrected fact, so the history stays auditable.

```bash
curl --request POST \
  --url "https://api.nerovasystems.com/api/v1/tenants/{tenantId}/memory/{memoryId}/corrections" \
  --header "Accept: application/json" \
  --header "Authorization: ******" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: correct-rcmem-stuv-01" \
  --data '{
    "text": "Saturday grooming cutoff is 15:00, not 16:00.",
    "source": "merchant_operator",
    "sourceReference": "crm-note-33089",
    "version": "v1:7b6c5d4e3f2a1b0c9d8e7f6a",
    "actor": { "actorReference": "operator:jane.d", "delegationReference": null }
  }'
```

## 4. Delete a fact

Deletion is permanent and, unusually for a `DELETE`, carries a JSON body with the fact's current `version` and the acting operator:

```bash
curl --request DELETE \
  --url "https://api.nerovasystems.com/api/v1/tenants/{tenantId}/memory/{memoryId}" \
  --header "Accept: application/json" \
  --header "Authorization: ******" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: delete-rcmem-stuv-01" \
  --data '{
    "version": "v1:7b6c5d4e3f2a1b0c9d8e7f6a",
    "actor": { "actorReference": "operator:jane.d", "delegationReference": null }
  }'
```

All three mutations require an `Idempotency-Key` and return the shared action response with `state` of `created`, `corrected`, or `deleted` and an `idempotencyStatus` of `applied` or `replayed`.

## One brain across both lines

A tenant's employee keeps a single memory. Facts recorded through this API, facts a merchant teaches on the management line, and things learned from real customer conversations on the booking line all land in the same store and inform both lines (the two roles are defined in [Two channel roles](https://docs.nerovasystems.com/documentation/concepts/channels#two-channel-roles)). There is no per-channel knowledge to keep in sync.

What never lands here is conversation content. Memory holds distilled facts; message contents stay inside the conversation surface, and the activity and work ledgers record [metadata only](https://docs.nerovasystems.com/documentation/concepts/channels#the-activity-ledger-is-metadata-only). The same rule covers line behavior settings (voice, media, availability): changes apply instantly and are logged metadata-only.

## Next steps

* Control how independently the employee acts on what it knows: [Set the autonomy mandate](/guides/operate-the-digital-employee/mandate.md).
* Full request and response shapes: [Memory reference](https://docs.nerovasystems.com/api-reference/memory).


---

# 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.nerovasystems.com/guides/operate-the-digital-employee/memory.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.