> ## Documentation Index
> Fetch the complete documentation index at: https://docs.neoagent.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Teaching Neo: instructions, skills, memory & intents
> The four places to put knowledge when building agents — what each is for, how Neo uses it, and how to decide where a given fact, rule, or procedure belongs
When you build an agent, there are four places to put what it needs to know. They look similar — all of them end up as guidance in front of the agent — but each answers a different question, lives in a different place, and reaches the agent in a different way. Put knowledge in the right one and it shows up exactly when needed; put it in the wrong one and it either never surfaces or crowds every single run.
| | Answers the question | Example |
| ----------------------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| **[Custom instructions](/core/writing-agent-instructions)** | *How should **this agent** do its job?* | "Triage hardware tickets to the Field Services board. Never change priority on VIP boards." |
| **[Memory](/core/memory)** | *What's true about **this client** (or our MSP)?* | "Acme Corp runs SecureShield AV — Defender alerts on their machines are expected." |
| **[Skills](/agents/skills/overview)** | *How do we run **this repeatable job**?* | The exact steps and code behind the weekly open-ticket report. |
| **[Intents](/chat-agents/intents)** | *What must we collect for **this type of request**?* | New starter: full name, start date, who to copy access from, 2FA number. |
## Start here: adopt them in order
You don't set all four up on day one — trying to author every skill and intent before Neo does any useful work is the fastest way to make it feel daunting. They're a ladder, and most of the value is on the first two rungs:
1. **Custom instructions — always first.** Every agent needs them, and for many agents they're enough on their own. Give the agent its actual job, its boundaries, and its tone. This is where every customer starts, technical or not.
2. **Memory — add as the quirks surface.** One fact at a time, usually captured straight from a real run: this client runs SecureShield AV, that client's VIPs are these two people. Scope each to the [company](/core/memory) it's true for, or MSP-wide for something true everywhere. No technical setup — cheap to add and useful immediately.
3. **Skills and intents — the optimization layer, added only when a client needs them.** These are for advanced, repeatable work, and you reach for them when a concrete recurring need shows up — a report you run every week, an intake you keep getting half-answered — not before. The easiest way in is to [capture a good run](#improving-them-from-real-runs) rather than author from scratch.
A new or non-technical owner should get real value from **custom instructions and memory alone**, then grow into skills and intents later as they optimise. And custom instructions aren't a thin pointer like *"resolve tickets using relevant skills"* — they carry the agent's real behaviour; skills and intents refine it, they don't replace it.
## How each one reaches the agent
The mechanics matter, because they explain when each kind of knowledge actually shows up:
* **Custom instructions** are **always in front of the agent**, on every run — but only for the one agent you wrote them on. They're the right home for anything that must apply every time that agent works, and the wrong home for anything long (a procedure) or client-specific (a fact that's only true for Acme).
* **Memory** is **retrieved when relevant**. Neo keeps one memory library for your whole tenant; every agent draws on it. An unpinned memory surfaces when something in the ticket or conversation cues it; a [pinned](/core/memory#pinned-vs-unpinned) memory is always included for its company. Memories are scoped to one company or MSP-wide, and can target specific agent surfaces via [audience](/core/memory#audience).
* **Skills** are **loaded when the task matches**. Every agent sees a short menu of skill names; when a task matches one, the agent loads the full procedure (and can run the skill's tested code in its sandbox). Custom skills are tenant-wide — build one and every agent can use it.
* **Intents** are **loaded when a request matches**. An agent handling end-user requests sees the menu of intents in scope for that company; when someone asks for a "new starter", it loads that intent's questions and collects only what's missing. Intents apply to end-user chat and ticket-triggered agents.
All four scale the same way: the agent carries only a small menu, and pulls the full content on demand. That's why adding your 30th memory or 10th skill doesn't slow anything down or bloat other runs.
## Where does this belong?
Run whatever you're about to write through these questions, in order:
1. **Is it a fact, rule, or preference about one client — or a durable fact about your MSP?** → **Memory.** One fact per memory, scoped to the company it belongs to. Pin it only if every run for that client needs it and nothing in a ticket would cue it.
2. **Is it a multi-step procedure you want done identically every time** (a report, a reconciliation, a routine)? → **Skill.** Ask Neo Support to [build it](/agents/skills/creating-skills), ideally from a run that already did the job well.
3. **Is it a common request type where the real problem is incomplete intake** (new starter, hardware request, mailbox access)? → **Intent.** List the questions once; every in-scope agent runs the same intake.
4. **Is it how this one agent should behave, on every run, for every client** — its job, its boundaries, its tone? → **Custom instructions.** Keep them short; the more they carry, the less each line weighs.
Two rules of thumb that resolve most gray areas:
* **Specific to one client → memory. True for the whole agent → instructions.** Client-by-client exceptions written into instructions are the most common misplacement — they apply to the wrong clients and get duplicated across agents.
* **Long and procedural → skill. Short and standing → instructions.** A 30-line procedure pasted into instructions burdens every run, even the ones it's irrelevant to; as a skill it loads only when the job comes up.
When guidance conflicts, **your custom instructions win** over a built-in skill's defaults.
## What good ones look like
**Custom instructions** — the agent's job and boundaries, true for every client:
* *"You handle the Service Desk board. Only work tickets in New or Unassigned; never reassign a ticket a technician has already picked up."*
* *"If you can't resolve after two attempts, escalate to the ticket owner with a summary of what you tried."*
**Memory** — one fact each, scoped to the client it's true for:
* *"Acme Corp runs SecureShield AV — Defender 'threat detected' alerts on their machines are expected and can be ignored."* (unpinned: an antivirus ticket cues it)
* *"Contoso's file shares live on CNT-FS01; mapped drives are pushed by the 'Contoso Drive Maps' GPO."* (unpinned: a missing-drive ticket cues it)
* *"Acme's VIPs are CEO Jane Doe and CFO Mark Lee — treat their tickets as top priority."* (pinned: always matters, but no ticket says "VIP")
**Skills** — whole procedures with a start and an end, worth freezing:
* The weekly open-ticket summary, grouped by client and priority, same shape every Monday.
* The monthly Microsoft 365 license reconciliation against actual headcount.
* Your leaver/offboarding procedure — the exact steps, in the exact order.
**Intents** — request types where completeness of intake is the battle:
* **New Starter** — full name, start date, who to copy access from, whether they need RDS, 2FA mobile number.
* **Hardware Request** — device type, who it's for, needed-by date, whether budget approval is attached.
* **Mailbox Access** — which mailbox, who gets access, read-only or send-as, sign-off from the mailbox owner.
## Improving them from real runs
You rarely get all of this right up front — the fastest path is to react to actual runs from [Event History](/product/event-history):
* A run went **wrong**? Use [**Train Neo**](/product/train-neo): describe what should have happened, and Neo proposes an edit to the workflow's or agent's custom instructions for you to review and apply.
* A run went **right** and you want it repeated identically? Click **Skillify** on it to [capture it as a skill](/agents/skills/creating-skills).
* A run stumbled on a client quirk? Add what it was missing as a **memory**, and every future run for that client knows it.
## They compose: a new-starter example
The four aren't alternatives — a well-built setup uses them together. Take employee onboarding:
1. An office manager emails: *"We've got someone starting in the Bristol office."* The ticket triggers your service-request agent, whose **custom instructions** define its job and boundaries on that board.
2. The agent recognises your **"New Starter" intent** and replies asking only for what the email didn't answer — the start date and the 2FA number.
3. When the reply lands, it re-triggers the agent, which loads your **"user-onboarding" skill** and follows your exact provisioning procedure step by step.
4. Throughout, **memory** fills in what's true for this client — *"Bristol office users get the RDS access template"*, *"new-starter tickets go to Priority 2"* — without anyone restating it.
Intake is consistent because of the intent, execution is consistent because of the skill, client specifics are right because of memory, and the agent stays inside its lane because of its instructions.
## Manage them in the dashboard
Memory, intents, and skills are tenant-wide libraries under **Data** in the left navigation; custom instructions live on each agent.
How to write instructions that hold up — structure, specificity, and what to leave out
Facts, rules, and preferences — pinned vs. unpinned, scope, and audience
Capture a proven procedure so it runs the same way every time
Consistent intake for the requests you see over and over