Agentforce & AI

An Agentforce pass rate is meaningless without a risk model

JSBC Labs15 September 20268 min read

A high score can approve the wrong agent

A team runs 500 Agentforce tests, reports a 94% pass rate and approves production. That number sounds reassuring until the failed 6% includes disclosing restricted data, taking an action for an unverified user or promising a refund outside policy. Meanwhile, hundreds of harmless phrasing tests inflate the average. The test suite has measured volume, not readiness.

Agent responses are non-deterministic and context-sensitive, so traditional exact-output testing is insufficient. But replacing exact assertions with a single AI-generated quality score is not enough either. Readiness depends on what the agent was allowed to do, which decisions carried risk and whether failure was safely contained. The risk model must come before the metric.

Define harm before writing test prompts

Start with the agent's business authority. List the decisions it can influence, the data it can disclose, the actions it can execute and the people affected. For each capability, describe credible harm: privacy exposure, financial loss, incorrect entitlement, missed escalation, discriminatory treatment, regulatory breach or a poor but recoverable customer experience.

Classify each scenario by severity and reversibility. A slightly verbose answer should not carry the same weight as changing a delivery address without verification. Define zero-tolerance conditions that block release regardless of the aggregate score, then set thresholds for lower-risk quality measures. This is JSBC Labs analysis, not a product limit: an enterprise needs a release decision model that reflects its obligations, not the convenience of one dashboard percentage.

Test the decision chain, not only the final prose

Salesforce Testing Center can evaluate topic classification, action sequences, response quality, instruction adherence, citations and latency. Those layers matter because a polished final response can conceal an unsafe route. The agent may select the wrong topic, call an unnecessary action, pass malformed inputs or change data correctly for the wrong customer.

Create assertions at every important boundary: selected topic or subagent, action name, validated arguments, execution identity, record state before and after, response claims, escalation outcome and latency budget. Use deterministic checks where the expected state is exact. Use scored evaluations for language qualities such as clarity, completeness or tone. Never let a good LLM-judge score override a failed permission, identity or data-integrity assertion.

Build a portfolio, not a pile, of test cases

Organise the suite by risk and user journey. Include ordinary successful requests, ambiguous language, missing information, out-of-scope requests, denied actions, stale knowledge, conflicting instructions, prompt injection, repeated requests and downstream failure. Add the regional language, vocabulary and accessibility patterns used by the real audience rather than testing only polished internal English.

Give each case a purpose, risk class, expected behaviour and owner. Remove duplicates that add volume without coverage. Reserve a stable regression set for release gating and maintain an exploratory set for discovering new weaknesses. AI-generated cases can broaden coverage quickly, but humans must review whether they reflect real policy and harm. Synthetic variety is useful; synthetic ground truth is still a hypothesis.

Conversation state is part of the product

A single-turn test can prove that the opening request routes correctly. It cannot prove that the agent retains a constraint, resists a contradiction, recovers from a failed action or escalates after several unsuccessful attempts. The dangerous failure often appears later, after context has accumulated and the user reframes the request.

Salesforce added conversation-level testing to Agentforce Studio in April 2026, allowing simulated personas and multi-turn evaluation. Use it for journeys where trust depends on sequence: identity verification before disclosure, consent before change, clarification before action and escalation after defined conditions. Check current product considerations when designing the suite; Salesforce documents limitations for conversation-level testing, including unsupported combinations with some context variables, mocked data and custom scorers.

Make the environment realistic and disposable

Salesforce recommends running Testing Center in a sandbox because agent tests can affect CRM data. A useful sandbox needs representative permissions, agent-user access, action configuration, knowledge, data shape and integration behaviour. A test that runs as an administrator against tidy records may pass while the production agent fails under its least-privilege identity or encounters missing and duplicated customer data.

Create known starting records and verify the ending state, then reset them predictably. Stub irreversible external side effects or route them to controlled test endpoints. Separate tests that need live retrieval or Data 360 queries from those that can use fixed fixtures. Salesforce states that Testing Center execution is unmetered as of Summer '26, while Data 360 queries initiated by tests remain metered; cost and capacity therefore still belong in the suite design.

Version the evidence with the agent

An agent version is more than instructions. Its behaviour depends on topics, actions, prompts, model configuration, permissions, knowledge, retrievers and connected automation. Record which versions and data snapshot produced each test result. If the grounding content changes after approval, yesterday's evidence no longer proves today's answers.

Salesforce now exposes run history in Agentforce Studio and command-line test execution through Agent Development Lifecycle capabilities. Use those features to compare outcomes over time and place defined suites in the delivery pipeline. A quality gate should block on critical assertions and material regression, not require every probabilistic response to be identical. Preserve failed traces so teams can distinguish model variation from a routing, data or action defect.

Keep humans in the evaluation loop

Automated evaluation scales repeatable checks, but it cannot fully represent how different people experience authority, tone, ambiguity or bias. Salesforce's Trust Testing methodology combines structured scenarios with diverse human perspectives to expose cultural, linguistic and identity-related failures that static technical checks can miss.

Recruit reviewers who understand both the business policy and the affected users. Give them concrete scenarios and a consistent way to record harm, uncertainty and disagreement. Do not ask one employee to stand in for an entire demographic. Human review should refine the dataset and scoring rubric, while material disagreements should reach the accountable risk or product owner rather than being averaged away.

Production is a new distribution, not the final test run

Pre-release testing samples expected behaviour; production introduces real phrasing, data, timing and adversarial pressure. Monitor topic and action selection, failed actions, escalation, latency, user feedback and policy exceptions within approved privacy boundaries. Connect each material incident to a reproducible regression case and decide whether the agent, action, knowledge or control needs to change.

Set observation windows and release thresholds before launch. Roll out to a bounded audience when risk justifies it, preserve a rapid disable or containment path and assign someone to review quality signals. An agent that passes once but has no operating feedback loop is not governed—it is merely unobserved between incidents.

The JSBC Labs view

Agentforce Testing Center provides increasingly capable tools: multi-turn simulation, custom evaluations, execution traces, run history and delivery integration. Those capabilities become meaningful only when the organisation supplies the ground truth. Define harm, separate deterministic controls from qualitative scoring, weight the suite by risk and preserve evidence against the full agent configuration.

The release question is not whether the agent passed enough prompts. It is whether critical failures are absent, residual risk is understood, business owners accept the evidence and production behaviour can be detected and contained. Build the test portfolio around that decision. A lower headline pass rate with honest high-risk coverage is more trustworthy than a flattering average built from easy conversations.