mirror of
https://github.com/forcedotcom/afv-library.git
synced 2026-07-30 11:43:26 +08:00
* @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>
179 lines
6.5 KiB
Plaintext
179 lines
6.5 KiB
Plaintext
# Action Callbacks Pattern
|
|
# Use the `run` keyword for deterministic post-action processing
|
|
#
|
|
# ★ When To Use This Pattern:
|
|
# - You need guaranteed follow-up after an action completes
|
|
# - Audit logging or notifications must ALWAYS happen
|
|
# - Chain multiple actions where order matters
|
|
#
|
|
# ★ Key Insight:
|
|
# The `run` keyword executes AFTER the parent action completes.
|
|
# This is deterministic (not LLM-decided) - the callback ALWAYS runs.
|
|
# Use this when you can't afford to skip follow-up steps.
|
|
#
|
|
# ★ Validation Impact:
|
|
# - [5 pts] Actions with proper callback structure
|
|
# - Avoid nested run (only 1 level of nesting allowed)
|
|
#
|
|
# This is a PARTIAL template - integrate into a complete agent file
|
|
|
|
subagent order_processing:
|
|
label: "Order Processing"
|
|
description: "Processes orders with guaranteed confirmation and logging"
|
|
|
|
actions:
|
|
create_order:
|
|
description: "Creates a new order in the system"
|
|
inputs:
|
|
customer_id: string
|
|
description: "Customer identifier"
|
|
items: list[string]
|
|
description: "List of item SKUs"
|
|
total: number
|
|
description: "Order total amount"
|
|
outputs:
|
|
order_id: string
|
|
description: "Generated order ID"
|
|
status: string
|
|
description: "Order creation status"
|
|
target: "flow://Create_Order"
|
|
|
|
send_confirmation:
|
|
description: "Sends order confirmation email"
|
|
inputs:
|
|
order_id: string
|
|
description: "Order ID to confirm"
|
|
customer_email: string
|
|
description: "Customer email address"
|
|
outputs:
|
|
sent: boolean
|
|
description: "Whether email was sent"
|
|
target: "flow://Send_Order_Confirmation"
|
|
|
|
log_activity:
|
|
description: "Logs activity for audit trail"
|
|
inputs:
|
|
event_type: string
|
|
description: "Type of event to log"
|
|
details: string
|
|
description: "Event details"
|
|
outputs:
|
|
logged: boolean
|
|
description: "Whether log was recorded"
|
|
target: "apex://AuditService.logEvent"
|
|
|
|
reasoning:
|
|
instructions: ->
|
|
| Help the customer place their order.
|
|
| Ensure confirmation is sent after successful orders.
|
|
| All order activities must be logged for compliance.
|
|
actions:
|
|
# This action uses callbacks to guarantee follow-up
|
|
process_order: @actions.create_order
|
|
with customer_id=@variables.customer_id
|
|
with items=...
|
|
with total=...
|
|
set @variables.order_id = @outputs.order_id
|
|
set @variables.order_status = @outputs.status
|
|
# Callback 1: Always send confirmation after order created
|
|
run @actions.send_confirmation
|
|
with order_id=@variables.order_id
|
|
with customer_email=@variables.customer_email
|
|
# Callback 2: Always log the activity
|
|
run @actions.log_activity
|
|
with event_type="ORDER_CREATED"
|
|
with details=@variables.order_id
|
|
|
|
back_to_menu: @utils.transition to @subagent.agent_router
|
|
|
|
# ★ Anti-Pattern: Nested run (DO NOT DO THIS)
|
|
#
|
|
# process: @actions.first
|
|
# run @actions.second
|
|
# run @actions.third # ❌ INVALID - nested run not allowed
|
|
#
|
|
# ★ Correct Pattern: Sequential callbacks (all at same level)
|
|
#
|
|
# process: @actions.first
|
|
# run @actions.second # ✅ First callback
|
|
# run @actions.third # ✅ Second callback (runs after second)
|
|
|
|
# ═══════════════════════════════════════════════════════════════════════════════
|
|
# ★ Pattern 2: Simple Variable Updates (No Callback Needed)
|
|
# ═══════════════════════════════════════════════════════════════════════════════
|
|
#
|
|
# For simple operations like incrementing counters or storing outputs,
|
|
# use `set` statements directly - NO `run` keyword needed.
|
|
#
|
|
# ⚠️ IMPORTANT: This pattern works in BOTH GenAiPlannerBundle AND AiAuthoringBundle
|
|
# The `run` keyword ONLY works in GenAiPlannerBundle (not AiAuthoringBundle)
|
|
# Use `set` statements for AiAuthoringBundle deployments
|
|
#
|
|
# Example: Create case and track count (works in BOTH bundle types)
|
|
|
|
subagent case_management:
|
|
label: "Case Management"
|
|
description: "Creates cases and tracks statistics"
|
|
|
|
actions:
|
|
create_case:
|
|
description: "Creates a new support case"
|
|
inputs:
|
|
inp_CustomerId: string
|
|
description: "Contact ID for the case"
|
|
inp_Subject: string
|
|
description: "Subject line for the case"
|
|
outputs:
|
|
out_CaseNumber: string
|
|
description: "Generated case number"
|
|
out_CaseId: string
|
|
description: "Salesforce ID of the created case"
|
|
target: "flow://Create_Case"
|
|
|
|
reasoning:
|
|
instructions: ->
|
|
| Help the customer create support cases.
|
|
| Track case count for session statistics.
|
|
actions:
|
|
# ✅ Simple pattern - just use `set` for variable updates
|
|
create_support_case: @actions.create_case
|
|
with inp_CustomerId=@variables.ContactId
|
|
with inp_Subject=...
|
|
set @variables.case_number = @outputs.out_CaseNumber
|
|
set @variables.case_id = @outputs.out_CaseId
|
|
set @variables.cases_created = @variables.cases_created + 1 # Direct increment!
|
|
|
|
back_to_menu: @utils.transition to @subagent.agent_router
|
|
|
|
# ═══════════════════════════════════════════════════════════════════════════════
|
|
# ⛔ INVALID KEYWORDS - NEVER USE THESE
|
|
# ═══════════════════════════════════════════════════════════════════════════════
|
|
#
|
|
# The following keywords DO NOT EXIST in Agent Script. Using them causes:
|
|
# SyntaxError: Unexpected '[keyword]'
|
|
#
|
|
# ❌ internal_actions - Does not exist (Claude may invent this for "local helpers")
|
|
# ❌ helper_actions - Does not exist
|
|
# ❌ private_actions - Does not exist
|
|
# ❌ local_actions - Does not exist
|
|
#
|
|
# If you need simple variable operations after an action, use `set` directly:
|
|
#
|
|
# ❌ WRONG (internal_actions does not exist):
|
|
#
|
|
# internal_actions:
|
|
# increment_counter:
|
|
# set @variables.count = @variables.count + 1
|
|
#
|
|
# reasoning:
|
|
# actions:
|
|
# process: @actions.create_case
|
|
# run @actions.increment_counter # ❌ Can't reference internal action
|
|
#
|
|
# ✅ CORRECT (use set directly in the action block):
|
|
#
|
|
# reasoning:
|
|
# actions:
|
|
# process: @actions.create_case
|
|
# set @variables.count = @variables.count + 1 # ✅ Direct set works!
|