What a prompt is in Finn
A Finn's behavior comes almost entirely from its prompt. In the editor (Start from scratch, or Edit on an existing Finn), the prompt is the single System prompt field on the Call flow tab, next to the Welcome message. When you build from a playbook instead, the setup's personality step splits it into three fields (Role & identity, Tone & style guidelines, Response guidelines). Everything on this page applies to either.
Write the prompt in four parts, in this order. Skip one and the agent gets brittle on live calls.
| Part | Where it lives | Length |
|---|---|---|
| Identity | Role & identity, or the top of the System prompt | 1-3 lines |
| Goal | Role & identity or Response guidelines | 1 line |
| Rules | Tone & style guidelines | 5-15 bullets |
| Examples | Response guidelines | 2-4 micro-dialogues |
Identity
Anchor a name, a role, an employer, and a tone. Nothing else.
You are Aria, a friendly appointment coordinator at Smile Dental Clinic.
You speak with patients calling to confirm, reschedule, or cancel an upcoming visit.
You are warm, brief, and never push extra services.
Backstory costs latency and gives the model room to improvise. Three lines is the ceiling.
Goal
One sentence, one concrete outcome.
Goal: confirm, reschedule, or cancel the patient's upcoming appointment within 90 seconds.
A goal like "help the caller with whatever they need" makes the agent meander and calls run long. If the real job is multi-step (qualify, then book, then warm-transfer), split it into separate steps in the Call flow instead of stacking it into one prompt.
Rules
State positives and negatives. The "never" rules matter as much as the "always" rules, because they are the only thing standing between the model and an improvised answer it should not give.
Rules:
- Always confirm you're speaking with the person named in the greeting before sharing any appointment details.
- If the caller says "remove me" or "stop calling", honor immediately and end the call politely.
- If asked if you're a real person, say honestly: "I'm Aria, a voice assistant for Smile Dental."
- Never quote a price — transfer to the front desk if asked.
- Never schedule a Sunday appointment — the clinic is closed.
- If the caller's intent is unclear after two clarifying questions, offer human transfer.
Rules that are only negative leave the agent with no positive frame, and it will stall rather than recover. Pair each prohibition with what to do instead.
Examples
Two to four short dialogues anchor tone better than any adjective. Show edge cases, not the happy path you already described in the rules.
Example 1 — Smooth confirm
Aria: "Hi, is this Priya? It's Aria from Smile Dental, calling about your visit on Thursday."
Caller: "Yes."
Aria: "Great. We have you booked for 4 PM Thursday with Dr. Mehta for a cleaning. Still works?"
Caller: "Yes, that works."
Aria: "Confirmed. See you Thursday. Have a great day."
Example 2 — Reschedule
Caller: "I need to move it."
Aria: "No problem. We have openings Friday at 11 AM or 3 PM, or Monday at 10. What works best?"
Examples that restate the rules add nothing. Write the angry caller, the ambiguous request, the caller who answers a different question than the one asked.
Variables
Put audience columns in double braces, for example {{ first_name }}. On a call, each one is filled from the contact's row in the audience you deploy with, matched to the column header regardless of case, spaces and punctuation. Only the welcome message and the system prompt are filled. Single braces such as {first_name} aren't filled on calls, and neither are placeholders inside call flow step prompts.
So {{ appointment_date }} and {{ loan_amount }} work if your audience has those columns. See variables.
Length
Keep the prompt as short as the job allows. A long prompt is read on every turn, and the more rules it carries, the more likely the agent is to contradict one of them. When a prompt keeps growing, move multi-step logic into the call flow and facts into a knowledge base, which holds facts the prompt should not carry inline.
Common failures
| Mistake | What goes wrong | Fix |
|---|---|---|
| Multi-paragraph identity | Bloats the first token, slows response | Three lines |
| Vague tone ("be helpful") | No effect on output | Three concrete adjectives |
| Open-ended goal | Agent meanders, calls run long | One outcome per agent |
| Negative-only rules | Agent stalls with no fallback | Mix positive and negative |
| No examples | Tone drifts under pressure | Two to four |
| Examples mirroring the rules | Redundant | Show edge cases |
Debugging a prompt
When calls go off-script, do this in order:
- Listen to the recording in call logs. Do not guess from the transcript summary.
- Find the first turn that goes wrong. Every turn after it is downstream noise.
- Add one rule covering that exact scenario, plus one example.
- Re-test on the same number using Test → Phone call from the Finn page.
If step 4 does not fix it, the problem is not the prompt. Look at the workflow, the audience data, or the knowledge base. Most "the model is dumb" reports are a missing rule for a scenario nobody wrote down.
Prompt edits are made in the dashboard, or through the API with the system_prompt field (the System prompt) and the identity_text, style_guardrails and response_guidelines fields. See api-finns. Changes apply to new calls only. In-flight calls finish under the configuration they started with.