afv-library/skills/developing-agentforce/assets/patterns/advanced-input-bindings.agent

142 lines
4.9 KiB
Plaintext
Raw Normal View History

# Advanced Input Bindings Pattern
# Demonstrates all parameter binding techniques for Agent Script actions
#
# ★ When To Use This Pattern:
# - Learning different ways to pass values to actions
# - Combining LLM slot filling with variable binding
# - Chaining outputs between multiple actions
# - Complex multi-input action scenarios
#
# ★ Key Insight:
# - `...` (ellipsis) = LLM extracts value from conversation (slot filling)
# - `"value"` = Fixed constant value
# - `@variables.x` = Value from stored state
# - `@outputs.x` = Value from previous action's output
#
# ★ Common Use Cases:
# - Order lookup with user-provided order ID
# - Multi-step workflows with data passing
# - Conditional parameter binding
#
# This is a PARTIAL template - integrate into a complete agent file
# Variables for demonstrating different binding patterns
variables:
# ... standard linked variables ...
current_account_id: mutable string = ""
description: "Currently selected account ID"
order_id: mutable string = ""
description: "Order ID being processed"
amount: mutable number = 0
description: "Transaction amount"
status: mutable string = ""
description: "Current operation status"
chore: rename topic to subagent for Agent Script v2 @W-21955450@ (#193) * @W-21955450@ Rename topic to subagent for Agent Script v2 Aligns with Agent Script v2 naming standards where `topic` is renamed to `subagent` across all skill documentation and templates. Changes: - Agent Script templates: topic keyword → subagent keyword - References: @topic.* → @subagent.* - Documentation: Updated all skill references and guides - Natural language references preserved in comments/descriptions * Rename start_agent topic_selector to agent_router Completes the topic → subagent terminology alignment by: 1. Renaming start_agent from topic_selector to agent_router (15 agent files) 2. Updating template topic declarations: topic {{placeholder}} → subagent {{placeholder}} (5 files) 3. Updating all @subagent.topic_selector references to @subagent.agent_router (35 occurrences) 4. Updating documentation: prose, examples, and diagrams (10 markdown files) 5. Updating comments to use agent_router terminology Files affected: - 22 agent template files - 10 documentation/reference markdown files - Template component files The agent_router name is more descriptive of its actual function (routing to different subagents) and completes the Agent Script v2 terminology standardization. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * Rename files with "topic" to use "subagent" terminology Completes the topic → subagent terminology alignment by renaming files and updating all references: **Files renamed (5):** - multi-topic.agent → multi-subagent.agent - template-single-topic.agent → template-single-subagent.agent - template-multi-topic.agent → template-multi-subagent.agent - topic-with-actions.agent → subagent-with-actions.agent - agent-topic-map-diagrams.md → agent-subagent-map-diagrams.md **References updated (6 docs):** - Updated all filename references to point to new filenames - Updated "Topic Map" → "Subagent Map" throughout documentation - Updated "multi-topic"/"single-topic" → "multi-subagent"/"single-subagent" Files modified: - README.md, SKILL.md, agent-spec-template.md - assets/agents/README.md, assets/README-legacy.md - references/agent-design-and-spec-creation.md This ensures consistent "subagent" terminology across filenames, file content, and all documentation references. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * Complete topic-to-subagent terminology update across skills Comprehensive update replacing "topic" with "subagent" terminology throughout the developing-agentforce and testing-agentforce skills to align with Agent Script's `subagent` block naming. Key changes: - "Topic Selector" → "Subagent Router" in all agent templates and docs - "Topic/action" → "Subagent/action" in documentation - "Topic map" → "Subagent map" in diagram references - Updated all architecture documentation to use "subagent" terminology - Updated 19 .agent template files with new labels and comments - Updated 8 reference documentation files with consistent terminology API contract preservation: - Test spec YAML files preserve "topic" terminology to match Testing Center API - Added clarifying comments explaining topic/subagent equivalence in YAML files - Field names like `expectedTopic` unchanged (Salesforce API requirement) Preserved terms: - "off-topic" (standard phrase for out-of-scope) - "expectedTopic" field (Testing Center API) - "platform topics" (Salesforce guardrail features) 32 files changed, 379 insertions(+), 366 deletions(-) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * Complete comprehensive topic-to-subagent terminology update Thorough update replacing all remaining "topic" references with "subagent" terminology across developing-agentforce, testing-agentforce, and observing-agentforce skills to fully align with Agent Script's `subagent` block naming. Key changes: - Agent Script syntax: @topic.<name> → @subagent.<name> - Agent Script syntax: topic.actions → subagent.actions - Shell script patterns: ^topic → ^subagent - Documentation: "topic instructions" → "subagent instructions" - observing-agentforce skill: Updated all agent architecture references - Template files: Updated all inline comments and descriptions - Variable names in scripts: TOPIC → SUBAGENT Specific updates: - 45 files changed, 294 insertions, 294 deletions - Updated all Agent Script code examples to use @subagent syntax - Updated observing-agentforce issue classification guide - Updated shell script patterns in diagnostic tools - Updated Apex comments to clarify topic field maps to subagents Preserved (as required): - "off-topic" and "off_topic" (standard out-of-scope phrase) - Testing Center API fields: expectedTopic, topic: in YAML - API response fields: .topic, generatedData.topic, topic_assertion - STDM field names: ssot__TopicApiName__c (with clarifying docs) - Template placeholders in test specs (API values) - "Topic hash drift" (API field behavior) - "Email topic/purpose" (means email subject) - Explanatory comments about API field mapping All Agent Script syntax and documentation now consistently uses "subagent" while preserving backward compatibility with platform API field names. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * a few more topic -> subagent replacements --------- Co-authored-by: Steve Hetzel <shetzel@salesforce.com> Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-04-28 02:42:18 +08:00
subagent order_processing:
label: "Order Processing"
description: "Demonstrates advanced input binding patterns"
actions:
# Action with multiple input types
process_order:
description: "Process an order with various input methods"
inputs:
order_id: string
description: "The order ID to process"
amount: number
description: "Transaction amount in USD"
account_id: string
description: "Customer account ID"
outputs:
confirmation_number: string
description: "Order confirmation number"
processed_amount: number
description: "Final processed amount"
target: "flow://Process_Order"
get_account:
description: "Look up account details"
inputs:
account_id: string
description: "Account ID to look up"
outputs:
account_name: string
description: "Account name"
credit_limit: number
description: "Available credit"
target: "flow://Get_Account_Details"
send_notification:
description: "Send order notification"
inputs:
confirmation_number: string
description: "Order confirmation to include"
recipient_account: string
description: "Account to notify"
outputs:
sent: boolean
description: "Whether notification was sent"
target: "flow://Send_Order_Notification"
reasoning:
instructions: ->
| Help the customer process their order.
|
| INPUT BINDING EXAMPLES:
| 1. Slot filling (...) - LLM extracts from conversation
| 2. Fixed values - Always use a constant
| 3. Variable binding - Use stored state
| 4. Output chaining - Use results from previous action
|
| Ask for order details and process appropriately.
actions:
# ★ PATTERN 1: Slot Filling (LLM extracts from conversation)
# User says "Process order ORD-12345" -> LLM fills order_id="ORD-12345"
slot_fill_lookup: @actions.process_order
with order_id=...
with amount=...
with account_id=...
set @variables.order_id = @outputs.confirmation_number
# ★ PATTERN 2: Fixed Value (constant)
# Always uses the same account for default lookups
fixed_account: @actions.get_account
with account_id="001DEFAULT000001"
set @variables.status = @outputs.account_name
# ★ PATTERN 3: Variable Binding (from stored state)
# Uses the account ID saved earlier in the conversation
variable_binding: @actions.get_account
with account_id=@variables.current_account_id
set @variables.status = @outputs.account_name
# ★ PATTERN 4: Output Chaining (from previous action)
# Uses confirmation_number from process_order to send notification
chained_output: @actions.process_order
with order_id=...
with amount=@variables.amount
with account_id=@variables.current_account_id
set @variables.order_id = @outputs.confirmation_number
run @actions.send_notification
with confirmation_number=@outputs.confirmation_number
with recipient_account=@variables.current_account_id
# ★ PATTERN 5: Mixed Binding (combining patterns)
# Some inputs from LLM, some from variables, some fixed
mixed_binding: @actions.process_order
with order_id=... # LLM slot fills
with amount=@variables.amount # From variable
with account_id="001INTERNAL00001" # Fixed value
# ★ Insight: Binding Pattern Decision Tree
#
# Need the LLM to extract from conversation? -> Use `...`
# Value is always the same constant? -> Use "value"
# Value was captured in a previous step? -> Use @variables.x
# Value comes from another action's output? -> Use @outputs.x (in callback)
#
# ★ Common Mistake: Using @outputs.x outside of a `run` callback
# @outputs.x is only available inside the action's callback chain
# Store important outputs in @variables for use elsewhere