Skip to main content
Custom instructions are the biggest lever you have on how well a Neo agent performs. They’re the free-text guidance you write in the agent editor, and Neo loads them as the agent’s highest-priority direction — they outrank Neo’s built-in skills and default behavior. Good instructions are the difference between an agent that works tickets like your best technician and one that guesses. This page applies to every agent driven by your instructions: ticket and scheduled agents and chat agents. They all share the same custom instructions field.
In a hurry? Click Adjust with Neo (inside the instructions box while it still holds the short starter line, next to the Custom Instructions title otherwise) and tell Neo what the agent should do. It drafts the instructions with you, following everything on this page, and on a new agent it works out the trigger, filter and tools too. See Let Neo draft them for you.

​
Start with what’s unique to you

The most common mistake is telling the agent things it already knows. Neo ships with built-in skills — diagnosis methodology, end-user communication, PSA and Microsoft 365 know-how — and sensible defaults. Your instructions sit on top of those and win wherever they conflict. So spend your words on what’s specific to your MSP: your processes, your decision rules, your guardrails, your tone. Don’t restate things Neo already does: Everything you don’t have to write is room for the guidance that actually matters.
Custom instructions are per-agent and apply to every company that agent serves. To add rules for one specific client — their escalation contact, their preferred tone, their custom-field conventions — use Memory instead. Both are “your instructions” and both override skills.

​
Say what to do and where the limits are — usually not how

This is the most important default to get right — it’s where most instructions go astray. Your agent already has its tools, and it picks the right one at runtime from each tool’s description. As a default — especially when you’re starting out — describe the outcome and the guardrails, and leave the mechanics to the agent. Reaching for specific tools, API endpoints, HTTP methods, PowerShell cmdlets, or raw system field names tends to make instructions more brittle, can box the agent in, and is easy to get subtly wrong. Saying what you want is usually shorter and survives product changes, PSA differences, and new tools.
You can name a system when it helps routing — “make the change in Microsoft 365”, “via the Exchange integration”, “in ConnectWise” — and refer to kinds of identifiers like email address, UPN, license type, or department group. This is a guideline, not a hard rule. If you know exactly what you want and why, getting specific is fair game — pin a particular endpoint, cmdlet, or field when you have a concrete reason the agent should take that path instead of choosing for itself. It’s a legitimate power-user move; just go in knowing the trade-off, and keep those specifics current as the underlying systems change. Start by describing outcomes, and reach for the details when they earn their place.
A good rule of thumb when you’re starting out: could a brand-new technician follow your instructions without you naming a single button or command? If yes, the agent can too. Once you know the systems well, it’s fine to get more prescriptive where it pays off.
Don’t ask an end-user chat agent to log the conversation onto the ticket. Once a chat is linked to a ticket, Neo records every message from both sides on it automatically — the user’s as customer replies, the agent’s as internal notes — turn by turn, with retries, and each message goes to the ticket it is actually about rather than whichever one the chat last touched. When that check can’t run — your PSA won’t return the ticket it compares against, or the check itself errors — the message is recorded on the ticket the chat was already on (see What the ticket records). An instruction like “log the full conversation” or “add all replies as a note” only confuses the agent — no tool posts a note whose text you dictate, so it either does nothing or files a ticket it shouldn’t. What is the agent’s decision — and worth an instruction — is when a ticket is needed, when to escalate, and when to mark it resolved.Watch for an instruction that answers both questions in one line, such as “wait until the conversation is finished, then add it all as a note”. The timing half is a real policy worth keeping; the logging half is the part to drop. Choose when the bot opens a ticket has the three shapes to paste in its place.

​
A structure that works

Most strong agents follow the same simple skeleton. You don’t need every section, but this order reads well to the model:
1

Goal — one line

Open with what this agent accomplishes. Many of the best instructions literally start with Goal:.
2

Role — who it is

Especially for chat agents: “You are a friendly first-line IT support assistant for end users.” This frames everything that follows.
3

Steps or decision rules

The ordered work, as bullets. Keep them short. For branching logic, state the condition, then the action.
4

Guardrails — what never to do

The hard limits. Be at least as explicit here as in the steps.
5

Escalation — when to hand off

The conditions that send a ticket to a human, and what to leave behind for them.
6

Output — what to leave behind

