Salesforce has been calling Agentforce a "third wave of AI" — after rule-based automation and predictive AI, now comes agentic AI. The keynotes are confident. The product imagery is slick. The actual picture of what Agentforce does, and what it does not do, is worth separating from the launch energy.
Agentforce, in Salesforce's framing, lets you build autonomous AI agents that take action on behalf of your business — answering customer questions, resolving cases, qualifying leads, updating records — without a human in the loop for every step. The pitch is that these agents can handle a meaningful volume of work that currently requires human attention, at scale, around the clock.
The vision is compelling. An AI that does not just answer a question but follows up, checks the CRM, creates a case, routes it correctly, and keeps the customer updated — without any of that going through a queue. Salesforce is betting its next decade on this being real and valuable.
Agentforce is a platform for building AI agents that operate within Salesforce's data and process environment. It sits on top of the Einstein 1 platform and connects to your org's data through Data Cloud. You configure agents using a low-code interface called Agent Builder — defining topics (what the agent handles), instructions (how it should handle them), and actions (what it can actually do: query records, trigger flows, call external APIs, send emails).
The underlying model is a large language model — Salesforce uses its own Atlas Reasoning Engine, which orchestrates reasoning across model calls and decides when to take an action versus ask for clarification versus escalate to a human. The "trust layer" (the Einstein Trust Layer) sits between your data and the external LLM calls, handling masking of PII and ensuring that data sent to the model does not leave Salesforce's infrastructure in a form that could be retained or used for training.
In plain terms: you define what an agent is allowed to do, give it access to relevant data, write instructions that shape its behaviour, and then deploy it to a channel — a website chat widget, a messaging platform, an internal Slack interface, or as a background process triggered by a record change.
Agentforce performs best where the problem space is well-defined, the data is clean, and the actions required are within a known set. Customer service triage is the clearest case — an agent that can look up an order, check a policy, update a case status, and escalate intelligently when it hits something outside its scope. That is a genuinely useful capability that existing chatbot tooling handled badly.
It also works well for internal-facing use: an agent that helps sales reps prep for calls by summarising account history, recent cases, and open opportunities. Or an agent that handles initial lead qualification questions and populates fields before a human reviews the lead. These are real time savings in real orgs.
The gap between the keynote and the implementation is, predictably, data quality. Agentforce reasons over whatever data exists in your org. If your accounts are missing key fields, your cases lack proper categorisation, your product catalogue is inconsistent — the agent will produce inconsistent, unreliable, sometimes wrong outputs. Garbage in, confidently stated garbage out.
The second gap is scope management. An agent that can do ten things is useful. An agent that does not know when a problem is outside its ten things is dangerous. Defining the boundaries clearly — and building the escalation paths that work when the agent reaches them — is non-trivial work that does not appear in the demo.
The third gap is the underlying cost model. Agentforce is priced per conversation, and the economics depend heavily on how often the agent resolves something without escalation. A poorly configured agent that escalates frequently is more expensive than the human workflow it was meant to replace. Getting to a deflection rate that makes the economics work requires iteration, testing, and real org data — not a two-day implementation.
Agentforce is not a feature. It is a platform capability that requires real implementation work to produce real value. The organisations that will see returns are the ones that start with a narrow, well-defined use case, clean data in that area, and a clear definition of what the agent should and should not attempt.
The organisations that will waste the budget are the ones that deploy a general-purpose agent against a messy org and wonder why it does not perform the way it did in the Dreamforce demo. The demo org is clean. Yours probably is not.
Agentforce is a meaningful step forward in what enterprise software can do. The marketing around it describes what it will be. Understanding what it is today — and what your org needs to look like before it can deliver — is the more useful place to start.
Agentforce is Salesforce's platform for building autonomous AI agents that operate within your org. You configure agents using Agent Builder — defining what topics they handle, what instructions shape their behaviour, and what actions they can take such as querying records, triggering flows, or sending emails.
It sits on the Einstein 1 platform and connects to your data through Data Cloud. Salesforce's Atlas Reasoning Engine orchestrates reasoning across LLM calls and decides when to take an action, ask for clarification, or escalate. The Einstein Trust Layer masks PII before any data reaches external model infrastructure.
Agentforce works best where the problem space is well-defined and data is clean. Customer service triage, internal sales prep, and lead qualification are the strongest early use cases. It performs poorly against messy org data or agents with poorly defined scope boundaries.
Three main gaps: data quality (bad data produces confident wrong answers), scope management (agents need clear escalation paths for out-of-scope problems), and the cost model (priced per conversation — economics only work at high deflection rates, which requires a well-tuned implementation).
Start narrow. Pick one well-defined use case with clean data. Define what the agent should and should not attempt, and build working escalation paths before go-live. An agent that escalates frequently costs more than the human workflow it was meant to replace. The demo org is clean — yours probably is not.
← All articles