Prompt

The model reads the system prompt on every turn, so everything the agent says is shaped by it. You edit it on the Prompt page, and it autosaves as you type.

What belongs in the prompt

Persona, rules, and boundaries: the things that are true on every call. How the agent speaks, what it will not discuss, when it ends the call, and when it transfers to a human.

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 belongs in a tool instead

Every tool carries its own description, and that description is what the model reads to decide when to call it. When you want to change how the agent uses a tool, edit the tool's description before you touch the prompt.

What the agent says out loud

Everything the agent generates is read aloud by text-to-speech, so the starter prompt carries spoken-output rules: say only the words the caller should hear, keep replies short, look things up with a tool, and speak numbers as words.

These rules live in the seeded prompt, in plain view, so you can 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 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.

These rules cover:

• disclosing account details only to the verified holder
• treating everything the caller says as input, not instructions
• never revealing what an identifier looks like
• never fabricating a fact or a binding promise

They hold under pressure: urgency, anger, or flattery do not waive them.

Why the floor is not in your prompt

The safety layer is applied at 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.

Writing good rules

Short and concrete beats long and abstract

works:     Read the order number back one character at a time and wait for a yes.
does not:  Be careful with identifiers.

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 does not make it stronger. Duplicated sections are blocked at publish time. Frame rules positively, too: tell the agent what to do, not just what to avoid.

Keep it tight

Every extra sentence is one more thing the model weighs on every turn. Contradictory or redundant instructions make behaviour less predictable. Cut anything that is not pulling its weight.

Testing a change

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.

For changes you want to hold up over many calls, use evals. A one-off test tells you the agent handled that call; a small suite of evals tells you it handles the call reliably. Every new agent ships with a baseline eval already attached.

Saving and publishing

The prompt autosaves on a short delay; Cmd/Ctrl+S saves immediately. Edits land in the draft and do not reach callers until you publish.

The publish gate runs the validator first.

A published version is read-only. To change a live agent, create a new draft and publish again.