What the agent should record: an internal note, a status change, a customer message.
Here’s the whole skeleton in one short, tool-agnostic example:
That’s a complete, effective agent instruction. It names no tools, fits in a few lines, and still covers the goal, the happy path, the guardrail, the escalation, and the output.

​
Format your instructions

The instructions editor renders formatting as you type, like a document editor — headings look like headings, lists like lists — and structure helps the model follow long instructions. Use the toolbar (headings, bold, lists, quotes, links, code blocks, tables) or type Markdown directly: ## starts a heading, - starts a list, **bold** bolds, and ⌘B/Ctrl+B and ⌘I/Ctrl+I work as you’d expect.
  • Pasting from Word, Google Docs, a web page, or a Markdown file keeps your bold text, headings, lists, and tables — nothing is flattened to plain text.
  • To indent a list item, press Tab — Shift+Tab moves it back out. Typing - or 1. at the start of an item indents it too, so you can type a nested list straight through. The first item of a list has nothing to sit under, so it can’t be indented.
  • Use headings to separate sections (steps, guardrails, escalation) and lists for rules. Bold the words that carry the rule: “Never reset without verifying identity.”
  • A line of =, -, * or _ characters stays exactly as you type it — length and character included. Frame a section header with one if you want the agent’s output to carry it.
  • Prefer to write the Markdown yourself? Switch the box to Markdown with the control in its top-right corner and edit the raw text. It is the same text the agent reads, and it saves exactly as you type it — switch back to Editor to see it rendered.
  • The left margin numbers your instructions: the Markdown view numbers every line, and the Editor view marks the line a heading, paragraph, list item or table starts on. Every number is a line of the saved text, so “change line 14” means the same line in either view and in the Neo Support chat. A block the Editor view cannot match to the saved text — a paragraph written with _italic_, which the editor writes back as *italic*, for example — carries no mark from there down, and the Markdown view still numbers it.
  • Under the hood the instructions are stored as Markdown — the same text the agent reads — so anything you already saved keeps working unchanged.

​
Write decision rules, not vibes

“Handle urgent tickets quickly” tells the agent nothing it can act on. Give it the actual rule — a threshold, a list, a condition. Specific instructions produce consistent agents. A security-triage agent, for example, classifies every alert with explicit bands instead of “use your judgment”:
The agent can follow that the same way every time. “Be careful with security tickets” it cannot.

​
How the agent reads a rule

A ticket or scheduled agent reads each rule for what it is meant to achieve, so a rule that does not clearly fit a case is applied the way its author would want. Approvals, holds, what goes to a client, and security rules are followed exactly as written. When a case must always go one way, name it in the rule. A ticket agent also has defaults, and each one gives way to custom instructions that say otherwise. It writes an internal note on each substantive action. It closes a ticket when the end user says the issue is resolved or asks to close it, and sets any other status only when your instructions say so. It stands down when a technician already did the work, takes the ticket over or asks it to stop.

​
Guardrails and escalation

State the limits as clearly as the work — the best instructions often write the “never” list more emphatically than the “do” list. Cover:
  • Hard prohibitions — “Never make tenant-wide, network-wide, or security-impacting changes.” “Don’t provide account or password support for the client’s line-of-business app (e.g. their accounting or HR system) — only help with installation and updates.”
  • Security basics for anything customer-facing — never ask a user to type a password, MFA code, or PIN into the chat; reframe (“can you sign in?”, not “what’s your password?”). Don’t perform account or permission changes yourself — log a ticket and let a technician handle them through a secure channel.
  • When to escalate — the conditions that send a ticket to a human, named concretely: the issue persists after basic checks, it needs configuration access, or it involves safeguarding or sensitive data. Name the route too (a status, a Teams message to a named person). With no route, the agent leaves the open step in its internal note, or in its dashboard summary when it cannot or may not write a note, and messages no one.
  • What to leave for the human — an internal note with what was checked, what’s still needed, and the suspected cause, so the technician has full context.

​
Wording a hold-until rule

A common guardrail holds everything back until some condition is met — an approver has signed off, or the ticket has reached a given status. Word it by what it blocks, because that is what the agent can check. The agent sees each of its tools labelled writes to client systems — it can change a PSA record, an identity or RMM object, a mailbox, or send a message to a person — or read-only, which changes none of that, or reads or writes, depending on your request for the tools that do both, where the agent classifies each call instead of the tool. So a rule phrased in those terms needs no interpretation:
The second version reads as a stricter rule, but “system lookup” is a category the agent has to map onto its own tools, and a search of Neo’s synced ticket data is not obviously in or out. Name writes, or name the changes in your PSA’s terms (a status change, a client-facing note), and say which reads stay allowed. Avoid naming tools: tools are renamed and retired, and a rule that names one that is gone sends the agent looking for it.

