How do I write a prompt for a sales agent?
State the job, the voice, the hard rules, the inputs it will see, the output format, and what to do when unsure. Keep facts in the knowledge base, not the prompt, and version the prompt like code.
The short answer
- A working sales agent prompt covers six things explicitly. The job it is doing. The voice it should write in. The hard rules it must never break. The inputs it will see. The exact output format expected. And what to do when it is unsure.
- Keep facts, pricing, offers, policy details, in a knowledge base the agent queries at run time, not pasted into the prompt. Facts change. A prompt that has to be edited every time a price changes is a maintenance burden and a source of stale answers.
- Version the prompt the way you would version code. Track what changed and why, so a shift in output quality can be traced to a specific edit rather than investigated from scratch.
- 'What to do when unsure' is not optional. An agent with no instruction for the low-confidence case will guess. A confident guess is harder to catch than an agent that flags uncertainty and hands off to a person.
Why the structure matters more than the wording
Most advice about prompt writing focuses on phrasing. Be specific, use examples, avoid ambiguity. That advice is not wrong, but it undersells a bigger issue. A prompt missing an entire section, like what to do when the agent is unsure, will produce inconsistent behavior however well the rest is phrased. The agent fills the gap with its own judgement, which varies from run to run in ways a person debugging the output later finds hard to reproduce.
Treating the prompt as a document with required sections, rather than a single block of instructions, catches this. If the job, the voice, the hard rules, the inputs, the output format and the fallback behavior are each written as a distinct, checkable piece, it becomes obvious when one is missing. A missing field in a form is easier to notice than a missing sentence in a paragraph.
The six sections and what goes in each
| Section | What goes in | Example line |
|---|---|---|
| The job | One sentence naming exactly what the agent does | "Draft a follow-up reply to an inbound email from a prospect." |
| The voice | A short reference to the company's actual voice, not adjectives | "Match the tone in the attached sample emails; do not use exclamation points." |
| Hard rules | Things the agent must never do, stated as rules, not suggestions | "Never mention a price we have not published. Never promise a delivery date." |
| Inputs | What the agent will see and where it comes from | "The last five messages in this thread, and the contact's deal stage." |
| Output format | The exact shape of the response expected | "Return a subject line and a body, no preamble, under 150 words." |
| When unsure | The specific action to take below a confidence threshold | "If you cannot determine the contact's intent, flag for review instead of guessing." |
Keeping facts out of the prompt, and the prompt out of drift
A prompt that includes "our Core plan is $299/mo" will be wrong the day that price changes. Worse, it might be wrong in five different prompts across five different agents that each hardcoded the same fact separately. A knowledge base the agent queries for that fact at run time needs updating in exactly one place. Every agent that reads from it stays correct automatically.
Disclosure: SalesCrew is our product, and its Inbox agent's prompts follow this structure. Job, voice reference, hard rules, the specific thread and record context as inputs, a defined draft format, and an explicit instruction to leave low-confidence drafts for review rather than sending. Facts like pricing and offers are pulled from the knowledge base via search tools at run time, not written into the prompt text.
Prompts that contain customer data leak it into every call
Questions
- Why should facts live in a knowledge base instead of the prompt?
- A prompt that hardcodes pricing, offers or policy has to be edited every time one of those facts changes. It is easy to miss an instance buried in a long prompt. A knowledge base the agent queries at run time stays current without touching the prompt at all.
- What does 'version the prompt like code' actually mean in practice?
- Track changes to the prompt the way you would a code file. Commit history, a changelog of what changed and why, and a way to compare the current version to a previous one when output quality shifts. A prompt edited ad hoc in a settings box with no history is much harder to debug later.
- What should 'hand to a person' look like inside a prompt?
- An explicit instruction naming the exact condition, such as a confidence threshold or a category of request, and the exact action to take, like flagging the item for review rather than guessing. Vague instructions like 'use your judgement' produce inconsistent behavior.