ResponseAutomationV2
The primary workflow. A single, data-driven workflow that serves every brand rather than one
workflow per brand β behavior comes from the brandβs
AutomationConfig, not from code.
A cancel signal is checked at each phase, so a workflow can be aborted partway without
leaving the ticket in an inconsistent state.
Signals and queries
Function-calling loop
The LLM can call tools defined in the brandβs config. The workflow executes each tool call as a
Temporal activity and feeds the result back:
The loop ends when the LLM returns content instead of tool calls. A maximum of 10 rounds is
enforced, so a model that keeps calling tools cannot spin indefinitely.
create_fulfillment, cancel_subscription, and skip_charge take real action on customer
accounts. Which tools a brand exposes is part of its AutomationConfig β scope
tool_definitions to what that brandβs agent should actually be able to do, and use the review
gate for the rest.
Review gate
The gate compares the classification confidence against min_confidence. Below the threshold,
the workflow waits for a review_decision signal rather than dispatching.
escalation_always_review forces the gate on escalation paths regardless of confidence.
Runtime API
POST /v1/workflows/response/start, /v1/workflows/{id}/signal/review, and
/v1/workflows/{id}/status are the deprecated v1 surface. New integrations should use the
response-automation-v2 paths above.