Define an AI Assistant Role With Clear Boundaries
Specify the audience, permitted support tasks, exclusions, and stop conditions, then test both a valid request and a tempting out-of-scope one.
Write the role as a decision boundary
An assistant role is more useful when it tells the system whom it serves, what responsibility it has, and where that responsibility ends. “Help customers” is too broad to guide difficult conversations. “Help prospective customers understand published plan differences, and refer account-specific billing disputes to the support team” gives a clearer audience, task, and exclusion.
Start with the people who will use the channel. A new buyer, an existing subscriber, and an employee may use similar words while needing different information. Choose the audience for this assistant and identify the evidence it may rely on. If the source material is public pricing and product documentation, the role should not imply access to an individual’s account or authority to change a subscription.
Describe allowed tasks with verbs and objects: explain a published feature, point to a policy, ask a clarifying question, or stop when the requested fact is unavailable. Then list tempting but excluded tasks. These are not abstract edge cases. They are requests likely to appear next to an in-scope question, such as asking for a refund exception after discussing the return policy.
Turn scope into instructions and tests
Resonoon’s assistant setup includes role and purpose controls, with guidance for role, tasks, audience, and communication style. Use those controls to express the boundaries in plain language. Keep company facts in approved knowledge material rather than burying changing prices, addresses, or policy dates in behavioral guidance. This separation makes later maintenance easier: revise the source when a fact changes, and revise the instruction when the expected behavior changes.
Build two tests for every important boundary. First, ask a valid question that the source can answer. Second, ask a plausible out-of-scope question that invites the assistant to overreach. For a plan-selection assistant, the first might ask which of two published plans includes a named feature. The second might ask the assistant to promise a discount based on a customer’s personal circumstances. Decide in advance whether the correct result is a direct answer, a clarifying question, or a handoff.
The difference matters because a role is not merely a topic label. An assistant can discuss returns without deciding exceptions; it can explain appointment requirements without diagnosing a patient; it can describe a product without guaranteeing compatibility that has not been verified. Write the exclusion in the form of an action the assistant should not take, then specify a safe next step. “Do not decide refund exceptions; explain the published rule and direct the customer to the team that reviews them” is more operational than “be careful.”
Test the tempting request
Use the assistant test page with the valid and out-of-scope examples. Keep exact prompts and expected outcomes in a team-owned test record. Review whether the answer respects the role even when the request is emotional, urgent, or phrased as though approval has already been granted. A polite tone does not compensate for a false promise.
If the valid answer is missing a fact, inspect the approved source. If the assistant answers the excluded request as though it has authority, tighten the role boundary and test the same wording again. Change one cause at a time so the team can see what improved. Include a paraphrase of the tempting question; otherwise the assistant may pass only because it recognizes a memorized phrase.
Avoid making the role so narrow that it refuses ordinary questions. “Only answer exact phrases from the handbook” can create needless friction. Instead, define the subject and the evidence standard: answer when an approved source supports the response, ask for clarification when the request is underspecified, and stop when the answer depends on an unverified exception or account-specific decision.
Keep the boundary current
Roles age as products, policies, and support ownership change. Assign a business owner to review the role when a relevant policy changes, a new audience is added, or repeated conversations reveal a gap. Maintain this review register in the team's shared documentation and assign someone to keep it current. Keep a dated copy of the approved wording and the test examples so a later reviewer can distinguish intentional scope from accidental omissions.
Before making the assistant available in a customer channel, check that the sources, test cases, and human fallback agree with the written role. A boundary that says “refer billing disputes” is not operational if no team owns those referrals. The AI customer support use case gives broader context for a support assistant; the business remains responsible for assigning its scope and authority.