A prompt for a customer service AI agent is not a paragraph of good intentions. It is an eight-block document (identity and scope, AI disclosure, sources of truth, hard rules, procedures, escalation, output format, personal data) that deliberately leaves out anything with an expiration date. Prices, hours, stock, and turnaround times belong in the knowledge base or in a live integration, never in the text of the prompt, because the prompt gets deployed and retested in full while the knowledge base gets corrected in a minute without touching how the agent behaves.
The other half of the job is the rules. Sort them into two piles: soft rules, which are about tone and style, and hard rules, which someone can verify by reading a transcript with no knowledge of your business. "Be friendly" is not auditable. "Do not state a price that is not in the knowledge base" is, and that distinction stops being academic the moment an agent promises something the company has no intention of honoring.
What follows is the entire prompt, published on this page, plus the parts that usually get skipped: how to test a change without breaking what already worked, what opening line satisfies the disclosure obligation that became enforceable on August 2, 2026, and the cases where the problem is not in the prompt no matter how many times you rewrite it.
What belongs in the prompt and what belongs in the knowledge base
The rule fits on one line: if a fact can change without the agent's behavior changing, it does not go in the prompt. The prompt describes how the agent behaves. The knowledge base holds what is true today.
There are three reasons, and none of them are cosmetic. The first is operational: whoever updates a price should not have to open the document that governs the agent, or rerun twenty-four control conversations because one number moved. The second is attention: the longer the prompt, the more the instructions that matter get diluted among paragraphs of catalog copy. The third is accountability: a fact in the knowledge base can be quoted verbatim and traced to its source, while a fact buried in the prompt becomes something the model half remembers.
There is a third home most people forget: the live integration. Stock levels, order status, open slots on a calendar, an account balance. Those are not knowledge, they are state. With no real-time lookup, the correct answer is not a helpful estimate. It is to say the agent will confirm, and escalate.
| Item | Where it goes | Why |
|---|---|---|
| Prices, rates, and discounts | Knowledge base | They change without notice and you need to fix them without deploying anything |
| Hours, holidays, and addresses | Knowledge base | They expire weekly; inside the prompt they turn the agent into a source of errors |
| Stock, lead times, and order status | Live integration | Neither prompt nor knowledge base: with no real-time lookup, the agent must not assert it |
| Return policy and legal text | Knowledge base, with the exact wording | The agent has to reproduce the current text, not a paraphrase from six months ago |
| Tone, register, and answer length | Prompt | That is behavior, not data; it does not expire when the catalog changes |
| What to do when it does not know | Prompt | It is a decision rule and it gets versioned with the rest of the behavior |
| Trigger for handing off to a person | Prompt | It defines when the agent stops talking; the detail lives on the page about escalating from chatbot to human |
A classic symptom of having mixed the two: the agent quotes an old price and the answer sounds perfect. The tone is right because the prompt is right. The fact is wrong because the fact was inside the prompt.
The eight blocks of a prompt that handles customers
Order matters more than it looks. Identity and hard rules go on top: in long documents, whatever sits in the middle is what holds up worst once a conversation runs long. Output format and personal data go last because they are closers, not frames.
Here are the eight blocks, and what each one has to settle.
- Identity and scopeWho it is, what company it speaks for, the three or four things it resolves, and what it does not resolve. The list of what it does not do matters as much as the list of what it does.
- Opening and disclosureThe literal sentence it introduces itself with, and what it answers if someone asks whether it is a person. Written out word for word, in quotes, not described.
- Sources of truthWhere the facts come from, what it does when they are missing, and what it does when the lookup fails. Without this block, the model fills the gap with whatever seems reasonable.
- Hard rulesThe closed list of what it can never assert. Written in the negative, each with a binary test: either it held or it did not.
- ProceduresThe three to five flows it handles end to end, in numbered steps. Go past five and the agent starts blending them.
- Escalation triggerThe exact conditions that hand the conversation to a person, and the literal message it signs off with. Not a vague "if things get complicated."
- Output formatLanguage, register, maximum lines per message, one question per message, and which characters to avoid. On WhatsApp, asterisks and numbered lists read badly.
- Personal dataWhat it asks for, what it never asks for, and what it does when a customer volunteers something they should not have sent.
Eight blocks are not eight loose paragraphs. Each one answers a question the model is going to face at some point in the conversation, and if the answer is not written down, it improvises one.
The twelve hard rules: what the agent can never assert
A hard rule has a specific property: someone who knows nothing about your business can read twenty transcripts and say, without argument, which ones broke it. Everything else (warmth, empathy, friendliness) is tone, and tone gets fixed by rereading transcripts, not by stacking adjectives into the prompt.
These twelve cover about ninety percent of the scares in customer service.
- Do not state a price that is not in the sourceNo rounding, no estimating, no "it usually runs around."
- Do not confirm availability or stock without a live lookupIf the integration does not answer, say it cannot be checked right now.
- Do not promise delivery, refund, or resolution timelinesThe company promises timelines. The agent does not.
- Do not invent exceptions to a policyNo "just this once," no "I'm sure they'll approve it."
- Do not say someone will call within X timeUnless a tool has actually booked the call and the agent has the time.
- Do not ask for payment details or passwords on the channelNo card number, no CVV, no verification codes, under any pretext.
- Do not restate personal data that is not neededIf the customer sends it, it does not get echoed back in the reply.
- Do not give medical, legal, or financial adviceTake the details and escalate, even when the question looks simple.
- Do not discuss competitorsNot favorably, not unfavorably. It answers for its own service.
- Do not deny being an AIIf asked, say so. And do not give the agent a human first name.
- Do not close without a path when it does not knowEither escalate, or take a contact and a response time. Never a bare apology.
- Do not answer outside the declared scopeOff-topic gets one sentence and a redirect. It has no opinions on anything else.
Hard rules are written in the negative on purpose. A model can read "give accurate information" a thousand different ways. "Do not state a price that is not in the knowledge base" has exactly one reading, and it fails visibly.
What happens when an agent promises something that does not exist: the Air Canada case
On February 14, 2024, the Civil Resolution Tribunal of British Columbia, a Canadian small claims tribunal, ordered Air Canada to pay Jake Moffatt C$812.02 over wrong information the chatbot on its website had given: C$650.88 in damages, C$36.14 in pre-judgment interest, and C$125 in tribunal fees. The file number is SC-2023-005609 and the citation is 2024 BCCRT 149.
Place it before drawing conclusions. It is a small claims decision from a Canadian provincial tribunal applying the tort of negligent misrepresentation. It is not binding on any United States court, it is not precedent, and it obligates nobody here. It is an illustrative case, and what it illustrates travels well.
Air Canada's position, as the tribunal summarized it, was in effect that the chatbot was a separate legal entity responsible for its own actions. The tribunal called that a remarkable submission and rejected it, finding that Air Canada had not taken reasonable care to ensure its chatbot was accurate. Then it added the detail that should worry anyone building agents: the chatbot linked to the right page, with the correct information on it, and the company was still on the hook, because the tribunal would not accept that a customer has to double-check one part of a website against another.
In the same territory, Spain's data protection authority publishes a consumer-facing infographic on chatbots warning that there is no guarantee the information a chatbot gives is correct and that, depending on the system, it can cause emotional harm, spread misinformation, or mislead. It is written for the public and imposes no obligations on companies, but read backward it is a reasonable list of what any company should be offering: name the party responsible, explain how data is handled, and say whether the system keeps learning from conversations.
Translated into prompt terms: the first three hard rules on the list above are not a matter of style. They are the difference between an agent that says "I do not have that confirmed, let me check" and one that invents a commercial condition somebody is going to have to pay for.
It should be obvious to Air Canada that it is responsible for all the information on its website. It makes no difference whether the information comes from a static page or a chatbot.
The opening line that satisfies the transparency obligation
As of August 2, 2026, Article 50 of Regulation (EU) 2024/1689 is enforceable. Nothing entered into force that day (the regulation has been in force since 2024); what changed is that this article became applicable. Paragraph 1 requires providers to design systems intended to interact directly with people so that those people are informed they are interacting with an AI system, unless it is obvious from the point of view of a reasonably well-informed, observant, and circumspect person, given the circumstances and context of use. The European Commission, in its FAQ on Article 50, holds that the exception must be read narrowly and against the standard of an average reasonably well-informed, observant, and circumspect person.
For a company in the United States this is not background reading if any of your customers are in the EU. The obligation attaches where the regulation reaches you or your end users, not because of where your servers sit. Whether your own state has a bot-disclosure rule on top of that is a question for your counsel, not for a blog post.
One nuance that is being reported badly this week: no, it has not all been postponed. Regulation (EU) 2026/1744, the digital omnibus on AI, published in the Official Journal on July 24, 2026, did delay the bulk of the high-risk obligations and did grant an extension to December 2, 2026, but only for the machine-readable technical marking in paragraph 2, and only for systems already on the market before August 2. The obligation to say you are talking to an AI got no extension.
Article 50 does not say how to word the sentence, beyond requiring that the information be given clearly and distinguishably no later than the first interaction. So the wording is a product decision, and it goes in verbatim as block 2 of the prompt. Three versions that work on different channels:
WhatsApp or Instagram: "Hi, this is the virtual assistant for [BRAND]. You are talking to an AI. If you would rather talk to a person, type HUMAN and I will pass you to the team."
Web: "Automated chat for [BRAND]. An AI answers here. To reach the team, type HUMAN or call [PHONE]."
Voice: "You have reached the automated assistant for [BRAND]. This call is handled by an AI. Say 'agent' at any time to reach the team."
What breaks the sentence: giving the agent a human first name, signing off with a headshot of a person who does not exist, or leaving the notice in the website footer and hoping it counts as the first interaction. And one decision this article cannot make for anyone: in a white-label setup, who is the provider and who is the deployer is a legal characterization that none of the sources consulted resolve, and it decides which paragraph of Article 50 lands on whom. That question is for a lawyer. On how to word the notice and where to place it on each channel, there is a page about disclosing that a chatbot is an AI.
The complete prompt, ready to copy
Here it is in full, with the eight blocks and the twelve hard rules inside. The brackets are the only thing you replace. No form, no download: it is selectable text.
1. IDENTITY AND SCOPE You are the assistant for [BRAND], [one sentence on what the company does]. You handle [CHANNEL] for customers and prospects. You resolve: [topic 1], [topic 2], [topic 3]. You do not resolve: [short list]. If someone asks about anything on that list, say so in one sentence and offer to pass them to the team.
2. OPENING AND DISCLOSURE On the first message of every new conversation, introduce yourself with these exact words: "Hi, this is the virtual assistant for [BRAND]. You are talking to an AI. If you would rather talk to a person, type HUMAN and I will pass you to the team." If the customer asks whether you are a person, say no, that you are the automated assistant for [BRAND]. Never say or imply that you are human. Do not use a human first name.
3. SOURCES OF TRUTH
Prices, hours, terms, timelines, and availability live in the knowledge base and in the connected tools. They are the only valid source.
If a fact is not there, do not infer it, estimate it, or round it: say you will confirm, and escalate.
If a lookup against the knowledge base or a tool fails, say so plainly ("I cannot check that right now") and escalate.
When you give a price, a timeline, or a condition, reproduce it exactly as it appears in the source. Never restate the figures in your own words.4. HARD RULES (no exceptions) Do not state a price that is not in the source. Do not confirm availability or stock without a live lookup. Do not promise delivery, refund, or resolution timelines. Do not invent exceptions to any policy. Do not say someone will call unless the call is booked and you have the time. Do not ask for card numbers, CVV, passwords, or verification codes. Do not restate personal data you do not need for the step in progress. Do not give medical, legal, or financial advice. Do not discuss or compare other companies. Do not deny that you are an AI. Do not close a conversation without a path: escalate, or take a contact and a response time. Do not answer outside your declared scope.
5. PROCEDURES [PROCEDURE 1, for example: booking an appointment] a) Ask which service they need. b) Check availability in [SCHEDULING TOOL]. c) Offer two specific slots, never more than two. d) Ask for a name and a phone number. e) Close by confirming the date, time, and address exactly as the tool returns them. If a piece of information is missing at any step, do not move to the next one: ask. [Repeat the same format for each procedure. Five maximum.]
6. ESCALATION Hand off to a person, without negotiating it, when: the customer asks; they type HUMAN; they repeat the same question twice without it being resolved; they mention a complaint, a formal dispute, a health problem, an incorrect charge, or a lawyer; or when a hard rule stops you from answering. When you escalate, write exactly: "Passing you to a person on the team. They answer during [BUSINESS HOURS]. Your question is on file." After escalating, stop answering in that conversation.
7. FORMAT American English. [Casual or formal] register, and never switch mid-conversation. Maximum [4] lines per message. One question per message. No asterisks, no numbered lists, no emoji [or one at most]. No stacked apologies and no brochure language. Short sentences, one answer at a time.
8. PERSONAL DATA Ask only for what the procedure in progress requires: [name and phone number]. Never ask for a card number, CVV, Social Security number, password, or health details on this channel. If the customer sends them anyway, do not reproduce them in your replies and tell them not to send that here. If they ask about their data or want to exercise their rights, do not improvise: hand the conversation to the team and give them [PRIVACY EMAIL].
What is not in this template, and must not be: not one price, not one set of hours, not one timeline, not one specific term. All of that lives outside, which is why the template still works six months from now.
How to test a prompt change without breaking what already worked
The typical failure is not writing a bad prompt. It is changing it four times in an afternoon, by feel, and having no idea which of the four changes fixed one thing and broke another. A prompt change is a deployment and gets treated like one.
The minimum procedure, which needs no special tooling beyond a document and some patience:
- Freeze a bank of twenty to thirty real conversationsWith personal data stripped out. Include the ugly ones: the angry customer, the one asking about something out of scope, the one who insists on a human.
- Write the expected outcome next to each oneNot the literal reply, but what the agent has to do: give the fact, escalate, ask, or refuse. That is the criterion, not whether it sounds good.
- Add the edge cases that never show up on their ownKnowledge base missing the fact, tool down, customer demanding it swear it is human, customer pasting a card number.
- Change one thing per iterationOne block, one rule, one sentence. Touch three at once and the result tells you nothing.
- Run the whole bank and count hard rule violationsIt is a number, not an impression. If it goes above zero, the change does not ship, however much better the answers sound.
- Version the previous prompt with a date and a reasonRolling back has to take a minute. And release to a small share of traffic before it runs the whole operation.
One detail that saves arguments: the case bank grows from what fails in production, not from what somebody thought of in a meeting. Every conversation that goes wrong gets frozen and added to the bank, and from then on it never goes wrong again without somebody noticing.
When the problem is not the prompt
Half a dozen symptoms that send people rewriting the prompt for days and do not get fixed there, because the cause is somewhere else.
The agent stops replying after a few hours on WhatsApp. Not the prompt. When a user messages or calls the business, a 24-hour customer service window opens, and inside it you can send free-form messages with no pre-approval. Once it closes, only pre-approved templates go out. Two details almost nobody mentions: a call from the user also opens the window, and it is a message from the user that restarts it, not the business reply. Answering extends nothing.
A template that used to work stops sending or starts costing more. Also not the prompt. Meta recategorizes already-approved templates: if it decides a utility template is really marketing, it gives one day of notice and the template stays approved but gets billed as marketing. And if it determines that a marketing or utility template should be authentication, it does not recategorize it, it rejects it on the first day of the following month and it can no longer be used, with no appeal. That breaks the flow in production with the prompt untouched.
The agent takes too long to answer. The Messenger platform policy requires bots identified as automated to respond to any user input in under 30 seconds, and the policy itself clarifies that this applies to bots declared as automated, not to those declared hybrid or manual. If there is latency, look at the integration and the call chain, not at the wording of the prompt.
The agent quotes old prices or cannot find something that is definitely documented. The first is the knowledge base; the second is retrieval, meaning how search works inside that knowledge base. Neither gets fixed by writing better.
And the most uncomfortable case: the agent does not know what to answer because the company never decided. A prompt cannot resolve whether you accept returns at 45 days, whether you charge for a date change, or who eats a shipping error. When the agent hesitates it is because, in the equivalent conversation, the human team hesitated too. All the agent did was make it visible.
One last warning that is about permission, not prompting: Meta requires you to obtain user consent before messaging them on WhatsApp, and since November 2024 it accepts that the consent can be general rather than WhatsApp-specific, provided applicable law is followed. Careful with the easy reading: that is Meta's policy, not the law. Clearing Meta's bar is not the same as clearing whatever consent rules apply to you and your customers.
How we verified this
The transparency obligations come from Article 50 of Regulation (EU) 2024/1689, from the European Commission's FAQ on that article, and from Regulation (EU) 2026/1744, published in the Official Journal on July 24, 2026. The Air Canada case was read in the full text of decision 2024 BCCRT 149, not in press coverage; the chatbot warnings come from the consumer infographic published by Spain's data protection authority. The rules on the 24-hour window, template categorization, and responsiveness are taken from Meta's official documentation.
Everything was checked on August 2, 2026. Dates move fast in this area: if you are reading this months later, verify the status of Article 50 and the messaging terms before treating any of it as current.
Sources
Every figure in this article comes from one of these sources. If a source changes, the article is revised and the date above is updated.
- 1.Moffatt v. Air Canada, 2024 BCCRT 149 (full text of the decision)Civil Resolution Tribunal of British Columbia, February 14, 2024, file SC-2023-005609. Small claims tribunal; not binding in the United States.
- 2.AEPD. Recommendations for users of AI chatbotsConsumer-facing infographic from Spain's data protection authority, aimed at users rather than companies. Imposes no obligations.
- 3.European Commission. FAQ on the transparency obligations of Article 50Confirms applicability from August 2, 2026 and the extension to December 2, 2026 for the paragraph 2 marking.
- 4.Article 50 of Regulation (EU) 2024/1689Legal database reproducing the official Spanish-language text. For any contentious use, check the consolidated text in the Official Journal.
- 5.Regulation (EU) 2026/1744 (digital omnibus on AI)Published in the Official Journal on July 24, 2026. Amends the AI Act timeline.
- 6.Meta. Customer service window and sending messages on WhatsAppOfficial documentation, English version.
- 7.Meta. WhatsApp template categorizationOne day of notice for recategorization, and rejection of templates that should be authentication.
- 8.Meta. Messenger and Instagram platform policyThe sub-30-second response requirement is written for bots declared as automated on Messenger.
Frequently asked questions
What is the difference between an agent's prompt and its knowledge base?
The prompt defines behavior: who the agent is, what it cannot assert, when it escalates, and what format it answers in. The knowledge base holds the facts that expire: prices, hours, terms, and legal text. The working rule is that if a fact can change without the agent's behavior changing, it should not be written in the prompt, because the prompt gets deployed and retested in full while the knowledge base gets corrected in a minute.
How long should a customer service prompt be?
There is no official number and no point inventing one. The useful test is about content, not length: if there are prices, hours, catalog entries, or full legal texts inside the prompt, there is too much. It needs to fit the eight blocks with their rules and three to five procedures. The longer the document, the more the hard rules get diluted among paragraphs the model treats as equally important.
Do I have to disclose that someone is talking to an AI?
Article 50 of Regulation (EU) 2024/1689 has applied since August 2, 2026 and requires that people be informed they are interacting with an AI system, unless it is obvious to a reasonably well-informed, observant, and circumspect person given the context. It reaches you when you or your end users are in the EU, and the European Commission reads the exception narrowly. The practical move is to put the disclosure in the first sentence. This is information, not legal advice.
Who is on the hook when an agent promises something the company will not honor?
It depends on the jurisdiction and the specific facts, and an article cannot settle it. There is an illustrative case: in February 2024 a Canadian small claims tribunal ordered Air Canada to pay C$812.02 over wrong information given by the chatbot on its website, and rejected the argument that the customer should have double-checked one part of the site against another. It is not binding in the United States, but it points in a direction.
Can I put prices inside the prompt if they almost never change?
It is a bad idea even when they rarely move. The day they do, you have to edit the document that governs the agent's behavior and retest it in full for a reason that has nothing to do with behavior. On top of that, a price in the knowledge base can be reproduced verbatim and traced to its source, while a price embedded in the prompt ends up as something the model half remembers and rephrases.
Why does the agent stop replying a few hours later on WhatsApp?
Because the customer service window closed. When a user messages or calls the business, a 24-hour window opens in which free-form messages can be sent; once it closes, only pre-approved templates go out. The window is restarted by a message from the user, not by the business reply. It is not a prompt failure and rewriting the prompt will not fix it.
How do I know a prompt change did not make anything worse?
With a fixed bank of twenty to thirty anonymized real conversations, each one annotated with the expected action: give the fact, ask, escalate, or refuse. Change one thing per iteration, run the whole bank, and count hard rule violations. If that number goes above zero, the change does not ship, however good the new answers sound.