​
Wording a start-of-work step

Many agents take ownership first: they assign the ticket to the agent’s own PSA resource and set a working status. A step you tie to the start of work runs once per ticket. A later run on the ticket takes only the part that no earlier run did and the ticket still needs, and never replaces an owner someone else set. The step runs before the agent replies to the customer, asks them a question, sets a waiting status or hands the ticket off. A reply that waits for the customer still counts as work on the ticket. A check you attach to the step is its condition: when the check passes, the agent takes the step, and when it fails, the agent skips it.
When the PSA API tool repeats a request it already made in the run, it sends that request to your PSA, so the repeat sees an owner a person or another system set after the first request. Its first request for a record can return a copy from Neo’s cache, and Get Ticket returns the ticket as the run first read it, so neither one is a live re-read. Name any other case where the agent should skip the step.
For risky writes — account changes, bulk operations, anything hard to undo — don’t rely on instructions alone. Require Technician-in-the-Loop so a human approves before the action runs. Instructions guide the agent; approvals are your safety net.

​
Tone and customer-facing language

For chat agents and any agent that messages end users, write for the reader — the end user, not your technicians — and control two things separately:
  • Voice — how it sounds: “Friendly, warm, plain language, no jargon. Brief over verbose.”
  • What it may and may not claim — the part teams forget. Tell the agent not to imply work it didn’t do, not to commit to specific dates or ETAs, and not to expose internal process:
Be honest about being an agent. Don’t volunteer it unprompted, but if a user asks directly whether they’re talking to a bot, answer truthfully — “I’m an automated support assistant; I handle first-line questions and pass anything hands-on to our techs.” Never claim to be human; never deny being automated.

​
Keep it concise

Aim for the shortest instructions that fully capture your intent. Prefer a tight set of bullets over a long numbered playbook, and cut anything that restates a Neo default or pads the page. Most agents need about a page — a few thousand characters is a good ceiling for everyday agents. Long, sophisticated agents do exist — a senior-technician agent handling a whole queue might run to several pages of decision tables. That’s fine when every line earns its place. Length should come from real complexity, not from boilerplate.

​
Advanced patterns

Once the basics are solid, these are the techniques Neo’s most advanced customers rely on. Reach for them when an agent’s logic is genuinely complex.
When an outcome depends on two or more variables — queue × priority, business hours × severity — a small table is clearer to the model (and to you) than nested prose. List the conditions and the action for each row.
LLMs can talk themselves into almost anything. If your agent keeps rationalizing the wrong call, legislate against it in plain language. Power users write lines like: “The bar is ‘can the agent finish this end-to-end with no human needed’ — not ‘does this seem reasonable.’ If a technician has to do anything later, escalate instead.” Naming the failure mode is often more effective than adding another rule.
When two rules could collide, say which wins — explicitly. “The quiet-hours rule suppresses customer messages, but it does NOT stop escalation: if the ticket needs a human, hand it off regardless.” One sentence here prevents a whole class of wrong decisions.
A short rationale helps the agent generalize to cases you didn’t list. “Escalating a ticket that turns out simple costs little; failing to escalate one that needed a human costs a lot — so when in doubt, escalate.”
An agent that can trigger on its own notes can loop. Sophisticated setups stamp each note with a marker and tell the agent to check for a recent one before acting again — “if you’ve already processed this ticket in the last few minutes and nothing new has happened, do nothing.” If you build multi-step or multi-agent automations, design for repeat runs.
Running several agents on the same accounts? Give them a shared persona name so every note, time entry, and customer message reads as one consistent technician rather than a committee.
Notification instructions can be conditional. Tell the agent when to stay silent and it sends nothing at all — no blank message, no empty email:“Post only for P1 and P2 tickets. If the priority is P3 or lower, do not post any message.”Write the silent case explicitly, as its own rule. “Only generate a message if…” works equally well.
A triaged field such as Status is decided on every ticket. A rule that only says when to set it, such as “set the status to Complete when …”, names no status for the other tickets, so on those Neo still decides the status itself, and can change it. Say what to do with the rest, as its own line:“When a ticket is a backup success alert, set the status to Complete. For every ticket that matches none of the rules above, keep the current status. Do not change it.”“Only follow these instructions for status” is not enough on its own: it limits which rules apply, and names no status for the other tickets.

