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

# Memory & learning

> Let Nash automatically remember how your team works and pick up useful context over time — an opt-in, org-controlled capability.

Memory and learning is what lets the Nash agent carry context about you and your organization forward over time — without anyone hand-writing a single note. When your organization turns it on, the agent quietly builds and maintains its own understanding of how your team works, the context of the conversation you're in, and the things it keeps working with. The next time you ask, it already has that background.

This is different from [Knowledge](/nash-agent/knowledge), which is the reference material *you* author and control. Knowledge is what you write; memory and learning is what the agent builds. They serve different purposes and live in different places.

Memory and learning is **off by default** and turned on by an org admin. Until someone enables it, the agent doesn't build any of these memories — it works only from your live Nash data, your conversation, and the knowledge you've authored.

## When to use this

Turn on memory and learning when you want the agent to carry context forward on its own, rather than starting fresh every time:

* **Your team has consistent working styles and preferences** that you'd rather not restate in every conversation.
* **You work the same kinds of problems repeatedly** and want the agent to recognize the patterns.
* **A single session involves a multi-step goal** and you want the agent to keep track of where it is.
* **You frequently revisit the same orders, drivers, or partners** and want the agent to remember what it has learned about them.

If you'd rather give the agent context you author and control by hand — SOPs, policies, definitions — use [Knowledge](/nash-agent/knowledge) instead. Many teams use both.

## How it works

When enabled, the agent builds these memories automatically in the background. There's nothing for you to write, curate, or maintain — that's the whole point. The agent decides what's worth remembering, stores it, and draws on it later, all on its own.

There are **four independent types** of memory and learning, and each one can be turned on or off separately for your organization. All four are off until an admin enables them.

### The four types

<CardGroup cols={2}>
  <Card title="Your profile / working style" icon="user">
    Builds a picture of who you are and how you prefer to work — your role and the delivery-management preferences the agent observes over time. This helps the agent tailor how it responds to you.
  </Card>

  <Card title="Useful memory across conversations" icon="brain">
    Lets the agent decide when something is worth remembering between conversations — important facts about your operation, the workflows you prefer, and the order patterns it sees. It skips small talk and greetings and holds onto what matters.
  </Card>

  <Card title="Context within a session" icon="list-check">
    Tracks the goals, plans, and progress inside a single conversation, so a multi-step task stays coherent from start to finish without you re-explaining where things stand.
  </Card>

  <Card title="Facts about entities" icon="boxes-stacked">
    Keeps track of facts, events, and relationships about the things the agent works with — orders, drivers, and partner organizations — so it builds up useful context about them across conversations.
  </Card>
</CardGroup>

Each type works on its own. You might enable just session context, or all four, or any combination — whatever fits how your team wants the agent to behave.

<Note>
  These memories are built automatically by the agent in the background. You don't write memories or record entity facts yourself — when a type is on, the agent populates and maintains it for you. This is what makes it "machine-built" rather than hand-authored. The one part you can author is your own profile — see [How Nash gets to know how you work](/nash-agent/how-nash-learns-about-your-team).
</Note>

## Memory and learning vs. Knowledge

This is the distinction people most often mix up, so it's worth being precise.

|                                | Knowledge                                                   | Memory & learning                                                       |
| ------------------------------ | ----------------------------------------------------------- | ----------------------------------------------------------------------- |
| **Who creates it**             | You — hand-authored                                         | The agent — machine-built                                               |
| **What it is**                 | SOPs, policies, definitions, reference links                | An inferred profile, remembered facts, session progress, entity context |
| **Does it change on its own?** | No — fixed until you edit it                                | Yes — the agent updates it as it goes                                   |
| **Who turns it on**            | Authored by admins (org-wide) or agent managers (per agent) | Opt-in; enabled per type by an admin                                    |
| **Default state**              | Empty until you write it                                    | Off until an admin enables it                                           |

In short: reach for **Knowledge** when you want to reliably give the agent context you control. Use **memory and learning** when you want the agent to build that context for itself over time. See [Knowledge](/nash-agent/knowledge) for the full picture on the hand-authored side.

## Privacy, scope, and controls

Because memory and learning observes how your team works, a few things are worth being clear about before you turn it on:

* **It's organization-wide, not per-user.** Enabling a type turns it on for everyone in your organization. There is no setting to enable a type for just one person — the toggle applies to the whole org.
* **Some types remember information about third parties.** The "facts about entities" type, in particular, builds up context about orders, drivers, and partner organizations. If your team has data-retention or privacy considerations, factor that in when deciding which types to enable.
* **It runs quietly in the background.** Building these memories uses a lightweight background process, so it stays inexpensive and out of your way during interactive work.

