AgentScript primer

A .agent file is a flat sequence of top-level blocks. Indentation defines containment (similar to YAML), and most blocks accept either inline values or block scalars introduced with | or ->.

system:
    instructions: |
        ...
config:
    developer_name: "Target_Service_Agent"
variables:
    order_number: mutable string = ""
start_agent subagent_selector:
    ...
subagent returns:
    ...
modality voice:
    voice_id: "..."

The systemblock carries the agent's top-level instructions and the built-in messages (e.g. welcome, error) returned to the customer.

system:
    instructions: |
        You are Target's customer service AI agent...
    messages:
        welcome: |
            Hi, I'm Target's AI assistant.
        error: "Sorry, something went wrong."

Identifies the agent and provides metadata used by the platform.

config:
    developer_name: "Target_Service_Agent"
    agent_label: "Target Service Agent"
    agent_type: "AgentforceServiceAgent"
    description: "Customer service agent for returns and price match."

Typed slots referenced from reasoning and action wiring. Variables can be mutable or linked (bound to a record source like @VoiceCall.Id).

variables:
    order_number: mutable string = ""
        description: "The customer's order number..."
    customer_verified: mutable boolean = False
        description: "Identity-verification gate."
    VoiceCallId: linked string
        source: @VoiceCall.Id

The entry router. Like a subagent, but it's where every conversation begins. Most start agents are pure routers — their only job is to call a transition action.

start_agent subagent_selector:
    label: "Subagent Selector"
    reasoning:
        instructions: |
            ...routing rules...
        actions:
            go_to_returns: @utils.transition to @subagent.returns
                description: "Returns, refunds..."

A focused workflow with its own reasoning instructions, action bindings, and (often) inline action definitions. Subagents communicate by transitioning to each other or by invoking actions.

subagent returns:
    label: "Order Returns"
    description: |
        Handles return, refund, exchange...
    before_reasoning:
        if @variables.customer_verified == False:
            transition to @subagent.customer_verification
    reasoning:
        instructions: ->
            | TARGET RETURNS WORKFLOW...
        actions:
            check_eligibility: @actions.Get_Return_Eligibility_By_Item
                with memberId = @variables.member_id
                with orderNumber = @variables.order_number

The graph view renders before_reasoning and after_reasoning transitions as dashed flow edges between subagents.

Actions are typed, callable units backed by Apex (apex://...) or other runtime targets. They declare structured inputs and outputs that other parts of the script wire variables into.

actions:
    Get_Order_Details:
        label: "Get Order Details"
        target: "apex://NF_GetOrderDetailsHandler"
        inputs:
            orderNumber: string
                is_required: True
        outputs:
            isSuccess: boolean
            memberId: string

Channel configuration — voice settings, telephony adapters, and similar. The graph surfaces this on the system node so it's visible at a glance.

modality voice:
    voice_id: "UgBBYS2sOqTuMpoF3BR0"
    outbound_speed: 1.0
connection telephony:
    adaptive_response_allowed: True