​
Let Neo draft them for you

You don’t have to start from a blank box. In the agent editor, Adjust with Neo sits inside the instructions box while it still holds the short starter line (“Goal: Resolve the ticket” or “Help the user”), saved or not, and next to the Custom Instructions title otherwise. An end-user chat agent starts with a full policy in the box, so its button is next to the title from the start. One click opens the Neo Support chat, which reads what the agent already holds and opens on options you can click. What it offers depends on where you are:
  • A new agent you have not written anything into — a short intake opens first, in the dashboard rather than the chat, so there is nothing to wait for. It asks what kind of work the agent takes on, shows you the templates in that category in case one already does the job, takes one line about what you want, and asks what starts it. The trigger you pick is written into the builder straight away. Neo then opens with your answers already in hand and asks only what they leave open.
  • A new agent you have already started — Neo reads your draft, names the kind of agent you are building, and offers what to do next for that kind of work. If the draft already reads like working instructions, a review is one of the options.
  • A saved agent — Neo offers three options:
    • Add or change a rule: describe the change. Neo shows the edit, and applies it after you confirm. Before that, it checks the change against the agent’s instructions and the MSP-wide pinned memories that reach it, plus one company’s pinned memories when the change concerns that company, and tells you what it finds: a rule the change contradicts (quoting both), an exception added to an exception, a duplicate, a rule so absolute it blocks common tickets, or a rule that leaves a ticket where nobody sees it when a step fails. Where rules can merge, it proposes one rule instead. You choose which version to apply.
    • Check my instructions: Neo looks for contradictions, including with the MSP-wide pinned memories the agent reads, missing rules and unclear formatting, and changes nothing. If the instructions are fine, it says so, and offers to format them when the formatting could be clearer.
    • Turn on the tools it needs: Neo reads the instructions and proposes the tools and permissions they need, with the line that needs each one. Nothing is turned on until you confirm.
On a new agent, Neo proposes the whole thing: the instructions, a name, what it runs on, what starts it, a ticket filter where it knows your real values, the tools the work needs, and the Microsoft 365, Active Directory, Exchange or PSA permissions those tools need to reach anything. Neo ends with a button that sets up the builder you have open. It fills the form without saving it, so anything you configured yourself survives and the save stays yours. Review every part before you save, and fill in any tool setting Neo left for you. Read the permissions row with care: it says which areas the agent may read and which it may change, and which changes ask a technician to approve them first. Whether Neo can also create the agent outright depends on how far you have got in the builder:
  • Nothing set up beyond the instructions and the tools you picked — Neo can create the agent for you, disabled, so nothing runs until you review it and switch it on. If you accept, the agent exists: leave the builder without saving, or you will end up with a second copy.
  • You have already set a schedule, filters, integration permissions, or settings on a tool — Neo offers the button and nothing more. Those settings live only in the builder, and an agent created from the chat would not have them.
The button waits for a saved agent to have no unsaved edits, because Neo works from what is stored. Save, then click it. On the Neo Support Agent itself only Check my instructions is offered — Neo owns that agent, so its instructions can’t be changed from here.
Read what Neo produces, then edit. And browse the template gallery: every template ships with well-written instructions you can clone and adapt.

​
Test, then iterate

Instructions are never one-and-done. The fastest way to improve them is to watch real runs:
1

Start in test mode

Turn test mode on so the agent describes what it would do instead of doing it. Read those decisions against what you’d want.
2

Watch real executions

Review the agent’s runs in Executions — where did it hesitate, over-reach, or misread a ticket? Each miss points at a missing rule or an ambiguous line.
3

Refine one thing at a time

Add the rule that would have prevented the miss, then re-test. Small, specific edits beat rewrites. Neo can also learn from your feedback and suggest instruction refinements automatically.

Agents

What agents are and how they work end-to-end

Memory

Durable per-client and MSP-wide facts that layer on top of your agent instructions

Skills

The built-in expertise your instructions sit on top of

Technician-in-the-Loop

Require human approval before sensitive actions