### Scope and isolation

Memories are **scoped to your organization** and never cross organization boundaries — Nash does not use one customer's memories to inform another's. Memory is read and written only within the [permissions](/nash-agent/guardrails) of the person the agent is acting for: the agent can't surface a memory to someone who wouldn't be allowed to see the underlying data.

### What is never remembered

* **Secrets and credentials** — API keys, passwords, and tokens are never stored as memories.
* **Payment details** — full card numbers and equivalent payment instruments.
* **Small talk** — greetings and chatter the agent judges not worth keeping (the "useful memory" type deliberately skips these).

When a type is turned off, the agent stops building that class of memory; with all types off, the agent works only from your live Nash data, the current conversation, and the [Knowledge](/nash-agent/knowledge) you've authored.

### Admin controls, retention, and export

* **Admin-gated.** Only an org admin can enable or disable each type (see [Turning it on](#turning-it-on)). Any member can view the current state.
* **Auditability.** An agent's use of memory is visible in its run history alongside the rest of its [actions and reasoning](/nash-agent/overview), so you can see what context informed a given response.
* **Retention, deletion, and export** of stored memories — along with **data-residency** commitments — follow your organization's Nash data processing agreement (DPA). To request deletion or export of memories, or to confirm residency for your region, contact your Nash representative or [support@usenash.com](mailto:support@usenash.com).

<Note>
  Turning a memory type off stops new memories of that type from being built. If you also need existing memories purged for a compliance request, raise it through the deletion path above rather than relying on the toggle alone.
</Note>

## Turning it on

Enabling or disabling memory and learning is an **org admin action** — it requires the permission tier that manages your organization's agent settings. Once set, it applies across your whole organization.

<Steps>
  <Step title="Open your organization's learning settings">
    Go to the memory and learning settings for your organization, where the four types are controlled.
  </Step>

  <Step title="Choose which types to enable">
    Turn on any combination of the four types — your profile / working style, useful memory across conversations, context within a session, and facts about entities. Each is an independent switch, and all start off.
  </Step>

  <Step title="Save">
    Once saved, the agent begins building the enabled memories on its next conversations. There's nothing further to author — it maintains them on its own from here.
  </Step>
</Steps>

<Warning>
  Changing these settings is an admin action that requires the permission tier managing agent settings. Any member of your org can check which types are currently enabled, but only an admin can change them. If you can see the settings but can't change them, ask an org owner or admin.
</Warning>

## FAQ

<AccordionGroup>
  <Accordion title="Is memory and learning on by default?">
    No. All four types are off until an admin turns them on. Until then, the agent works only from your live Nash data, the current conversation, and any [Knowledge](/nash-agent/knowledge) you've authored — it doesn't build or store any of these memories.
  </Accordion>

  <Accordion title="Do I have to write or maintain anything?">
    No. That's the difference from Knowledge. When a type is on, the agent builds and updates the memory itself in the background. You don't write memories, track session progress, or record entity facts — the agent does all of that. The one part you can author is your own profile — see [How Nash gets to know how you work](/nash-agent/how-nash-learns-about-your-team).
  </Accordion>

  <Accordion title="Can I enable a type for just myself?">
    No. The four types are controlled at the organization level. Enabling one turns it on for every user in your org; there's no per-user switch. This is worth keeping in mind as a privacy and consent consideration before you turn a type on.
  </Accordion>

  <Accordion title="How is this different from Knowledge?">
    Knowledge is reference material you write and control — it's fixed until you edit it and it's the same for everyone. Memory and learning is built by the agent automatically and evolves on its own. Use Knowledge when you want to hand the agent context you control; use memory and learning when you want the agent to build that context for itself. See [Knowledge](/nash-agent/knowledge).
  </Accordion>

  <Accordion title="Who can turn memory and learning on or off?">
    Enabling or disabling the four types requires the admin permission tier that manages your organization's agent settings. Reading the current state is open to any org member, but changing it is admin-only. Check with whoever administers your Nash account.
  </Accordion>
</AccordionGroup>

## Related

<CardGroup cols={2}>
  <Card title="Knowledge" icon="book" href="/nash-agent/knowledge">
    The reference material you author by hand — SOPs, policies, and links — for your whole org or a single agent.
  </Card>

  <Card title="Custom agents" icon="robot" href="/nash-agent/custom-agents">
    Define a scoped, reusable agent with its own instructions, scope, and knowledge.
  </Card>

  <Card title="Usage & cost" icon="chart-line" href="/nash-agent/usage">
    See your organization's token consumption and cost over time.
  </Card>
</CardGroup>
