Write instructions for your Assistant

How to write base instructions and workflow tasks that work

Write instructions for your Assistant

An Assistant does what you tell it to do, in the words you use. Clear instructions are the difference between an Assistant that posts a useful summary on every ticket and one that guesses, rambles, or asks the agent to do the work anyway.

This guide covers what to write in each field, with the patterns that work and the ones that don't.

---

What you write, and where

You configure an Assistant in the Tasks & Personality step. Three fields shape how it behaves.

Field	What it's for
Base Instructions	The Assistant's standing brief: who it works for, what it handles, what it must never do, and how to reply. It applies to everything the Assistant does.
Personality	The tone of its replies - Friendly, Professional, Concise or Empathetic.
Workflow tasks	Ordered steps for work that has to happen in sequence. Optional.

The Agent type you pick decides whether you write the base instructions yourself. Choose Custom to author your own. Purpose-built types, such as the Notion Assistant, come with instructions managed by Suptask and the field is read-only - you shape those Assistants through workflow tasks and connectors instead.

---

Write the base instructions

Cover four things, in this order. Four to eight lines is usually enough.

1. Role - who the Assistant works for and in which Inbox.

2. Scope - the requests it handles and the outcome it should reach.

3. Boundaries - what it must not do, and when to hand over to an agent.

4. Output - what its reply should contain, and what to leave out.

A worked example:

You are a co-pilot for the IT agents who resolve tickets in this Inbox.
Your job is to enrich each new ticket with the requester's account and
device details before an agent picks it up.
Only read information. Never create, change or delete anything.
Reply with one short summary using clear labels. Leave out empty fields,
aliases and internal IDs.
If you cannot identify the requester, say so in one line and stop.

Compare that with an instruction that gives the Assistant nothing to work with:

Help the agents with IT tickets and be useful.

The second version doesn't say which systems to look in, when to stop, or what a good reply looks like - so every ticket gets a different answer.

Always write a stopping rule. "If you cannot find X, say so and stop" prevents an Assistant from filling gaps with guesses.

---

Break the work into tasks

Use Workflow tasks when a request needs several steps in a fixed order, especially across systems. Each task is a numbered instruction the Assistant works through in turn.

Good tasks share three habits:

• One outcome per task. "Find the requester's email" and "look up their devices" are two tasks, not one.

• Name the data that carries over. Say what a task should extract, so the next task has something to use: "Extract the email address", "Extract the device serial numbers".

• Say what not to return. Assistants are thorough by default. "Do not output aliases" or "Do not return custom fields" keeps summaries readable.

An example of three tasks that pass data down the chain:

1. Get the requester's details with @Get User Info using @Requester ID.
   Extract their email address.

2. Use the email address to look up the user in Google Workspace Admin.
   Summarize their department, job title and group membership.
   Do not output aliases.

3. Search the "[Asset register]" page in Confluence for that email address
   and extract the serial numbers listed for the user. Look up each serial
   number in PDQ Connect and summarize the device name, OS version and
   last check-in.

If a step depends on something the previous step found, say so explicitly. Assistants follow instructions better than they infer intent.

---

Reference tools and ticket data

Type @ in a base instruction or workflow task to insert a token. The menu lists two kinds:

• Tools from the connectors you enabled on the previous step, such as @Get User Info or @List Groups.

• Ticket data available on the request, such as @Requester ID.

Tokens point the Assistant at an exact tool instead of leaving it to choose one, which makes multi-step workflows far more predictable. Insert them from the @ menu rather than typing the name - a token only works when it's inserted from the menu.

A tool has to be enabled on the Connectors step before it appears in the @ menu. If a tool is missing, go back and enable it.

---

Decide what it may change

Each tool on a connector runs in one of three modes. This is where you set how much the Assistant may do on its own.

Mode	Behaviour	Use it for
Off	The Assistant can't use the tool.	Anything it has no business touching, such as deleting users.
Ask	The Assistant proposes the action and waits for approval.	Changes to accounts, access, records or customer-facing data.
Auto	The Assistant runs the tool on its own.	Read-only lookups: searching knowledge, reading a user or a device.

A reliable default: every read tool on Auto, every write tool on Ask, and destructive tools Off. You can loosen this once you've seen the Assistant work on real tickets.

---

Choose when it runs

The Activation step decides which tickets an Assistant works on. You can set up more than one trigger.

• @suptask mention - an agent triggers the Assistant from the ticket thread. Add two or three example phrases so Suptask can tell which Assistant a mention is meant for, such as device questions, user lookups.

• Ticket created - the Assistant runs on every new ticket in the Inbox. Use Limit to forms to restrict it to the request types it was written for.

• Automatically answer tickets - replies go to the requester instead of the agent. Turn this on for deflection Assistants that answer from knowledge, and leave it off for anything that touches accounts or data.

By default, results are only visible to the agent. That makes automatic triggers safe to test: the Assistant does its work on the ticket, and only your team sees it.

---

Checklist

Before you deploy, read your instructions back and check that they answer:

• Who does this Assistant work for, and on which requests?

• Which system should it look in first?

• What should it never do?

• When should it hand over to an agent?

• What should the reply contain - and leave out?

The most common problems come from missing answers to these. An Assistant that answers questions outside its scope needs a tighter scope line. One that returns walls of text needs an output rule. One that invents details needs a stopping rule and knowledge grounding - see Auto-answer requests.

---

Related articles

AI Assistants