* @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>
4.8 KiB
Deploy -- Bundle Publication Reference
Extracted from SKILL.md Section 18. This file is loaded on demand when deployment details are needed.
Overview
Full deployment lifecycle for Agentforce agents: validate, deploy metadata, publish bundle, and activate.
Usage
# Validate + publish
sf agent publish authoring-bundle --json --api-name MyAgent -o <org-alias>
# Activate after publish
sf agent activate --json --api-name MyAgent -o <org-alias>
Deployment Phases
Phase 0: Safety Gate (Required)
Read the .agent file and run safety review (see safety-review-reference.md). If any BLOCK finding exists, STOP deployment. WARN findings must be reported and acknowledged by the user before proceeding.
Phase 1: Pre-Deployment Validation
sf agent validate authoring-bundle --json --api-name MyAgent -o <org-alias>
Phase 1b: Target Dependency Check
Verify all flow/apex targets exist in the org before publishing. If missing, scaffold and deploy them first.
Phase 2: Deploy Supporting Metadata
sf project deploy start --json --source-dir force-app -o <org-alias>
Phase 3: Publish Agent Bundle
sf agent publish authoring-bundle --json --api-name MyAgent -o <org-alias>
4-step process: Validate (~1-2s) -> Publish (~8-10s) -> Retrieve (~5-7s) -> Deploy (~4-6s)
Phase 4: Activate Agent
sf agent activate --json --api-name MyAgent -o <org-alias>
Note: sf agent activate may not support --json in all CLI versions. If it returns plain text, check for "successfully activated" in the output.
Publishing creates an inactive version. Without activation, preview fails with "No valid version available".
Deploy vs Publish
| What changes | sf project deploy start |
sf agent publish authoring-bundle |
|---|---|---|
| Bundle metadata | Yes | Yes |
system: instructions: |
Yes (via activate) | Yes |
reasoning: actions: (transitions + invocations) |
NO | Yes |
Always prefer sf agent publish authoring-bundle. If you change reasoning: actions:, publish is required.
Common Errors
| Error | Cause | Fix |
|---|---|---|
Required fields missing: [BundleType] |
Extra fields in bundle-meta.xml | Use minimal: only <bundleType>AGENT</bundleType> |
Internal Error, try again later |
Invalid default_agent_user or new agent platform bug | Query Einstein Agent Users; for new agents, create shell in Setup UI first |
Duplicate value found: GenAiPluginDefinition |
start_agent and subagent share name |
Use different names |
Flow not found |
Metadata not deployed | Deploy flows before publishing |
SetupEntityType is not supported for DML |
PermissionSet via Apex DML | Use Metadata API (sf project deploy start) |
Rollback
sf agent deactivate --json --api-name MyAgent -o <org>
sf data query --json --query "SELECT Id, VersionNumber FROM BotVersion WHERE BotDefinition.DeveloperName = 'MyAgent' ORDER BY VersionNumber DESC LIMIT 2" -o <org>
sf agent activate --json --api-name MyAgent --version-number <previous> -o <org>
CI/CD Integration
name: Deploy Agentforce Agent
on:
push:
branches: [main]
paths: ['force-app/**']
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install SF CLI
run: npm install -g @salesforce/cli
- name: Auth
run: |
echo "${{ secrets.SFDX_AUTH_URL }}" > auth.txt
sf org login sfdx-url --sfdx-url-file auth.txt --alias production
- name: Validate
run: sf agent validate authoring-bundle --json --api-name ${{ vars.AGENT_NAME }} -o production
- name: Deploy Metadata
run: sf project deploy start --json --source-dir force-app -o production
- name: Publish
run: sf agent publish authoring-bundle --json --api-name ${{ vars.AGENT_NAME }} -o production
- name: Activate
if: github.ref == 'refs/heads/main'
run: sf agent activate --json --api-name ${{ vars.AGENT_NAME }} -o production
Pre-Deployment Checklist
- All action targets exist in org (run discover first)
- Agent Script validated (no syntax errors)
- Einstein Agent User configured correctly
- Supporting metadata deployed
- Previous version backed up
- Rollback plan documented
Post-Deployment Testing
sf agent preview start --json --use-live-actions --authoring-bundle MyAgent -o <org>
# Read sessionId from the JSON response, then:
sf agent preview send --json --authoring-bundle MyAgent --session-id <SESSION_ID> -u "Hello, I need help" -o <org>
sf agent preview end --json --authoring-bundle MyAgent --session-id <SESSION_ID> -o <org>
Exit Codes
| Code | Meaning |
|---|---|
| 0 | Success |
| 1 | Validation/deployment failed |
| 2 | Critical failure |