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? Neo’s built-in Prompt Wizard drafts instructions for you from a short brief, following everything on this page. 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:
Already handled by NeoSo don’t write…
Searching documentation and past tickets”Search the knowledge base for the answer”
Adding notes and logging time”Remember to log your time”
Professional tone and plain language”Be professional and polite”
Keeping customer data safe”Don’t leak personal information”
Not promising specific timelines”Don’t over-promise on timing”
Choosing which tool to use for a task”Call the ticket-update tool, then the note tool”
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 Company 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. 
Create the new user in Microsoft 365, assign the standard license for
their department, and add them to the right distribution groups. If the
ticket doesn't say which department, ask before creating the account.
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.

​
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: 
Goal: resolve password-reset tickets for verified end users.

- Verify the requester's identity before any reset.
- Reset the password and require a change at next sign-in.
- If identity can't be verified, do not reset — add an internal note
  and escalate to the service desk.
- Record what was done on the ticket and let the requester know it's done.
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.

​
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”: 
Rate each alert and act on the rating:

- Red (active compromise — confirmed malware, live lateral movement,
  data exfiltration): escalate to an engineer immediately and notify
  the on-call channel.
- Amber (suspicious but unconfirmed — repeated failed logins from an
  unusual location, privilege-escalation attempts): assign to first
  line with a suggested customer update. Do not page anyone.
- Green (expected activity, vendor noise, informational): add an
  internal note explaining why it's benign, then close.

If the evidence is contradictory or the impact is high, don't guess —
mark for human review and escalate.
The agent can follow that the same way every time. “Be careful with security tickets” it cannot.

​
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.
  • 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.
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:
Don't:
- Say you've "asked the team" or "flagged it" — describe work as in
  progress, not as something you personally dispatched.
- Give specific dates, times, or ETAs. Point timing questions to the
  support line.
- Claim to have emailed, called, or done anything you didn't do.

Do:
- Acknowledge the request and give the next step in neutral terms.
- Be honest if you can't do something, and offer to log a ticket.
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.

​
Let Neo draft them for you

You don’t have to start from a blank box. In the agent editor, two built-in tools write to these best practices for you:
  • Prompt Wizard — answer three short prompts (Objective, plus optional Procedures and Preferences) and Neo drafts complete instructions and recommends the tools to enable. It deliberately keeps them concise and tool-agnostic, exactly as above.
  • Auto-Configure — already have instructions? It reviews and tightens them, suggests tools to match, and flags anything no tool can do.
Both are starting points — read what they produce, 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 Event History — 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

Company Memory

Per-client rules 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