Putting an Agentforce agent into production: a 12-point checklist

An Agentforce demo takes a few days. An agent that holds up in front of real customers or employees takes more discipline. This checklist gathers the points that most often separate the two. Use it as a go/no-go review with your platform team, your business owner and your security team.

Before go-live: scope and data

• One job, written down. Describe in two sentences what the agent does, for whom, and what it must never do. Every topic and action should trace back to this.
• Topics that do not overlap. If two topics could answer the same request, the agent will hesitate between them. Merge or sharpen the instructions.
• Grounding data with an owner. List every source the agent answers from: knowledge articles, Data 360 objects, external systems. Give each one an owner and an update rule.
• No sensitive data it does not need. Remove fields and objects the agent has no reason to read. What it cannot read, it cannot leak.

Before go-live: permissions and tests

• Least privilege for the agent user. Check what the agent can read and, above all, what records its actions can create or change. Separate read-only actions from actions that write.
• A written test set. At least a few dozen realistic requests, including off-topic ones, ambiguous ones and attempts to make the agent ignore its instructions. Record the expected behaviour for each.
• Results kept as evidence. Save the test results with the date and the version tested. You will replay them after every change.

On go-live day

• A clear handover to a human. Define when the agent hands over (sensitive topics, low confidence, explicit request) and check that the service agent receives the conversation history.
• Transparency notice. Tell users they are talking to an AI, in the conversation itself. In the EU this is required by Article 50 of the AI Act since 2 August 2026.
• A cost baseline. Note the expected volume and estimate the consumption per conversation, so that the first invoice is not the first measurement.

In the first weeks

• A named owner. One person who reads conversation samples every week, follows the indicators and approves changes.
• A change log. Every change to instructions, topics, actions or data sources, with the date, the reason and who approved it.

Common mistakes

• Launching to all users at once instead of a pilot group.
• Treating the Einstein Trust Layer as the whole security design: it protects the exchange with the model, not the permissions you give the agent.
• Measuring success by the number of conversations instead of the share of requests actually resolved.
• Forgetting the agent after go-live: knowledge ages, and each Salesforce release can change behaviour.