The `Agent` pseudo metadata type is a convenience wrapper that retrieves or deploys all agent-related components at once.
### Using the Agent Pseudo Type
```bash
# Retrieve agent + all dependencies from org
sf project retrieve start --metadata Agent:[AgentName] --target-org [alias]
# Deploy agent metadata to org
sf project deploy start --metadata Agent:[AgentName] --target-org [alias]
```
### What Gets Synced
When using `--metadata Agent:[Name]`:
**Retrieved/Deployed:**
-`Bot` - Top-level chatbot
-`BotVersion` - Version configuration
-`GenAiPlannerBundle` - Reasoning engine
-`GenAiPlugin` - All topics
-`GenAiFunction` - All actions
**NOT Included:**
- Apex classes (deploy separately)
- Flows (deploy separately)
- Named Credentials (deploy separately)
---
## Sync Operations
### Retrieving Agents from Org
```bash
# Retrieve agent using pseudo metadata type
sf project retrieve start --metadata Agent:Customer_Support_Agent --target-org myorg
# Retrieve to specific output directory
sf project retrieve start --metadata Agent:Customer_Support_Agent --output-dir ./retrieved --target-org myorg
# Retrieve multiple agents
sf project retrieve start --metadata Agent:Support_Agent,Agent:Sales_Agent --target-org myorg
```
### Retrieving Specific Components
```bash
# Retrieve just the bot definition
sf project retrieve start --metadata Bot:Customer_Support_Agent --target-org myorg
# Retrieve a specific BotVersion along with the bot definition
sf project retrieve start \
--metadata Bot:Customer_Support_Agent \
--metadata BotVersion:Customer_Support_Agent.v3 \
--target-org myorg
# Retrieve just the planner bundle
sf project retrieve start --metadata GenAiPlannerBundle:Customer_Support_Agent_Planner --target-org myorg
# Retrieve all plugins (topics)
sf project retrieve start --metadata GenAiPlugin --target-org myorg
# Retrieve all functions (actions)
sf project retrieve start --metadata GenAiFunction --target-org myorg
```
> **Versioned retrieve note:** Current SF CLI releases correctly retrieve the specific `BotVersion` you request instead of always pulling only the latest version.
### Deploying Agents to Org
```bash
# Deploy agent using pseudo metadata type
sf project deploy start --metadata Agent:Customer_Support_Agent --target-org myorg
# Deploy with validation only (dry run)
sf project deploy start --metadata Agent:Customer_Support_Agent --dry-run --target-org myorg
# Deploy multiple agents
sf project deploy start --metadata Agent:Support_Agent,Agent:Sales_Agent --target-org myorg
```
---
## Agent Lifecycle Management
### Activate Agent
Makes an agent available to users.
```bash
# Manual activation
sf agent activate --api-name [AgentName] --target-org [alias]
# CI / deterministic activation of a known BotVersion
sf agent activate --api-name [AgentName] --version [N] --target-org [alias] --json
```
**Requirements:**
- Agent must be published first (`sf agent publish authoring-bundle`)
- All Apex classes and Flows must be deployed
-`default_agent_user` must be a valid org user with Agentforce permissions
**Activation notes:**
-`--version [N]` maps to the `vN` suffix in `BotVersion` metadata
- Omitting `--version` triggers interactive version selection
- Using `--json` without `--version` activates the latest agent version
- For CI/CD and reproducible rollouts, prefer `--version [N] --json`
**Post-Activation:**
- Agent is immediately available to users
- Preview command can be used for testing
- Changes require deactivation first
### Deactivate Agent
Deactivates an agent for modifications. **Required before making changes.**
```bash
# Manual deactivation
sf agent deactivate --api-name [AgentName] --target-org [alias]
# Script-friendly deactivation
sf agent deactivate --api-name [AgentName] --target-org [alias] --json
```
**When Deactivation is Required:**
- Adding or removing topics
- Modifying action configurations
- Changing system instructions
- Updating variable definitions
### Modification Workflow
```bash
# 1. Deactivate agent
sf agent deactivate --api-name Customer_Support_Agent --target-org myorg
# 2. Make changes to Agent Script
# 3. Re-publish
sf agent publish authoring-bundle --api-name Customer_Support_Agent --target-org myorg
# 4. Re-activate
sf agent activate --api-name Customer_Support_Agent --target-org myorg
```
---
## Agent Preview
Preview allows testing agent behavior before production deployment.
> **Note**: `EinsteinAgentApiChannel` surfaceType is NOT available on all orgs. Use `CustomerWebClient` instead — it enables both Agent Builder Preview and Agent Runtime API access.
> **⚠️ Agent Script agents**: `connection messaging:` in the `.agent` DSL ONLY generates a `Messaging` plannerSurface — `CustomerWebClient` is never auto-generated. You must manually patch it after EVERY `sf agent publish authoring-bundle`. See the post-publish workflow in `agentforce-generate`.
### Fix: Add plannerSurfaces when agent is active
If the agent is active, you must deactivate before deploying:
```bash
# Deactivate → Deploy → Activate
sf agent deactivate --api-name AgentName -o TARGET_ORG --json
sf project deploy start --metadata "GenAiPlannerBundle:AgentName_vNN" -o TARGET_ORG --json
sf agent activate --api-name AgentName --version NN -o TARGET_ORG --json
```
Use the same `NN` value from the planner bundle version you just patched so activation is deterministic.
sf project deploy start --metadata GenAiPlannerBundle,BotVersion --target-org myorg
```
> **Why this matters**: Without `CustomerWebClient` plannerSurface, the Agent Builder Preview shows "Something went wrong" and the Agent Runtime API returns `500 UNKNOWN_EXCEPTION` on session creation.
---
## ISV Packaging (BotTemplate)
Use `sf agent generate template` to package an agent for distribution via managed packages on AppExchange.