Ten Agentforce mistakes and what each one looks like in production
Most teams arrive with a diagnosis rather than a symptom, and the diagnosis is usually wrong. Sorted by what the failure looks like from the outside, which is all you have once the agent is live.
ChatGPT
Claude
Google AI
Copilot
AI & AgentforceMost calls we take about a struggling deployment open with a diagnosis rather than a symptom. The agent is making things up. The agent is too cautious. The agent works and nobody uses it. In a good half of those conversations the diagnosis is wrong, and three weeks have already gone into fixing something that was not broken.
So the ten below are sorted by what the failure looks like from the outside, because once the agent is live that is the only evidence you have. Find the symptom first. Each section then gives you the test that confirms it, which matters, because several of these symptoms have more than one plausible cause and only one of them is yours.
Read the symptom, not the story
| Symptom in production | Likely cause | First move |
|---|---|---|
| Fluent answers that are wrong on specifics | 1. Grounding failure treated as a prompt problem | Retrieve the source by hand before touching instructions |
| Answers on topics nobody scoped | 2. No out-of-scope list, so nothing gets declined | Write the refusal list and the decline wording |
| Fine in testing, fell apart in week one | 3. Started on the highest-volume intent | Narrow to a bounded intent set and rebuild outward |
| Customers reach a person only by giving up | 4. Escalation suppressed by persistence instructions | Search the instructions for wording that rewards trying harder |
| Nobody can say whether last week's change helped | 5. No scored regression set | Freeze fifty questions with known answers |
| A regression appeared and two things changed | 6. Remediation and build running in parallel | Sequence them, freeze one while the other moves |
| One action misbehaves and you cannot narrow it | 7. Wide actions doing several jobs | Split by verb, one action doing one job |
| Content surfacing to the wrong people | 8. The second access path was never audited | Audit content visibility separately from record sharing |
| Quality slid over months and nobody noticed | 9. No named owner after launch | Name a person and give them a standing hour |
| Deflection up, phone queue unchanged | 10. Measuring deflection alone | Add repeat contact, escalation rate, sampled accuracy |
The right-hand column is the first move, not the remediation. Its job is to confirm or eliminate a cause cheaply, usually in under an hour, before anybody commits a sprint to it.
When the answers are wrong
1. Treating a grounding failure as a prompt problem
The agent answers a question about the returns window and gets it wrong by a fortnight. The instinct is to rewrite the instructions, because instructions are editable in minutes and knowledge remediation is a project.
How to confirm it. Take the exact failing question and retrieve the source by hand. Three outcomes. You find one correct, current, uniquely authoritative document, in which case the agent had what it needed and the problem may genuinely sit in the instructions. You find nothing authoritative. Or, most commonly, you find two documents that disagree and neither is marked as superseding the other. The last two are grounding, and prompting cannot fix either, because prompting changes how an answer is expressed rather than what was available to express.
The reliable tell is durability. A prompt edit made against a grounding failure fixes the question you tested and fails on the one beside it, because you patched an instance rather than a cause. If the fix log shows a run of narrow, question-specific instructions, you are treating symptoms one at a time. The sequence we use to establish authority before any tuning starts is set out in the grounding checklist.
2. No out-of-scope list, so the agent answers things it should decline
The agent offers a view on the tax treatment of a refund, compares you to a competitor, or produces something adjacent to legal advice. Nobody scoped any of that. Nobody told it not to, either.
How to confirm it. Ask whether a written list exists of what the agent declines. Not a principle, a list. If there is no list, the agent has no basis for declining anything, and it will answer whatever it can construct a plausible response to. Then have somebody outside the project spend twenty minutes deliberately steering it off-topic, which finds the boundary faster than any amount of internal review.
The fix is an explicit refusal set expressed as topics rather than banned words, since word lists are trivially routed around by rephrasing. Write the decline wording as well. A bare refusal with no next step generates complaints of its own, so each declined topic needs an onward path: a person, a form, or a named team.
When the agent goes too far, or not far enough
3. Starting with the highest-volume intent because that is where the business case is
Everything looked good in testing. Week one was ugly. This is the most predictable failure on the list and the hardest to argue against beforehand, because the business case genuinely is strongest where the volume is.
How to confirm it. Two counts against the first fortnight of transcripts. First, how many distinct phrasings arrived for that single intent. Second, how often the correct answer required data from a system outside Salesforce. High volume in a service queue usually means both: the widest range of phrasings and the deepest external dependency. Order status is the canonical example, and it is an integration project wearing an AI project's clothes.
Volume is what makes a business case look good and what makes a first deployment look bad. The scoring we use to sequence candidates, including why boring internal use cases beat glamorous customer-facing ones, is in use cases that survive a business case.
4. Escalation suppressed by instructions telling the agent to try harder
Deflection looks healthy, escalation sits near zero, and the complaints that do arrive describe going round in circles. Nobody decided to suppress escalation. It arrives through a series of individually reasonable edits, each of which moved the headline number in the right direction.
How to confirm it. Search the instruction set for anything that rewards persistence: attempt to resolve before handing over, exhaust available options first, avoid unnecessary transfers. Then count turns to escalation in the conversations that did escalate. If the distribution is bunched at the far end, customers are getting to a person by outlasting the agent rather than by any designed trigger firing.
Persistence should come from better grounding, never from reluctance to hand over. Escalation needs designed triggers, and at least one should be a business rule rather than a confidence score, because a confident wrong answer on a hardship enquiry is precisely what a confidence threshold cannot catch. The full treatment is in deflection that does not cost you the customer.
When you cannot tell what changed
5. Launching without a scored regression set, so degradation is invisible
Ask what last Tuesday's change did to answer quality. If the reply is a feeling, or a reference to two or three conversations somebody remembers, there is no regression set and every quality judgement being made is anecdote.
How to confirm it. Ask to see the score. Not the transcript sample, the score, from before the change and after it. Its absence is the confirmation, and it takes about a minute to establish.
Fifty to eighty real questions with known correct answers, marked by a person against a written rubric, run before and after every material change. It is unglamorous and it is the single asset that makes the other nine mistakes findable, because without a stable measurement every diagnosis is a story about a handful of conversations. Build it before launch. Retrofitting one afterwards means the baseline starts at whatever quality you have already drifted to, which is the number you most needed to compare against.
6. Running knowledge remediation and the agent build in parallel
A regression appears in week six. Knowledge was being cleaned up that week and the agent was being tuned that week, and there is now no way to attribute the change to either.
How to confirm it. Put both change logs side by side, day by day. Overlapping edits inside the same regression window means attribution is gone. You are not looking for a culprit here, you are checking whether the question is answerable at all before anyone spends a week on it.
The parallel plan is faster on the schedule and slower in practice, because unattributable regressions cost more to unpick than the sequencing ever saved. Freeze windows fix it cheaply: knowledge changes land early in the week, agent changes midweek, a regression run between the two. That single scheduling decision turns a fortnight of guessing into a morning of reading a diff.
7. Wide actions that do several jobs, making misbehaviour undiagnosable
An action misbehaves and you cannot narrow which part of it did. The usual culprit is something like manage order, which internally handles lookup, status, address change and cancellation.
How to confirm it. Read the action description the way the model reads it. If it contains "and" or "or", it is wide. The second tell is selection frequency: a wide action gets chosen for requests it barely fits, because its description matches nearly everything.
Split by verb, one action doing one job, described in the language a customer would actually use. Agent Builder makes narrow actions cheap to define, and narrow actions can be tested in isolation, which is the whole point. There is a cost dimension too. Consumption is metered per action across the Agentforce buying models, so an agent taking four actions to answer what should take one is quietly expensive as well as opaque.
When something is visible that should not be
8. Never auditing the second access path
Record sharing was reviewed carefully. Somebody with the right instincts checked profiles, roles and sharing rules against the user the agent runs as. Then the agent surfaced the contents of an internal article to an external customer, or refused an article the customer was entitled to see.
How to confirm it. Test as a genuinely low-privilege user, not as an administrator with a role temporarily swapped. Ask for something you know sits inside a restricted article and something you know sits in a public one. Record access and content visibility are governed separately, and a clean review of the first tells you nothing at all about the second.
When nothing is obviously broken
9. No named owner after launch, so drift goes unnoticed
Nothing broke. Everything slid. Answer quality in month five is worse than in month one and no single change explains it, because the cause is dozens of small ones: articles edited by their owners, products added, a policy revised, an intent quietly moving outside the grounded set.
How to confirm it. Ask who read last month's escalations. If the answer is a team name rather than a person's name, nobody did. Ask when the regression set was last run. If the answer needs looking up, it is not being run.
One named person, one standing hour a week, a fixed agenda: sampled accuracy review, current regression score, escalation trend, actions per conversation. That last number is the earliest warning available, because an agent working harder to reach the same answer shows up on the consumption bill weeks before it shows up in a complaint.
10. Measuring deflection alone
Deflection is up and the phone queue has not moved. The number is real. It is also silent on whether anything was resolved, and those two things come apart in a specific way: a plausible wrong answer is a deflected conversation and a repeat contact three days later.
How to confirm it. Join contacts across channels for the seven days following each agent conversation. Most organisations cannot make that join on request, which is itself the finding, because deflection measured inside one channel is structurally incapable of seeing the customer who simply used a different one.
Report four numbers together and never one: deflection, repeat contact within seven days, escalation rate, sampled accuracy. Agree the set before launch, while the figures are hypothetical and nobody is defending them.
The order to fix them in
If more than one of these is yours, and it usually is, the sequence is not worst first.
Fix number 8 immediately, whatever else is happening, because it is the only one on the list whose downside is unbounded. Then build number 5, the regression set, before attempting anything else. That feels like a detour and it is the opposite: every subsequent fix is unverifiable without it, and you will otherwise spend the next month unable to tell repair from coincidence.
After that, work upstream to downstream. Grounding and scope before instructions, instructions before measurement, measurement before widening. Fixing in the other direction produces changes that look effective for a fortnight and then stop, because the layer underneath them was still moving.
Running the diagnosis
Ninety minutes, three people, one screen. Read twenty conversations end to end, sampled deliberately rather than randomly: five escalations, five completions on the highest-volume intent, five where the customer rephrased more than twice, five from the long tail. Mark each against the symptom table as you go.
Reading beats reporting here, and it is worth being blunt about why. Dashboards show the shape of a distribution. They cannot show the moment a customer gave up, or the exact turn at which the agent began answering a different question from the one asked. Every failure above was found by somebody reading, and almost none of them were named correctly on the first description.
The sequencing that avoids most of this in the first place, and the order the work should run in before launch rather than after it, is in how to implement Agentforce and the implementation best practices.
