afv-library/skills/developing-agentforce/references/deploy-reference.md
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

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