Agentforce works when the org underneath it is ready.
Most Agentforce pilots do not fail because the agent was configured badly. They fail because the agent was pointed at a data model nobody trusted, a sharing model nobody had reviewed, and knowledge sources nobody owned. I assess whether your org can support agents today, fix what cannot, and then build agents that behave in production the way they behaved in the pilot.
Why AI projects stall on the platform
An agent is only as good as what it can read and what it is allowed to do. When account data is duplicated across three objects, when field-level security was last reviewed at go-live, and when the knowledge base has not been curated since the last migration, an agent will confidently return the wrong answer. That is not a model problem. It is an architecture problem wearing a model costume.
The second failure mode is permissions. Agents act on behalf of users, inside the same sharing model everyone else lives in. Orgs that have accumulated years of permission sets, sharing rules, and one-off grants often cannot answer a simple question: if this agent runs for this user, what exactly can it see? Nobody wants to find that out from a customer.
The third is that pilots get scoped to a demo and then judged as production. A pilot on clean sample data proves the feature works. It proves nothing about your org. The gap between those two things is where budget goes to die.
"The pilot looked great, and then it hit real data."
"Nobody can tell us exactly what the agent is allowed to see."
"We bought the licences and still cannot get past the proof of concept."
Business impact
An agent that returns wrong answers is worse than no agent, because it costs trust that is expensive to rebuild. Once a sales team stops believing the assistant, they stop using it, and the licence spend becomes a line item somebody has to defend. The reverse is also true. An agent grounded in data people already trust removes real work from support queues, sales research, and service triage, and it does so without adding headcount.
How I solve it
Readiness assessment
Audit the data model, duplication, field-level security, sharing model, and knowledge sources against what the agent will actually need to read and do. The output is a written go, fix, or wait, with reasons.
Grounding and permission design
Fix what the assessment surfaced. Consolidate the objects the agent depends on, define the retrieval and knowledge strategy, and design the permission model so the answer to "what can this agent see" is a document, not a guess.
Agent build
Build the topics, actions, and instructions in Agentforce, wiring real Salesforce actions rather than a chat wrapper. Every action that writes data goes through the same validation and automation your users do.
Guardrails and testing
Define escalation and handoff paths, set the boundaries of what the agent may answer, and test against real historical cases rather than sample prompts. Handoff includes the documentation your admin team needs to change it safely.
Typical engagement: a two to three week readiness assessment, then a scoped build if the assessment says the org is ready. Scope and price are fixed in a written proposal before anything is built.
Outcomes from this work
- A written readiness verdict you can take to a budget conversation, whether the answer is yes or not yet
- A documented answer to what each agent can read, write, and escalate
- Agents tested against real historical cases before they reach a customer
Outcomes are drawn from anonymized client engagements; specific figures are shared on a consultation call.
This is the right engagement if…
- You have bought or are evaluating Agentforce and want an honest read on whether your org can support it before you commit further.
- A pilot performed well on sample data and stalled when it met production.
- You need the data model, sharing model, and knowledge sources assessed by the same person who will build the agent.
- Your compliance or security team needs a documented answer on what an agent can access before it goes live.
…and probably not if
- You want an agent deployed this month regardless of what the readiness assessment finds.
- The organisation is not willing to change the underlying data model, even where it is the reason the agent is wrong.
- You are looking for a chatbot on the website rather than an agent operating inside Salesforce.
Before you book a call
Do we need Data Cloud to use Agentforce?
What if the assessment says we are not ready?
What’s the starting investment?
Can you work with the AI or data team we already have?
How do you stop an agent from doing something it should not?
Is this relevant if we are not doing AI yet?
Related work
-
35% Administrative time reduced by+28% Cross-sell opportunities identified+18% Matter close rate improvement - Medical Device Distribution
Sales Cloud with territory management and automated dashboards
Read the case study64% → 89% Forecast accuracy-18 days Sales cycle reductionRep retention: 12% → 6% annual churn Territory conflicts eliminated
Start with the assessment.
Bring the org, the use case, and whatever the pilot did or did not do. Thirty minutes is usually enough to tell you whether the blocker is the agent or the architecture underneath it.