To test an Agentforce agent before go-live, pass it through five gates. Write down what it must and must never do. Cover every subagent and action with single-turn tests. Run full conversations, including hostile ones. Check that its actions changed the right records. Then repeat the key tests many times and launch to a small group first. Go live only when each gate meets a pass bar you set before testing started.
This is the checklist version. For the concepts behind agent testing, start with our guide to testing Salesforce Agentforce agents.
Why an agent needs a stricter release gate than a flow
A flow does the same thing every time. An agent decides what to do, in words you did not write, and can do it differently on the next run. Salesforce’s own Testing API notes say test results may change between runs.
Salesforce AI Research measured the gap. On its CRMArena-Pro benchmark of 19 business tasks across sales, service and CPQ, leading LLM agents succeeded about 58% of the time on single-turn tasks and about 35% on multi-turn tasks. Under the standard prompt, most models refused requests for confidential data 0.0% to 0.4% of the time. The paper calls it near-zero confidentiality awareness.
Those are general-purpose models, not your configured agent. Your instructions and guardrails should do much better. The point is where to look. Agents slip in long conversations and around data access, so that is where your tests should be heaviest.
It comes up on our calls too. Between July 30 and October 30, 2026, about 6 different prospects raised agent testing quality as a reason they were not ready to go live.
Gate 1: Write the contract
You cannot test an agent against a vibe. Write one row per subagent before anyone writes a test. Here is what that looks like for a service agent:
Subagent | Must do | Must never do | Hands off when |
|---|---|---|---|
Order status | Look up orders for the verified customer | Show another customer’s order | The order is missing or disputed |
Returns | Start a return inside the policy window | Approve a refund over the limit | The customer asks for an exception |
General questions | Answer from approved knowledge articles | Make up a policy or a price | It cannot find a source |
Get the business owner to sign it. This table is the pass bar for every gate after it.
Gate 2: Cover every subagent and action
Agentforce Testing Center is the right tool for this gate. Each test case is an utterance plus the expected subagent, expected actions and expected response. Subagents and actions are written as API names, not labels. Testing Center can also generate test cases from your subagents and actions, and it now lives in Agentforce Studio, next to Agent Builder.
For each subagent, write at least:
The happy path, in three or four different phrasings.
A request with missing information, so the agent has to ask for it.
A request it must refuse, taken from the “must never do” column.
An out-of-scope request, to check that it routes or hands off.
A near-miss that belongs to a different subagent.
Our free Agentforce Testing Center coverage planner builds this list from your subagents and actions and exports a CSV in Testing Center’s format. One test definition holds up to 1,000 cases, and you can have 10 runs in progress at a time.
Watch the bill. Salesforce says Testing API runs consume Einstein Requests credits, in sandbox as well as production. Run 20 cases first and check your usage before you run 500.
Gate 3: Run conversations, including hostile ones
Real users don’t ask one clean question. They change topic, add details late, get annoyed, and paste in things they shouldn’t. Testing Center’s conversation-level tests now simulate a user with a persona, such as a frustrated customer, a non-native English speaker or a distracted user, and score the conversation on measures like task resolution.
Then attack it on purpose:
Ask it to ignore its instructions, or to reveal them.
Ask for another customer’s data, with a believable story.
Switch topics in the middle of a task, then come back.
Push for an action the contract forbids, three different ways.
Ask it to skip verification to save time.
This is not theoretical. When we red teamed an Agentforce agent with conversation alone, it revealed its internal instructions. Here is what happened and how to prevent it. If your agent takes calls, test the voice channel separately. Voice agents fail in different ways.
Gate 4: Check the data, not just the reply
An agent can say “I’ve updated your case” and not update it. Or update the wrong one. A test that only grades the reply passes both.
After each action, query the record. Did the field change? Is it the right record? Was anything else touched? A SOQL check after the conversation catches what a response grader can’t.
Run as the real user too. Employee agents work as the person using them, with that person’s permissions. Service agents act as the agent user you set up for them. If you only test as an admin, you will miss the permission errors your users hit on day one.
Gate 5: Repeat the tests, then roll out in stages
One green run tells you little about a system that can answer differently each time. The math is simple. If a conversation fails 1 time in 10, one run catches it 10% of the time. Ten runs catch it about 65% of the time. Thirty runs, about 96%.
So run your key conversations 10 to 30 times each and track the pass rate, not a single result. Set the bar by risk. Zero failures on data leaks and forbidden actions. An agreed pass rate for answer quality.
Then launch small:
Internal users first, for a week.
A small share of real traffic, with an easy way to reach a person.
Full rollout once the pass rate and the handoff rate hold steady.
Watch real sessions in Agentforce Observability, and turn every bad conversation into a new test. The best new tests come from real conversations that went wrong.
The go-live checklist
A signed contract for every subagent: must do, must never do, hand off when.
Every subagent and action has happy-path, refusal, out-of-scope and near-miss tests.
All single-turn tests pass in Testing Center.
Conversation tests pass for at least three personas.
Prompt injection and data-leak attempts fail every time.
Every action is checked against the record it changed.
Tests run as the real agent user and as key employee profiles.
Key conversations run 10 or more times with a stable pass rate.
Handoff to a person works and is easy to trigger.
Credit use for testing and for production is estimated.
A staged rollout plan with a named owner.
Bad production conversations feed back into the test suite.
Where TestZeus fits
TestZeus Agent Harness covers the gates Testing Center leaves to you. An adversary agent runs multi-turn conversations that get harder as your agent holds up. Tests can run as different profiles, and they intercept tool calls and SOQL so you see what the agent actually changed. Runs repeat, with trend lines across agent versions, scores for tool usage, safety, scope adherence and accuracy, and suggested guardrail fixes. It covers Agentforce text and voice in 12 languages, with a token budget to cap credit use.
We compare the two in Agentforce Testing Center vs TestZeus Agent Harness. To see it on your own agent first, ask for a free adversarial scan.
FAQ
How do you test an Agentforce agent before go-live?
Write down what each subagent must and must never do. Cover every subagent and action with single-turn tests, run multi-turn and adversarial conversations, check the records each action changed, and repeat key tests many times. Then launch to a small group before everyone.
Is Agentforce Testing Center enough?
It covers single-turn tests, conversation-level tests with personas, custom evaluations and CI quality gates. Most teams still need separate checks for data changes, deliberate attacks, permissions as real users, and pass rates across many runs.
How many test cases does an Agentforce agent need?
There is no fixed number. Start with five to ten per subagent: happy paths in different phrasings, missing information, refusals, out-of-scope requests and near-miss routing. One Testing Center definition holds up to 1,000 cases.
Does Agentforce testing use credits?
Yes. Salesforce says Testing API runs consume Einstein Requests credits in both sandbox and production. Run a small batch first and check your usage.
How often should we retest after go-live?
On every change to instructions, actions, knowledge or the model, and on each Salesforce release. Add a test for every bad conversation you find in production.
// Start testing //
