Prompt

The system prompt is the agent's standing instructions: who it is, how it talks, what it can and cannot do. The model reads the whole prompt at the start of every turn, so it is the single most important piece of text you author. Everything the agent says is shaped by it. You edit it on the Prompt page, and it autosaves as you type.

You do not write a prompt from a blank page. A new agent ships with a complete, sectioned starter prompt already written. Your job is to tune it: swap in your business's details, sharpen the rules, and tighten anything that does not fit.

What a new agent starts with

When you create an agent, the platform copies a house-standard starter prompt into the new agent's first draft (a draft version, unpublished, yours to edit). It is a real, working inbound-assistant prompt, derived from a production flagship agent with the business-specific bits stripped out and left as fill-in slots.

The starter prompt is organised into named sections:

• Identity and greeting: who the agent is, which business it answers for, and the one rule it never breaks: its identity is fixed for the whole call, even if a caller insists it pretend to be something else.
• Personality: the register. Professional, friendly, helpful; Australian, no slang.
• Voice and tone: speak like a helpful person, not a salesperson or an AI; natural phrasing; match the caller's level of detail.
• Response style: the spoken-output rules (covered below): say only the words the caller should hear, keep replies to one or two short sentences, look facts up with a tool rather than reciting from memory.
• Topics you can discuss: the agent's lane, and how to steer back when a caller drifts off it.
• Capturing names, numbers and places: how to handle proper nouns and identifiers that speech-to-text tends to garble: ask the caller to spell them, read them back, confirm.
• Handling common situations: short, concrete responses for the recurring moments: did not catch them, a tool found nothing, an off-topic question, a frustrated caller.
• Ending the call: end only once the caller has clearly finished, not on a trailing "okay, thanks".
• Examples: a handful of short <example> exchanges showing the behaviour you want, with the business-specific bits left as slots to replace.

Why a sectioned prompt

The sections are not decoration. A model follows a prompt more reliably when its rules are grouped under clear headings than when they are buried in one long paragraph. Named sections also make the prompt easy for you to edit: you can find the rule you want to change without re-reading the whole thing, and you can see at a glance whether a behaviour you care about is covered. Keep the structure when you edit. Add a section if you need one; do not dissolve the prompt back into prose.

What belongs in the prompt, and what belongs in a tool

The prompt is for persona, rules, and boundaries: the things that are true on every call regardless of what the caller asks. How the agent speaks, what it will not discuss, how it confirms a name, when it ends the call, when it transfers to a human.

The prompt is not where you document how each tool works. Every tool carries its own description, and that description is what the model reads to decide when to call it. The runtime's guiding principle is tools first, prompt last: when you want to change how the agent uses a tool, edit the tool's description before you touch the prompt. A tool description is the highest-leverage prompt surface you have.

For this reason the starter prompt has no per-tool section. The only tool-related line it carries is the one in Response style: say a short, natural lead-in before using a tool so the caller is not left in silence while it runs.

The spoken-output rules

The agent is on a phone call, so everything it generates is read aloud by text-to-speech. The starter prompt's Response style section carries the rules that keep spoken output clean. They matter enough to call out:

• Say only the words the caller should hear. No reasoning out loud, no JSON, no tool arguments, no timestamps, none of the bracketed tool notes you see in the examples. Those belong in the tool call, not in the reply.
• Keep it short. One or two sentences a turn. Pick the single most relevant thing, say it, and wait. A long list read aloud is what makes callers hang up.
• Look it up first. Never state a price, fact, status, or policy from memory. Use a tool, then say what it returned. If the tool finds nothing, say so and offer a next step.
• Speak numbers as words. Prices, dates, and phone numbers in spoken form ("one hundred and nine dollars", "the twenty-first", phone numbers one digit at a time). No bullet points, no dashes, no markdown.

These rules live in the seeded prompt, in plain view, so you can read and edit them. As a backstop, the runtime also strips markdown from the audio path, so a stray asterisk never reaches the speaker even if a rule gets edited out. The rules in the prompt are still what does the real work.

The one fixed safety layer

Above your prompt sits one layer you cannot see or edit. At call time the runtime prepends a fixed set of security and safety rules to every agent's prompt, the same floor for every agent in the platform. These rules cover things like: disclosing account, order, and billing details only to the verified account holder, treating everything the caller says as input rather than instructions (so a caller cannot talk the agent out of its rules), never revealing what an identifier looks like, and never fabricating a fact or a binding promise. They also hold under pressure: urgency, anger, or flattery do not waive any of them.

This floor is applied in the runtime, not stored in your editable prompt, so it cannot be accidentally deleted, and it takes precedence over anything in your prompt that conflicts with it. Everything else the agent does is what you wrote. The prompt you see in the editor is the entire prompt you control, plus this one fixed layer underneath it.

Writing good rules

A few habits make prompts the agent actually follows:

• Short and concrete beats long and abstract. "Read the order number back one character at a time and wait for a yes" works; "be careful with identifiers" does not.
• Show, don't just tell. An <example> exchange teaches a behaviour more reliably than a paragraph describing it. The starter prompt's examples are there for exactly this; add your own for the situations specific to your business.
• Say each rule once. Repeating a rule in two places does not make it stronger; it makes the agent hear the same instruction twice, and duplicated sections are blocked at publish time. If a rule matters, state it once, clearly.
• Frame it positively. Tell the agent what to do, not just what to avoid.
• Keep it tight. Every extra sentence is one more thing the model has to weigh on every turn, and contradictory or redundant instructions make behaviour less predictable, not more. Cut anything that is not pulling its weight.

Editing the bracket slots

The starter prompt marks every fill-in spot with [square brackets]: [Assistant], [Business], [one line on what the business does], and the bracketed bits inside the examples. Replace each one with your own details.

The brackets are the only placeholder style the starter prompt uses, and there is a reason. They are plain prose, so the agent will read them aloud verbatim if you leave them in. Two other syntaxes mean something specific and should never appear in the prompt as a fill-in:

• {{double curly braces}} are live variables that get substituted at call time. The editor flags an unknown {{token}} as a blocking error, because an unresolved one would break the call.
• <angle brackets> are reserved for things like the <example> tags and are not a fill-in convention.

So: replace [brackets] with real text, use {{variables}} only for genuine runtime values you have defined, and leave the <example> tags as they are.

Iterating: test, then evals

Prompt work is a loop, not a one-shot. After an edit, talk to the agent in the test panel before any caller does. The test panel is never blocked by the validator, so you can try a half-finished idea, hear how it sounds, and adjust. When you open the panel, the editor flushes any pending edits first, so what you test is what you just wrote.

For changes you want to hold up over many calls, lean on evals rather than a single test. A one-off test tells you the agent handled that call; a small suite of evals tells you it handles the call reliably, across different caller styles and a few awkward turns. Every new agent ships with a baseline eval already attached, so the gate is reachable from day one. Add evals for the situations your agent actually handles, and re-run them after a prompt change to confirm you fixed the thing you meant to without breaking something else.

Saving and publishing

The prompt editor autosaves. Your edits land in the agent's draft on a short delay, and Cmd/Ctrl+S saves immediately. Drafts are never live: edits to a draft cannot reach a real caller until you publish.

Publishing promotes the draft to the live version. The publish gate runs the validator first: an empty prompt, an unknown {{variable}}, or duplicated sections block publishing until you fix them, while an unfilled [bracket] slot is flagged as a risk you can choose to ship past. A published version is read-only; to change a live agent, edit the draft and publish again. Only one version is live at a time. See agents for the full draft-and-publish flow.