Teaching Neo: instructions, skills, memory & intents

An agent has four places for what it needs to know. Each answers a different question, lives in a different place and reaches the agent in a different way. Knowledge in the right place shows up on the runs that need it. Knowledge in the wrong place either never surfaces or rides every run.

​

Start here: adopt them in order

Nobody sets all four up on day one. Most of the value sits on the first two rungs.

1. Custom instructions, always first. Every agent needs them, and for many agents they are enough. Give the agent its job, its boundaries and its tone.
2. Memory, as the quirks surface. One fact at a time, usually captured from a real run: this client runs SecureShield AV, that client’s VIPs are these two people. Scope each to the company it is true for, or MSP-wide for something true everywhere. No technical setup.
3. Skills and intents, when a recurring need shows up. A report you run every week, an intake that keeps coming back half-answered. The easiest way in is to capture a good run.

​

How each one reaches the agent

• Custom instructions are in front of the agent on every run, for the one agent you wrote them on. They suit anything that must apply every time that agent works. They do not suit a long procedure or a fact true for one client.
• Memory is retrieved when relevant. Neo keeps one memory library for your tenant. An unpinned memory surfaces when something in the ticket or conversation cues it; a pinned memory is always included for its scope. A memory is scoped to one company or MSP-wide, and its audience and any agent filter decide which runs can recall it.
• Skills are loaded when the task matches. Every triggered, scheduled and internal chat 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. An end-user Chat Agent has no skill loader.
• Intents are loaded when a request matches. An agent that receives requests sees the intents in scope; when someone asks for a “new starter”, it loads that intent’s questions and collects only what is missing. Intents apply to end-user chat agents, internal chat agents and ticket-triggered agents.

​

Where does this belong?

Run whatever you are about to write through these questions, in order, and stop at the first yes.

1. Is it a password, token, key or other secret? None of the four. It belongs in your password manager or documentation platform. When an agent needs a stored password, it reads it from a documentation platform you have connected with that permission.
2. Is it a fact true for one client, or a durable fact about your MSP? A client fact names one company, person, site, device or product: a contact, an approver, a naming convention, the identity provider, the tools they run, an exception to your usual handling. An MSP fact is your support hours, your dispatch coordinator, the documentation tool you use. Either is a memory, scoped to that company or MSP-wide, when it is one fact or a short rule that Neo cannot already read from a ticket, your PSA or your documentation. A client-only procedure of roughly five or more steps goes to question 3. One fact per memory. Pin it only if every run needs it and nothing in a ticket would cue it.
3. Is it a procedure of roughly five or more ordered steps that applies to only some of the agent’s runs, or a scheduled agent’s whole job? A report, a reconciliation, a routine you follow only when a condition holds (“when a user is travelling abroad”). That is a skill. A scheduled agent keeps one line in its instructions that names the job and the skill to load. Ask Neo Support to build it, ideally from a run that already did the job well.
4. Is it “for requests of type X, ask for A, B and C”, a form, or “don’t ask about D on X requests”? That is an intent, on an agent that receives requests. List the questions once; every in-scope agent runs the same intake.
5. Otherwise it is how this one agent behaves, on every run, for every client. Its job, the order of work, what it may and must not do, when it hands back, its tone, its status conventions. That is a custom instruction. Keep them short; the more they carry, the less each line weighs.

One exception: an end-user Chat Agent cannot load a skill or recall an unpinned memory. For that agent, a procedure stays in its custom instructions, and a client fact becomes a pinned memory with the external-chat audience. Two rules settle most gray areas.

• One client: memory. Your MSP itself: MSP-wide memory. Every client: instructions. Client-by-client exceptions written into instructions are the most common misplacement; they apply to the wrong clients and get duplicated across agents. An MSP-wide memory (“our dispatch coordinator is Sam Lee”) is available across all your client companies, to the agents its audience and any agent filter allow. A rule about what the agent does, true for every client, stays in the instructions even when it names a product (“for RMM alerts that auto-resolved, add an internal note”).
• How to do it: skill. What to collect first: intent. What is true: memory. A memory can become false. A skill’s saved procedure stays fixed until you edit it. An intent ends at one outcome.

When guidance conflicts, your custom instructions win over a built-in skill’s defaults.

​

What does not belong where

Not a memory

• A secret. It belongs in your password manager or documentation platform.
• A rule for the agent’s own behaviour (“never reboot without approval”). That is a custom instruction.
• A procedure of roughly five or more steps. That is a skill.
• A copy of an agent’s instruction block, or a line addressed to one agent by name. That is that agent’s instructions.
• A fact Neo can already read from a ticket, your PSA or your documentation, such as a contact’s email on the PSA contact record.

Not a skill

• The agent’s own main loop. An L1 agent’s “check history, gather details, diagnose, fix, verify, document” is its instructions, however long.
• A one-off job.
• A single fact or preference.
• A how-to a built-in skill already teaches, such as your PSA’s API.
• A copy of another agent’s instructions, or a cheat sheet that repeats an existing skill.

Not an intent

• A body that is the agent’s whole job (“act as a friendly triage agent that understands the issue and hands off”).
• A catch-all for requests that fit nothing. That is the agent’s default behaviour.
• Two intents that differ only by a value. “Hardware: laptop”, “Hardware: desktop” and “Hardware: tablet” are one Hardware intent with a device-type field.
• A procedure hidden in the intake. The intent keeps the questions; the steps go to a skill.
• A policy that applies whatever the requester asked (“never reply to a personal Gmail address”). That is an instruction, or a memory when it is one client’s rule.
• An intent on a scheduled agent. A scheduled run has no requester.

​

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 is 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: it always matters, and no ticket says “VIP”)

Skills: whole procedures with a start and an end.

• The weekly open-ticket summary, grouped by client and priority, the same shape every Monday.
• The monthly Microsoft 365 licence reconciliation against actual headcount.
• Your leaver procedure: the exact steps, in the exact order.

Intents: request types where complete intake is the hard part.

• New Starter: full name, start date, who to copy access from, whether they need RDS, 2FA mobile number.
• Hardware Request: device type, who it is 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

The fastest path is to react to real runs from Executions.

• A run went wrong: use Train Neo. The run opens in a Neo Support conversation; describe what should have happened, or just send, and Neo investigates the run and its approval decisions and proposes the one change that fixes it — usually an edit to the agent’s custom instructions, sometimes a tool, an integration permission or a memory it was missing — applied once you confirm.
• A run went right and you want it repeated identically: click Skillify on it to capture it as a skill.
• A run stumbled on a client quirk: add what it was missing as a memory, and every future run for that client knows it.
• Starting a new agent: apply a template, or ask Neo Support to set it up with you. It asks the few questions the template cannot answer about your workspace, then creates the workflow or agent disabled for your review.

​

They compose: a new-starter example

A well-built setup uses the four 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 did not 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 is true for this client: “Bristol office users get the RDS access template”, “new-starter tickets go to Priority 2”.

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.