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

# Memory

> Durable facts, rules, and preferences Neo recalls at runtime — curated by your team and scoped MSP-wide or per company.

Memory is Neo's long-term knowledge about your MSP and your clients — the durable facts, rules, and preferences that don't belong in any single ticket. Neo recalls relevant memory every time it works, so it stays consistent instead of re-asking or guessing. It applies across all of Neo's actions, ensuring a consistent approach for each company.

<Note>
  **Automatic discovery is coming soon.** Today, every memory is one your team adds. Soon, Neo will also learn durable facts on its own — from your resolved tickets, your RMM inventory, and reviews of its own past runs — and propose them for your review. Automatic discovery is **not enabled yet**; for now, you curate memory yourself.
</Note>

## What Neo remembers

<Columns cols={3}>
  <Card title="Facts" icon="circle-info">
    Durable truths about a client — the apps they run, who their VIPs are, their environment's quirks.
  </Card>

  <Card title="Rules" icon="list-check">
    Handling that kicks in for a specific situation — who to escalate to, where to route certain tickets, a client's exception to your usual process.
  </Card>

  <Card title="Preferences" icon="sliders">
    Tone, terminology, and key contacts — how to communicate and who to notify for each client.
  </Card>
</Columns>

## Memory vs. custom instructions

Neo **retrieves** memory: at runtime it builds a query from the ticket and pulls in the memories that match. A memory only helps if something in the ticket — an app name, a symptom, the requester, the kind of request — would lead Neo to it. *"Acme runs SecureShield AV"* surfaces the moment a ticket mentions an antivirus alert. A rule with nothing to match against — *"always set the Site Code custom field"* — never surfaces, because no ticket says "Site Code."

That gives you two ways to make a memory land: key it to a cue a ticket will contain (leave it **unpinned**), or, if it has no cue but always applies, **pin** it so Neo never has to find it.

Standing, **org-wide** procedures that apply across every client — your documentation process, your onboarding steps, your change-approval policy — belong in the agent's [custom instructions](/core/writing-agent-instructions), not memory. Custom instructions are always in front of Neo, so it never has to retrieve them.

<Tip>
  Quick test: is it specific to **one client**? It's a memory — pin it if every ticket needs it, leave it unpinned if a ticket will cue it. Is it how this agent works for **all** clients? It's a custom instruction. For the full decision guide across instructions, skills, memory, and intents, see [Teaching Neo](/core/teaching-neo).
</Tip>

## Pinned vs. unpinned

* **Pinned** memories are **always** included — Neo never misses them. Pin what's relevant on every run for a client, e.g. *"Acme's VIPs are CEO Jane Doe and CFO Mark Lee — treat their tickets as top priority."*
* **Unpinned** memories are the default — Neo brings them up on its own when they're relevant to the task, so it stays informed without crowding every run, e.g. *"Peter Nguyen is the Service Desk Manager"* surfaces when a ticket needs escalation, but stays out of the way otherwise. Most memories should stay unpinned.

Pin a memory when every ticket for that client needs it but nothing in the ticket would cue Neo to look — a VIP list, branding and tone, a custom-field convention. Leave it unpinned when the ticket's own content will surface it — an escalation contact, an environment quirk, handling for a specific kind of request.

Because every pin is loaded into every run, pins are capped: up to **20 pinned memories per company** and **10 MSP-wide** (with a total-length limit per scope). If a pin is rejected, unpin something less essential — or leave the memory unpinned and let Neo recall it.

**Length:** an unpinned memory is kept short (up to 500 characters) so it stays a sharp, recall-friendly fact. A **pinned** memory can be longer — because it's injected verbatim rather than recalled, its limit is the scope's pinned-length budget — so a standing instruction has room for the detail it needs. You can edit any memory's text in the dashboard (**Save** replaces the old version); editing a pinned memory keeps it pinned.

## Scope

Choose who a memory applies to:

* **Company-specific** — applies only when Neo works for that end-client company.
* **MSP-wide** — applies across every client, e.g. your internal standards or tooling.

## Audience

Choose which agents can recall a memory:

* **Triggered / Scheduled agents** — the automation agents that work tickets and entities.
* **Chat agents — Internal** — your technicians' dashboard chat.
* **Chat agents — External** — end-user-facing chat.
* **All agents** — every surface (the default).

Classic [workflows](/core/workflows) benefit too: **pinned** memories are included when a workflow's Smart Actions run for a company. Recalling unpinned memories on demand is an agent capability.

## Add a memory

<Note>
  Only **admins** can add, edit, pin, or delete memories — including through a chat agent (an agent saves a memory only when the person chatting is an admin). Everyone's agents still recall them.
</Note>

<Steps>
  <Step title="Open Memory">
    Go to the **Memory** section in the dashboard.
  </Step>

  <Step title="Write the memory">
    Select **New memory** and enter the fact, rule, or preference in plain English.
  </Step>

  <Step title="Set scope and audience">
    Choose the companies it applies to (or **All companies** for MSP-wide), and which agents should recall it.
  </Step>

  <Step title="Pin if it's always relevant">
    Pin memories Neo should apply on every run; leave the rest unpinned.
  </Step>
</Steps>

## Examples

Each example notes its **scope**, **type**, and **pin** — and what makes Neo recall it. The first three are **unpinned**: a ticket's own content cues them. The last is **pinned**: it always applies but nothing in a ticket would trigger it.

### Environment quirk

**Scope:** Acme Corp · **Type:** Fact · **Pin:** Unpinned

```
Acme Corp runs SecureShield AV, not Microsoft Defender. Defender "threat detected" alerts on their machines are expected and can be ignored.
```

**Why it works:** a ticket about a Defender alert names the antivirus, so Neo recalls this and avoids the false alarm.

### Key contact

**Scope:** Acme Corp · **Type:** Fact · **Pin:** Unpinned

```
Peter Nguyen is the Service Desk Manager and the escalation contact for after-hours P1 incidents.
```

**Why it works:** when Neo decides a ticket needs escalating, it looks up who to escalate to — and finds Peter.

### Special handling for a request type

**Scope:** Acme Corp · **Type:** Rule · **Pin:** Unpinned

```
Acme keeps a pool of loaner laptops at their HQ. When a ticket reports broken or failed hardware, offer a loaner before ordering a replacement.
```

**Why it works:** a hardware-failure ticket cues Neo to recall the loaner option before it suggests buying new.

### Tailored ticket acknowledgments

**Scope:** Acme Corp · **Type:** Preference · **Pin:** Pinned

```
- Mention that their dedicated support team, "The Acme Support Squad", is on the case.
- If the ticket is P1, state that an update will be provided within 15 minutes.
```

**Why it's pinned:** nothing in a ticket would specifically trigger this, but it shapes every Acme reply — so it's pinned rather than left to recall.

<Tip>
  Keep each memory short and specific — one fact or one rule per memory recalls better than a long block of text. Start with your most important clients and the rules you repeat most often.
</Tip>
