Configure Agent Prompt

Write the prompt as the operating script for a live voice call. It should define who the agent is, what the call must achieve, how the agent should speak, what data it must collect, and when it should use functions.

For voice, keep instructions short and operational: one question at a time, clear fallback behavior, explicit function triggers, and no overlapping rules.

In RocketAiFlow, write prompts as operational rules for a real phone call, not as a product description.

Use clear sections, ordered steps, and examples when behavior needs to be demonstrated. This is also aligned with the OpenAI prompt guidance.

• use short sections with explicit headings
• state the business objective in plain language
• define the speaking style with concrete rules, short answers, and one question at a time
• list the required information the agent must collect
• name the functions the agent can call and when to call them
• state what the agent must do when information is missing
• avoid conflicting instructions and broad vague goals

Use this structure as a starting point for complex prompts. Keep each section short. Add detail only where it changes behavior.

• Role: who the agent is and who it represents.
• Call objective: the business outcome the call should reach.
• Speaking style: how the agent should speak, how long answers should be, and how it should handle uncertainty.
• Information to collect: the fields needed before the workflow can continue.
• Function rules: exact function names, trigger conditions, required fields, and negative rules.
• Transfer rules: when the call should be transferred to a person or destination.
• Closing rules: how the agent should summarize, close, or leave the call unresolved.
• Context variables: contact or campaign values the prompt can use, such as {t.name} or {t.data.birthDate}.

# Role
[who the agent is and who it represents]

# Call objective
[the business result the call should reach]

# Speaking style
- Speak in short sentences.
- Ask one question at a time.
- Confirm important values such as dates, names, and phone numbers.
- Do not invent information.

# Information to collect
- [required field 1]
- [required field 2]
- [required field 3]

# Function rules
- Use function_name only when [trigger condition].
- Before calling it, collect [required fields].
- If a required field is missing, ask one short follow-up question.
- Do not call the function when [negative condition].

# Transfer rules
[when to transfer and which destination is allowed]

# Closing rules
[how to summarize the result and close the call]

# Context variables
[which {t...} values may be used and what to do if they are missing]

Use this as a compact starting point and adapt the role, objective, required fields, and function names to your workflow.

# Role
You are Rocket Demo Assistant, a voice agent for RocketAiFlow.

# Goal
Qualify the caller and understand whether they want a demo, a callback, or more information.

# Conversation style
- Speak clearly and briefly.
- Ask one question at a time.
- Do not invent information.
- If the caller asks something you cannot answer, say so and offer a transfer.

# Information to collect
- name
- company
- reason for the call
- interest level
- preferred next step

# Functions
- Use save_lead_qualification only after you have collected the required qualification fields.
- If a required field is missing, ask one short follow-up question before calling the function.
- Use transfer_call only when the caller asks to speak with a human or the workflow requires a handoff.

# Closing
Summarize the next step before ending or transferring the call.

In RocketAiFlow, function rules belong in the prompt when the agent must decide whether to call a configured function during a live call.

Provider function-calling guidance is useful for schemas, names, and tool behavior. See the OpenAI function calling guide.

• mention each function by its exact name and connect it to a concrete trigger condition
• list the required fields that must be collected before the function can be called
• if a required value is missing, tell the agent to ask one short follow-up question before calling the function
• Good: “Use transfer_to_service when the caller asks for sales, support, or administration. Set exten to the matching supported service.”
• Good: “Use rescheduled_contact only after the caller asks to be contacted later and you have confirmed the callback date and time.”
• Avoid: “Use tools when useful.” This is too vague for reliable behavior.
• Add a negative rule for every important function: do not call it if the required fields are missing or the caller intent is unclear.

Template variables can personalize the prompt, but they should not make the instruction hard to read.

Use variables such as {t.name}, {t.phone}, or {t.externalId} only when the prompt or function needs that context.

For outbound calls, variables come from the campaign contact. For inbound calls, variables render only when the agent has contact retrieval enabled and Contact Inbounds contains a list associated with that agent and a number that matches the caller.

• use contact variables for known data already saved on the contact or campaign record
• ask the caller for values that are not already available
• do not assume a variable will render unless the value exists on the active contact; if there is no match, variables such as {t.name} or {t.data.birthDate} are not rendered
• review the detailed model in Dynamic Parameters