instruction field: up to 8,000 characters are saved, and the first 2,000 are used when answering) sets its audience, tone, technical depth and answer format. It cannot change what an answer is grounded in: the platform checks the evidence before the model is called and checks every answer against its citations afterwards, whatever the guidance says. So guidance does not need to warn the model against making things up, and can be spent entirely on how answers should read.
What good guidance covers
Good guidance usually covers four things:- Role & Audience: State who the assistant is speaking to (e.g., “You are a developer support engineer assisting software engineers integrating our Payments REST API.”).
- Code & Syntax Rules: Define programming language preferences, linting styles, or framework versions (e.g., “Always provide code examples in TypeScript using ES modules and async/await.”).
- Citation Presentation: Direct how citations should be discussed (e.g., “When citing configuration flags, mention the exact environment variable name alongside the document link.”).
- Response Length & Style: Specify conciseness preferences (e.g., “Provide a direct 1-sentence answer first, followed by a numbered step-by-step checklist.”).
Examples by use case
Developer API assistant
Developer API Persona
Customer support assistant
Customer Support Persona
What guidance cannot change
Guidance is placed below the platform’s own rules, and cannot weaken them:- It cannot override grounding. An instruction such as “Answer even if you have to guess” has no effect. When the evidence does not support an answer, the assistant abstains.
- It cannot make retrieved text authoritative. Passages from your content and the user’s question are always presented to the model as untrusted content, separate from instructions, whatever the guidance says.
- It cannot widen what is searched. Retrieval covers only the assistant’s own collections, inside your organisation, before the prompt is built.