Skip to main content

​
Variable Naming

Do:
  • Use clear names: customer_email, appointment_date
  • Use prefixes for related vars: api_response, api_status, api_error
  • Use boolean prefixes: is_verified, has_appointment, can_proceed
  • Keep names short but meaningful: booking_id not booking_identifier
Don’t:
  • Use vague names: data, value, temp, var1
  • Abbreviate: cust_nm, appt_dt, usr_ph
  • Mix styles: customerName, appointment-date, USER_PHONE
  • Use very long names

​
Variable Organization

Do:
  • Group related custom variables
  • Use consistent prefixes for API-related variables
  • Add descriptions for complex variables
  • Use enums for fixed options
Don’t:
  • Create duplicate variables with different names
  • Mix unrelated data in one variable
  • Add variables “just in case”; add when needed

​
Single Prompt Agent Variables

Do:
  • Use custom variables for configuration values (business name, hours, feature flags)
  • Use system variables for context (time, call info, user/agent details)
  • Use descriptive names that explain purpose
  • Group related configuration variables
  • Use boolean variables for feature flags (enable_transfers, accepts_reservations)
  • Document what each custom variable controls
  • Use appropriate types (number for counts, boolean for flags)
  • Test with different variable values per environment
Don’t:
  • Try to use extracted or static variables (not supported in single prompt agents)
  • Expect to collect data from conversations into variables
  • Use single prompt agents when you need extraction or multi-step workflows
  • Hardcode values that should be configurable
  • Create complex variable structures; keep config simple
  • Forget that custom variables become params in the agent configuration

​
Extraction Strategy

Do:
  • Test tools first (API) or define expected response (Web) before extraction
  • Use AI extraction for unstructured user input
  • Use toolpath extraction for structured API responses
  • Use static variables for computed or formatted values
  • Mark critical variables as required
  • Write clear, specific extraction prompts
  • Use the path selector instead of typing JSONPath by hand
  • Test success and error cases
  • Use the preview to confirm extracted values
Don’t:
  • Configure extraction without testing (API) or defining expected response (Web)
  • Manually write JSONPath when the path selector is available
  • Assume API shape without testing
  • Skip error scenarios
  • Extract too many variables in one turn
  • Use overly complex JSONPath when simpler paths work
  • Extract variables you never use
  • Use generic prompts like “get the data”

​
Tool Testing

API tools:
  • Do: Always test before extracting; use realistic data; test success and error; use path selector on test response; verify preview; document expected shape.
  • Don’t: Skip testing; guess the response; ignore errors; test only one scenario; skip edge cases (empty arrays, nulls, missing fields).
Web tools:
  • Do: Define expected response before extracting; manually test to verify format; document object vs string; keep expected structure realistic and up to date.
  • Don’t: Assume format; use overly complex expected structure; forget to document; skip manual testing.

​
Performance

Do: Reuse variables across nodes; use static variables for computed values; remove unused variables; use the right types (e.g. number for numbers). Don’t: Create many unused variables; extract the same data repeatedly; use object/array when a simple type is enough; store large structures in variables.

​
Validation & Templates

Do: Fix validation errors promptly; use enums for fixed options; mark critical variables required; test availability in different paths; use templates for dynamic text; provide fallbacks for optional variables. Don’t: Ignore warnings; reference variables that might not exist; use variables before they’re set; hardcode values that should be variables; forget to handle missing values. See Troubleshooting for common issues and Examples for full flows.