Foothill Veterinary Alliance built and tested a new referral-booking agent entirely in a sandbox. When the specialist deploys it to production, what generally must move along with the agent itself for it to function correctly?
Select an answer to reveal the explanation.
Short Explanation
An agent doesn't travel alone. It's more like a chef moving kitchens: the recipe (agent) is useless without the ingredients and equipment (topics, actions, flows, prompt templates, permission sets) coming along too.
Full Explanation
Deploying an Agentforce agent from sandbox to production requires its dependent metadata to move with it: the topics it uses, the standard and custom actions those topics invoke, any flows or prompt templates those actions call, and the permission sets that govern what the Agent User and human users can see and do. Without those dependencies present and correctly configured in production, the deployed agent will reference components that either do not exist there or behave differently. Assuming only the display name needs to move ignores that the agent's actual behavior lives in its topics, actions, and instructions, none of which travel automatically with a name. Inventing a special Agent User license type is not a real deployment mechanic; the Agent User uses the standard Salesforce licensing and permission-set model like any other user. Assuming sandbox and production orgs share configuration automatically and in real time is false — they are separate orgs, and metadata must be explicitly deployed (for example via change sets or another deployment mechanism) for it to exist and match on the other side.