* @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>
5.5 KiB
Prompt Template Actions
Invoking Salesforce Prompt Templates as actions within Agent Script.
Overview
Prompt Template Actions let agents invoke Salesforce Prompt Templates via the generatePromptResponse:// protocol. The agent passes structured inputs to the template and receives a generated promptResponse output — keeping content generation in the template while the agent manages conversation flow.
When to use: Personalized responses, summarization, content generation, recommendations — anything where an LLM prompt template produces better output than static Flow logic.
Action Definition (Agentforce Assets)
Define the action in Setup > Agentforce > Action Definitions (or via metadata API):
actions:
Generate_Personalized_Schedule:
description: "Generate a personalized schedule using a prompt template"
inputs:
"Input:email": string
description: "User's email address"
is_required: True
"Input:preferences": string
description: "User's scheduling preferences"
is_required: False
outputs:
promptResponse: string
description: "The personalized schedule generated by the template"
is_used_by_planner: True
target: "generatePromptResponse://Generate_Personalized_Schedule"
Critical syntax rules
| Rule | Example |
|---|---|
| Target protocol | "generatePromptResponse://TemplateName" |
| Input names must be quoted | "Input:email" not Input:email |
Input prefix is Input: |
Matches the template's input field API name |
Output field is always promptResponse |
Single string output from the template |
Agent Script Invocation
Reference the action definition in your .agent file:
subagent schedule_generation:
reasoning:
actions:
generate_schedule: @actions.Generate_Personalized_Schedule
with "Input:email"=@variables.user_email
"Input:preferences"=...
set @variables.schedule = @outputs.promptResponse
Input binding patterns (same as regular actions):
@variables.user_email— variable binding (data from prior turns)...— LLM slot-filling (extract from conversation)"professional"— fixed value (business rule constant)
Grounded Data Integration
Templates can include data providers (Apex classes, Flows) that supply contextual data for personalized responses. The grounding happens inside the template — Agent Script only needs to pass the lookup key:
actions:
Get_Product_Recommendations:
description: "Generate personalized product recommendations based on purchase history"
inputs:
"Input:customerId": string
description: "Customer ID for personalization"
is_required: True
outputs:
promptResponse: string
description: "Personalized recommendations grounded in customer data"
target: "generatePromptResponse://Product_Recommender"
The template itself (configured in Prompt Builder) includes:
- Data Provider: Apex class fetching customer purchase history
- Grounding: Recent orders, preferences, browsing history
- Template instructions: How to format recommendations using the grounded data
Common Patterns
Pattern 1: Content Generation
generate_email: @actions.Generate_Email_Response
with "Input:customerMessage"=@variables.user_message
"Input:tone"="professional"
"Input:context"=@variables.case_context
set @variables.email_draft = @outputs.promptResponse
Pattern 2: Summarization
summarize: @actions.Summarize_Conversation
with "Input:conversationHistory"=@variables.chat_history
"Input:maxLength"="500"
set @variables.summary = @outputs.promptResponse
Pattern 3: Personalized Recommendations
recommend: @actions.Get_Product_Recommendations
with "Input:customerId"=@variables.customer_id
"Input:category"=...
set @variables.recommendations = @outputs.promptResponse
Known Limitation: run Keyword with Prompt Templates
Chained actions using run may not properly map "Input:X" parameters:
# ❌ MAY NOT WORK — run + prompt template input binding:
process: @actions.create_order
with customer_id=@variables.customer_id
run @actions.Generate_Order_Summary
with "Input:orderId"=@variables.order_id # Input binding may fail
# ✅ WORKAROUND — call as primary action instead:
generate_summary: @actions.Generate_Order_Summary
with "Input:orderId"=@variables.order_id # Works as primary action
set @variables.summary = @outputs.promptResponse
Common Errors
| Error | Cause | Fix |
|---|---|---|
SyntaxError on input binding |
Missing quotes on parameter name | Use "Input:email" not Input:email |
| Template not found | Wrong protocol or template name | Verify generatePromptResponse://ExactTemplateName |
Empty promptResponse |
Template inactive or missing required inputs | Activate template in Setup, check all is_required: True inputs are bound |
| Input not mapped | API name mismatch | Input field name after Input: must exactly match template's input API name |
Checklist
- Template exists in org and is active
- Input field API names match template configuration exactly
- All
is_required: Trueinputs are bound (via...,@variables, or fixed) promptResponseoutput is captured withset- Template response quality tested with representative inputs
- If using grounded data: data provider returns expected records