Every Salesforce release has a testing ritual attached to it. Write the Apex tests, hit 75% coverage, run the regression pack, ship. Nobody loves it, but everyone knows the shape of it. Agentforce doesn’t fit that shape. Most teams find that out a week after go-live, when an agent tells a customer something that isn’t true and nobody can explain why, or point to a test that would have caught it.
Coverage percentage tells you nothing about an agent
Apex testing asks a narrow question: given this input, does the code return the expected output, every time, deterministically. An Agentforce topic doesn’t work that way. Ask the same question two different ways and you can get two different answers, both reasonable-sounding, only one of them correct. Coverage percentage can’t catch that. It was built to catch broken logic, not bad judgment.
That’s the real shift. You’re no longer testing whether code executes correctly. You’re testing whether a system that reasons in natural language reaches the right decision often enough, fails safely when it doesn’t, and never does anything it shouldn’t have permission to do in the first place.
What actually needs testing
Four things, roughly in order of how often they break in practice:
- Topic and intent routing. Does the agent correctly identify what the customer is actually asking for, including when they phrase it badly, use industry jargon wrong, or ask two things in one message?
- Grounding. When the agent answers a factual question, is it pulling from an actual record, a knowledge article, a Data Cloud object, something real, or is it filling the gap with something plausible-sounding?
- Action execution. When the agent decides to do something (update a case, trigger a refund, escalate), does it pass the right parameters, respect field-level security, and stop when it should?
- Escalation and refusal. Does the agent know when to hand off to a human, and does it actually do that instead of attempting the task anyway because it sounded confident it could?
Most teams I’ve seen test the first one reasonably well, because it’s the one that shows up in a demo. The other three get skipped, and they’re the ones that cause the incidents.
Build a test set before you build the agent
The teams that get this right treat the test set as a deliverable in its own right, written before a single topic is configured. Not after. A good test set for a contact-centre agent typically has three layers.
Golden conversations
A fixed set of real (anonymised) conversation transcripts, maybe 30 to 50 to start, covering the common paths and the awkward ones: the customer who’s annoyed, the one who gives contradictory information, the one who asks for something the agent genuinely shouldn’t be allowed to do. Run these against every build before it moves environments. If a change to one topic quietly breaks the behaviour of another, this is what catches it.
Adversarial prompts
Deliberately awkward inputs designed to find the edges: prompt injection attempts buried in a case description, a customer trying to get the agent to override a business rule by rephrasing the request, a question that sounds like it’s in scope but actually needs a human judgment call. If nobody on the team is writing these on purpose, someone outside the team will find them for you, in production, and it won’t go well.
Regression baselines
A snapshot of expected responses for a stable set of inputs, re-run on a schedule and whenever the underlying model, prompt, or grounding data changes. This is the part most orgs skip entirely because nothing in the standard release process asks for it. Without it, a model update from the platform vendor can shift agent behaviour and nobody notices until a customer complains.
Where this breaks in practice
A pattern I’ve seen more than once: a contact-centre team pilots an agent on a narrow, well-defined topic, like order status lookups, and it performs well. Confidence builds. The scope expands to billing questions, then to refund processing, faster than the test set grows with it. Three months in, the agent is handling cases nobody explicitly tested for, because the team that approved the expansion assumed “it’s working” meant the same thing at the new scope as it did at the old one. It didn’t. The grounding data for refunds wasn’t as clean as the order data, and the agent started answering confidently from stale records.
The fix isn’t slower rollout for its own sake. It’s tying scope expansion to test set expansion, explicitly, as a release gate. If the topic list grows, the golden conversations and adversarial prompts grow with it, before go-live, not after the first complaint.
Who actually owns this
This is where a lot of orgs stall, because it doesn’t map cleanly onto an existing role. A Salesforce admin can configure a topic and wire up an action, but evaluating whether an agent’s judgment is sound on ambiguous inputs isn’t a configuration skill. A developer can write the Apex action behind an agent action and unit test the Apex itself, but that only proves the action works when called correctly, not that the agent calls it correctly.
In practice, agent QA needs someone who understands both the business process well enough to write realistic test conversations and the platform well enough to read a reasoning trace and spot where it went wrong. On a lot of teams that’s the technical lead, by default, because nobody else has both halves. Worth naming explicitly rather than letting it fall to whoever’s free.
A practical go-live checklist
Before any Agentforce topic moves to production, I want to see:
- A documented test set covering the golden paths, the awkward paths, and at least a handful of adversarial inputs, with expected outcomes written down in advance, not judged after the fact
- A grounding check confirming every factual claim the agent can make traces back to an actual object, field, or knowledge source
- Explicit verification that every action the agent can trigger respects the same field-level security and sharing rules a human user would be bound by
- A named owner for the regression suite, and a trigger for re-running it (model change, prompt change, data model change, scope expansion)
- A rollback plan that doesn’t depend on someone noticing a bad answer in real time
None of this is exotic. It’s the same discipline Salesforce teams already apply to a risky Apex deployment, just aimed at a system where “the code is correct” is no longer the question that matters. The teams struggling with Agentforce adoption right now aren’t struggling because the platform doesn’t work. They’re struggling because they brought a deterministic testing mindset to a probabilistic system, and the gap between those two things is exactly where production incidents live.