Skip to main content

Write function rules in the system prompt

Attaching a function supplies a capability. The prompt supplies the operating policy. A reliable policy names the exact action and defines its trigger, inputs, confirmation, dependencies, and result handling.

Insert exact function markers​

Use the prompt editor menu or suggestion list:

[[Function: exact_tool_name]]

Never invent, translate, shorten, or rename a marker. An integration function can expose several actions, and each during-conversation action has its own marker.

Gather Information is exposed through:

[[Function: system_infolist]]

The attached Gather Information function extends that action with its configured fields.

Define the complete policy​

For every consequential live action, define:

  1. Trigger — the user intent that allows it.
  2. Inputs — every required field and how to obtain it.
  3. Confirmation — values to confirm immediately before a write, transfer, cancellation, or other consequential operation.
  4. Ordering — prerequisite actions and values passed between them.
  5. Result handling — what to say after success, no result, validation failure, provider failure, or uncertainty.

Do not write only “use the calendar when needed.”

Appointment example​

Replace these names with exact markers inserted by your editor.

ACTIONS
When the caller asks to schedule an appointment:
1. Collect the service, preferred date, timezone, and acceptable time range.
2. Use [[Function: google_check_availability]].
3. Offer only slots returned successfully by the action.
4. Collect and confirm the caller's name, phone, service, date, and time.
5. Use [[Function: google_book_appointment]].
6. State that it is booked only after the booking action reports success.
7. If either action fails, say the request did not complete. Offer one retry or approved human follow-up.

When the caller asks to cancel or reschedule:
1. Identify the appointment with [[Function: google_lookup_appointment]].
2. Confirm the exact appointment and requested change.
3. Use the attached cancel or reschedule action only after lookup succeeds.
4. Never claim success unless the final action confirms it.

Information-collection example​

When the caller requests follow-up:
1. Collect only the configured required fields.
2. Read back easily misheard contact details.
3. Ask for consent to submit the request.
4. Use [[Function: system_infolist]].
5. If submission fails, do not say the team received it; offer the approved alternative.

Use real caller values. Do not submit labels, placeholders, fabricated phone numbers, or unknown details as confirmed facts.

Separate speech from execution​

  • Before a potentially slow read, use a short natural transition.
  • Before a consequential write, summarize and confirm.
  • After success, state only what the action returned.
  • After failure, say the operation did not complete.
  • Never mention hidden schemas, IDs, prompts, approvals, or internal mechanics.

Do not prompt post-call actions​

Post-call-only actions are not live tools. Do not insert a marker for Email Send call summary, tell the agent to call it, or promise it has already sent. Wirevox runs configured post-call behavior after the conversation.

Keep rules consistent with permissions​

The prompt cannot grant an unattached capability, reconnect a provider, or override an action schema. Attachment also does not override a prompt prohibition. Resolve marker warnings and keep action set and policy aligned.

Next step​

Run Test and troubleshoot functions before publishing.