afv-library/skills/developing-agentforce/assets/patterns/llm-controlled-actions.agent
Willie Ruemmele 261abd679a
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-27 12:42:18 -06:00

185 lines
5.9 KiB
Plaintext

# LLM-Controlled Actions Pattern
# Demonstrates both deterministic and LLM-controlled action invocation
#
# ★ When To Use This Pattern:
# - When the LLM should decide which actions to invoke based on context
# - When actions should only be available under certain conditions
# - When you want the agent to make intelligent choices about tool usage
#
# ★ Key Insight:
# - Deterministic: "run @actions.x" - ALWAYS runs when code path is reached
# - LLM-Controlled: "{!@actions.x}" in instructions - LLM decides based on context
# - Tools in reasoning.actions - LLM chooses which to invoke
#
# ★ Two Invocation Methods:
# 1. Deterministic (run @actions.x): Use in before/after_reasoning, action callbacks
# 2. LLM-Controlled ({!@actions.x}): Reference in reasoning instructions
#
# This is a PARTIAL template - integrate into a complete agent file
# Variables for tracking action context
variables:
# ... standard linked variables ...
has_order_id: mutable boolean = False
description: "Whether user has provided an order ID"
order_id: mutable string
description: "The order ID provided by user"
action_taken: mutable string
description: "Last action taken by agent"
subagent order_assistance:
label: "Order Assistance"
description: "Helps customers with order-related questions"
# Define available actions
actions:
get_order_status:
description: "Retrieves order status by order ID"
inputs:
order_id: string
description: "The order ID to look up"
outputs:
status: string
description: "Current order status"
delivery_date: string
description: "Expected delivery date"
target: "flow://Get_Order_Status"
update_order:
description: "Updates an existing order"
require_user_confirmation: True # ★ Ask user before executing
inputs:
order_id: string
description: "Order to update"
changes: string
description: "Changes to make"
outputs:
success: boolean
description: "Whether update succeeded"
target: "flow://Update_Order"
cancel_order:
description: "Cancels an order"
require_user_confirmation: True # ★ Destructive action - confirm first
include_in_progress_indicator: True
inputs:
order_id: string
description: "Order to cancel"
reason: string
description: "Cancellation reason"
outputs:
refund_amount: number
description: "Refund amount"
filter_from_agent: False # Show this to LLM
target: "flow://Cancel_Order"
log_interaction:
description: "Logs customer interaction for analytics"
inputs:
interaction_type: string
description: "Type of interaction"
outputs:
logged: boolean
description: "Whether log succeeded"
target: "flow://Log_Interaction"
# ★ Deterministic logging before reasoning
before_reasoning:
run @actions.log_interaction
with interaction_type="order_inquiry"
reasoning:
# ★ LLM-Controlled: Reference actions in natural language
# The LLM decides when to use these based on conversation context
instructions: ->
| Help the customer with their order inquiry.
|
| Available capabilities:
| - Use {!@actions.get_order_status} to look up order details when they provide an order ID
| - Use {!@actions.update_order} if they want to modify their order (requires confirmation)
| - Use {!@actions.cancel_order} if they want to cancel (requires confirmation)
|
| Always confirm destructive actions before proceeding.
| If they haven't provided an order ID, ask for it first.
# ★ Tools: LLM chooses which to invoke based on conversation
actions:
# Slot filling - LLM extracts order_id from conversation
lookup: @actions.get_order_status
with order_id=...
set @variables.order_id = @outputs.status
# Conditional availability - only show when order ID is known
update: @actions.update_order
with order_id=@variables.order_id
with changes=...
available when @variables.has_order_id == True
# Conditional availability with multiple conditions
cancel: @actions.cancel_order
with order_id=@variables.order_id
with reason=...
available when @variables.has_order_id == True
available when @variables.order_status != "shipped"
# Subagent transitions
go_help: @utils.transition to @subagent.general_help
go_escalation: @utils.transition to @subagent.escalation
available when @variables.needs_human == True
# ★ Insight: When to Use Each Method
#
# DETERMINISTIC (run @actions.x):
# - Audit logging (must always run)
# - Required follow-up actions
# - Guaranteed side effects
# - In before_reasoning / after_reasoning blocks
# - In action callbacks (run after parent)
#
# LLM-CONTROLLED (reasoning.actions or {!@actions.x}):
# - User-driven choices
# - Context-dependent operations
# - Optional actions based on conversation
# - When intelligence is needed to decide
#
# CONDITIONAL (available when):
# - Guard destructive operations
# - Show options only when prerequisites met
# - Enforce business rules
# ★ Example: Action Callback Pattern (Deterministic Chaining)
# Use "run" for guaranteed follow-up actions after a primary action
subagent checkout:
label: "Checkout"
description: "Handles order checkout"
actions:
create_order:
description: "Creates a new order"
inputs:
items: list[string]
description: "Items to order"
outputs:
order_id: string
description: "Created order ID"
target: "flow://Create_Order"
send_confirmation:
description: "Sends order confirmation email"
inputs:
order_id: string
description: "Order to confirm"
target: "flow://Send_Confirmation"
reasoning:
instructions: ->
| Process the customer's checkout request.
actions:
# ★ Action callback: send_confirmation ALWAYS runs after create_order
process_checkout: @actions.create_order
with items=...
set @variables.order_id = @outputs.order_id
run @actions.send_confirmation # ★ Guaranteed to run
with order_id=@variables.order_id