Skip to main content
Knowledge is the reference material you hand the agent so it answers in your context instead of in generic terms. Think standard operating procedures, business background, escalation policies, or a list of reference links the agent can pull up when it’s relevant. Knowledge is reference, not orders. The agent treats it as authoritative background it can draw on — not a script it must follow word for word. For behavior you want the agent to actually do (its job, its tone, the steps it follows), use the agent’s instructions instead.

​
When to use this

Add knowledge whenever the agent needs context it can’t get from your live Nash data:
  • Your SOPs and playbooks — how your team handles a late delivery, when to escalate, who to notify.
  • Business context — what your service tiers mean, which contracts are priority, what “on time” means for you.
  • Policy and reference text — refund rules, communication guidelines, brand language.
  • Reference links — URLs to internal runbooks or public pages the agent can fetch when a question calls for them.
You do not need knowledge for facts the agent can already look up. It already sees your orders, jobs, deliveries, provider performance, and analytics directly. Knowledge fills the gaps that live in your team’s heads or in your documents.

​
How it works

There are two scopes of knowledge, and they stack.

​
Global knowledge (org-wide)

Global knowledge is your “about this organization” reference material. You set it once for your org, and it applies everywhere — the main Nash agent in chat picks it up, and every custom agent in your org inherits it by default. Use global knowledge for context that is true across all of your operations: company background, org-wide policies, escalation chains, and shared definitions.

​
Custom knowledge (per agent)

Custom knowledge is “about this agent” reference material attached to a single custom agent. Use it for context that only matters to that one agent’s job — for example, a refund-handling agent gets your refund policy, while a provider-performance agent gets your scorecard definitions. By default, a custom agent uses both its own knowledge and your global knowledge. You can turn off that inheritance on a per-agent basis so the agent uses only its own reference material — useful when an agent’s context would clash with the org-wide defaults.

​
How the two combine

When a custom agent runs, Nash merges the two scopes into one reference section: your global knowledge first, then the agent’s own knowledge. The agent reads the whole thing as background. If you’ve turned off inheritance for that agent, only its own knowledge is used. Each scope has two parts:
PartWhat it isHow the agent uses it
Reference textA free-text block of notes, policies, and contextRead as background on every turn
Reference URLsA list of web linksFetched on demand, only when a question makes a link relevant
Reference URLs are not crawled up front. The agent fetches a link only when the conversation calls for it, so a long link list doesn’t slow down every run. Links must be standard web addresses (http or https), and you can add up to 50 per scope.
Keep reference text focused. Everything in a knowledge block is read by the agent on every turn, so a tight, well-organized page of context works better than a sprawling document. Move anything long-form to a reference URL and let the agent fetch it when needed.

​
Knowledge vs. memory and learning

This is the part people most often mix up, so it’s worth being precise. Knowledge is what you write. It’s static reference material you author and maintain by hand — your SOPs, policies, and links. It doesn’t change unless you change it, and it’s the same for everyone in your org (or everyone using that agent). Memory and learning is what the agent builds. When your org turns it on, the agent can automatically remember things across conversations — like a user’s preferences, useful context from earlier in a session, or facts it has picked up about the entities it works with. That happens behind the scenes; you don’t write those notes, the agent does. In short: knowledge is hand-authored and fixed; learning is machine-built and evolving. They’re configured in different places and serve different purposes. Use knowledge when you want to reliably give the agent context you control. Memory and learning is a separate, opt-in capability your org admin manages.

​
Set it up

​
Set global (org-wide) knowledge

1

Open your organization's agent settings

Go to the Nash Agent settings for your organization, where the org-wide reference material lives.
2

Add your reference text and links

Paste in your “about this org” context as reference text, and add any reference URLs you want the agent to be able to pull up.
3

Save

Once saved, global knowledge applies immediately — to the main Nash agent in chat and to every custom agent that inherits org knowledge.
Setting org-wide knowledge is an admin action. Reading it is open to any member of your org, but editing it requires admin-level permission (the same tier that manages agent settings). If you can’t edit it, ask an org owner or admin.

​
Set custom (per-agent) knowledge

1

Open the custom agent in the agent builder

Create a new custom agent or edit an existing one.
2

Add the agent's own knowledge

Add reference text and reference URLs specific to that agent’s job.
3

Choose whether to inherit org knowledge

Leave inheritance on (the default) to combine org-wide knowledge with the agent’s own, or turn it off to use only the agent’s knowledge.
4

Save the agent

The agent uses its knowledge on its next run, whether that’s an interactive chat or a scheduled run.
Managing custom agents — including their knowledge — requires the permission tier that lets you create and edit agents and their scheduled runs. Members who can only view agents can’t change their knowledge.

​
FAQ

No. Knowledge is authoritative background, not a command list. The agent draws on it to answer in your context, but it’s deliberately told to treat it as reference rather than a literal script. If you want the agent to take specific steps or behave a certain way, put that in the agent’s instructions, not its knowledge.
By default it adds to it — the agent sees org-wide knowledge plus the agent’s own. If you want a single agent to ignore the org-wide material, turn off knowledge inheritance for that agent, and it will use only its own reference text and links.
Only when a question makes a link relevant. The agent fetches a URL on demand rather than reading every link on every run, so you can list reference pages without slowing things down.
Knowledge is reference material you write and control. The agent “remembering” things across conversations is a separate memory-and-learning capability your org can opt into — there, the agent builds the notes automatically. Knowledge is fixed until you edit it; memory evolves on its own.

Custom agents

Define a scoped, reusable agent and attach its own knowledge, scope, and tools.

Scheduling and runs

Run a custom agent on a schedule or in response to events.