System Prompt
The standing instructions that define a chatbot's job, tone, and limits, and why it is the single highest-leverage file in the whole build.
Updated 2026-08-18
A system prompt is the block of instructions handed to the model before every conversation, telling it who it is, what it is allowed to do, and how to behave. The user never sees it. On most platforms it is the one field that separates a useful agent from a liability.
Why it matters when you are buying or building
If a vendor will not show you the prompt or let you edit it, you do not own the behavior of your own bot. Ask that question during the demo. Every platform I actually run in production (Voiceflow, ElevenLabs, Telnyx, OpenAI Realtime) exposes it in some form, sometimes split across a global identity prompt and per-task instructions.
A prompt that works in production usually covers five things:
- Identity and scope. Who the agent is, what business, what it handles and what it does not.
- Facts that change. Hours, service area, pricing model, escalation number. These belong in variables or a knowledge base, not hardcoded prose you forget to update.
- The unhappy path. What to say when it does not know, and when to hand off to a person.
- Format rules. For voice, that means spoken-friendly output: no bullet lists, no URLs read aloud, numbers spoken naturally.
- An explicit list of things it cannot do.
That last one is not obvious until it bites you.
What I have seen in production
I had a receptionist agent that confidently told a caller it had blocked their number. It had no such ability. Nothing in the prompt said it could block numbers, but nothing said it could not, so the model filled the gap with something plausible. The fix was a literal "abilities you do NOT have" section listing blocking, refunds, account changes, and anything else it might be asked for, with an instruction to say plainly that it cannot do it and offer to take a message. That pattern now goes into every prompt I write. See stopping chatbot hallucinations.
The second gotcha is mechanical. Prompts on most voice platforms support {{placeholder}} tokens that get substituted at runtime with caller data. If a token is left in the text and nothing fills it, the platform does not always error. It silently ships a prompt with literal braces in it, and the agent's behavior degrades in ways that are hard to trace. I have lost real time to that on a telecom client's assistants. Always dump the rendered prompt for a live session, not the template, when something looks off.
Keep prompts tight. Every token is re-sent on every turn, so it costs money and adds latency. Long, rambling prompts also dilute the rules that matter. Write it, then cut it in half.