Skip to main content
Memory and learning is what lets the Nash agent get smarter about you and your organization 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, 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 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

Your profile / working style

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.

Useful memory across conversations

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.

Context within a session

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.

Facts about entities

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.
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.
These memories are built automatically by the agent in the background. You don’t author profile fields, 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.

Memory and learning vs. Knowledge

This is the distinction people most often mix up, so it’s worth being precise.
KnowledgeMemory & learning
Who creates itYou — hand-authoredThe agent — machine-built
What it isSOPs, policies, definitions, reference linksAn inferred profile, remembered facts, session progress, entity context
Does it change on its own?No — fixed until you edit itYes — the agent updates it as it goes
Who turns it onAuthored by an admin; used everywhereOpt-in; enabled per type by an admin
Default stateEmpty until you write itOff 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 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 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 you’ve authored.

Admin controls, retention, and export

  • Admin-gated. Only an org admin can enable or disable each type (see 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, 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.
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.

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.
1

Open your organization's learning settings

Go to the memory and learning settings for your organization, where the four types are controlled.
2

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.
3

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.
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.

FAQ

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 you’ve authored — it doesn’t build or store any of these memories.
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 author profile fields, write memories, track session progress, or record entity facts — the agent does all of that.
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.
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.
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.

Knowledge

The reference material you author by hand — SOPs, policies, and links — for your whole org or a single agent.

Custom agents

Define a scoped, reusable agent with its own instructions, scope, and knowledge.

Usage

See your organization’s token consumption and cost over time.