Write clear instructions for your agent

Build the prompt around six decisions

A useful prompt is an operating brief for one assistant. It explains the task, the evidence it can use, the boundaries it must respect, the way it should respond, how to handle uncertainty and when to involve a person. Start with these decisions before adding detailed wording.

Keep the role narrow enough to test. “Help visitors choose Acme frames and understand our published policies” gives you concrete success criteria. “Be the best assistant and answer everything” does not tell the agent which facts or actions it is allowed to rely on.

Use short headings and direct instructions. Put related rules together and state an exception beside the rule it qualifies. Repeating the same instruction in slightly different words makes later maintenance harder and can introduce contradictions.

• Role and scope: who the assistant helps and which tasks it handles.
• Evidence: approved Knowledge and enabled tools, including what to do when evidence is missing.
• Boundaries: no invented dimensions, policies, completed actions or identity assumptions.
• Style: language, length, structure and the number of clarifying questions.
• Uncertainty: what to say and which next step to offer.
• Human support: the situations that require staff and the actual available handoff path.

A practical prompt template

Use this as an editable starting point, not a universal policy. Replace the example company, task and support route. Delete any capability your agent does not have. Check that every promised action corresponds to an enabled tool or a real staff process.

Do not add private credentials or a complete product catalog to the template. A prompt can describe how to use information, but it cannot make an unavailable source current or enable a disabled tool.

ROLE
You are Acme’s customer support assistant. Help visitors choose suitable products and understand approved support policies.

EVIDENCE
Use approved Knowledge and enabled tools for business facts. If a required fact is missing, explain the limitation instead of guessing.

BOUNDARIES
Do not invent measurements, prices, stock, delivery dates or policy exceptions. Do not claim a refund, booking or order change is complete unless a supported authorised process confirms it.

CONVERSATION
Reply in the visitor’s language when supported. Start with the useful answer. Ask one specific clarifying question when a missing detail changes the recommendation.

UNCERTAINTY
Separate known facts from assumptions. If the available information cannot answer the question, say what is missing and offer the configured support route.

HUMAN SUPPORT
Offer staff support when the visitor asks for a person or the request needs a human decision. Do not promise an immediate response outside actual team availability.

CONTACT DETAILS
Do not repeatedly request details already supplied. Request only information needed for the next useful step. A mentioned email or phone number does not prove identity.

Decide what belongs in Knowledge instead

Put policies, product specifications, price lists, opening information and long reference material in Knowledge. These facts can change independently of the assistant’s behavior. A current source can be updated, processed and inspected through citations without rewriting the whole prompt.

Put behavioral instructions in the prompt: “When a measurement is missing, say so and ask which product variant the visitor means.” Put the actual measurements and variant relationships in the source. This separation makes it easier to diagnose whether a bad answer came from missing facts or poor instructions.

If two sources disagree, resolve the conflicting material. A prompt saying “always be accurate” cannot decide which of two incompatible return policies your business actually intends. Source priority can help retrieval, but obsolete facts still need correction.

Teach the agent how to handle missing information

Tell the assistant what a useful incomplete answer looks like. It should explain the supported part, identify the missing detail and offer one appropriate next step. “I can confirm the outside size, but the source does not specify the glass size” is more useful than guessing a dimension or refusing the entire question.

Use a clarifying question when the visitor can supply information that changes the answer, such as the product variant, country or issue type. Do not ask a question merely to delay admitting that your own source lacks a fact.

Avoid blanket instructions such as “never say you do not know” or “always complete the customer’s request.” They encourage unsupported certainty. A successful support interaction can be an accurate limitation and a clear handoff.

Resolve conflicting instructions across the setup

Read the prompt together with public tone, enabled tools and published workflows. A concise default prompt and a matching workflow requesting a detailed step-by-step response can intentionally produce different styles. Two independent rules making opposing business promises are a problem to fix.

When behavior is surprising, inspect the workflow trace and source evidence before adding another absolute rule. Change the smallest cause: source for a wrong fact, tool permission for access, workflow for routing, prompt for general behavior.

Do not expect prompt wording to bypass permissions or create unsupported actions. “Use the customer’s email to open any order” is not a substitute for the supported identity and commerce checks.

Use examples that teach a reusable pattern

An example should illustrate the decision you want the agent to make. Pair a customer question with the qualities of a good response: cite the relevant policy, acknowledge the missing measurement or ask for the product variant. Keep example facts clearly illustrative and avoid copying outdated prices into instructions.

Include a boundary example as well as a happy path. If the assistant should help with ordinary returns but refer custom-made exceptions to staff, test both. A long set of almost identical successful examples provides less value than a few well-chosen contrasts.

• Known answer: explain the approved policy and its relevant exception.
• Unknown fact: name the missing information without inventing it.
• Ambiguous request: ask one question that changes the next step.
• Human request: offer the configured handoff rather than arguing.
• Account request: use the required identity process instead of treating volunteered details as proof.

Test the draft and publish deliberately

Use Test draft from the editor when you want to evaluate the current snapshot without replacing the live prompt. In Prompt tests, review the exact prompt under test, selected models, customer messages and expected behavior. Tests and AI-assisted drafts do not automatically become the production configuration.

Compare an exact known-answer question, a paraphrase, an ambiguous question, an unknown fact, a human request and an attempted policy exception. Inspect the actual answer, sources and any tool trace. The model’s own evaluation can help you investigate, but your approved facts remain the reference.

Apply only the changes you have reviewed, then use the agent’s Save changes control and wait for success. Reopen the setting to confirm it persisted, start a fresh test conversation and check the same scenarios again. Saving does not rewrite messages already sent.

Keep an instruction change log

Record the original failing question, expected behavior and the instruction you changed. Keep a small regression set of real, redacted customer questions. Add a test when a new failure mode appears rather than growing the prompt with every sentence from every conversation.

Review the instructions when a policy source, tool permission, model or workflow changes. Remove obsolete promises and duplicate rules. A shorter prompt with explicit evidence and boundaries is easier for your team to understand than a large document whose exceptions are scattered throughout.

Create a bot that knows its job and its limits.

A bot has an internal name, instructions, a model and optional tools. Start with a narrow role such as “returns support for NL web store” instead of a broad “company assistant”. Narrow scopes produce easier-to-test and more reliable answers.

Instruction pattern: “Answer only with the supplied knowledge. If the answer is missing, say so clearly and offer human support. Do not guess delivery dates, stock or refund outcomes.”

• Name the bot: Use a name your team recognises. The public display name is configured independently under Appearance.
• Write the operating instructions: Explain who the bot is, what it may do, how it should respond when knowledge is missing and when it should offer a person. Keep factual policies in Knowledge instead of repeating them in instructions.
• Select tools intentionally: Available options can include site lookup, commerce actions and staff handoff. Turn on only workflows you have tested; experimental controls can change visitor and Staff Console behaviour.
• Set handoff rules: Create conditions based on detected intent, sentiment, keywords, message length or office hours. Decide whether to show a staff CTA or open the contact form immediately, and choose normal, high or urgent priority.
• Activate when ready: An inactive bot remains unavailable to public and developer chat requests until you enable it.