Most conversations about Agentforce start in the same place. What should the agent do? What should it be called? Where should it sit? The agent is the visible part, it demos beautifully, and it is what everyone pictures when they hear the word AI.
It is also, in my experience, the least reliable part of the build and the part that most often needs removing.
I have built a fair number of AI projects on Salesforce now, and the same pattern keeps surfacing. Three of them make the point particularly well. One ended with the agent taken out entirely. One never had an agent in the first place. One needed the agent and could not have worked without it. Put them side by side and there is a lesson worth understanding before you spend money on anything.
Behind almost any useful Agentforce build sits a set of flows, prompt templates and Apex classes. That is where the real work happens: pulling information out of unstructured text, assessing it, matching it to records that already exist, writing it back into the right fields. Some of that is straightforward configuration. Some of it, particularly where you need structured output turned into multiple Salesforce records, is genuine development work and should be costed as such.
This is not a controversial reading of the platform, incidentally. Salesforce describes Agentforce as taking your existing workflows, prompt templates, Apex and APIs and turning them into agent actions. The engine comes first in their own description of it.
A prompt template, if you have not used one, is a reusable instruction to an AI model that lives inside Salesforce. The instruction stays the same every time. You pass in the variable bits, a record, a transcript, a list, and you get back a consistent output. You can call one from a flow, including a flow that runs automatically when a record changes. No conversation required.
That engine has to be built whichever route you take. The agent is an optional layer on top of it. What the agent does is read a conversation and decide which of your actions to run. It is doing routing, not the work itself.
Once you see it that way, the design question changes. It stops being "should we build an agent" and becomes "does this situation actually need a conversational front door".
In a previous role I helped build an agent for a sales training business. It had four genuine jobs to do, chained together.
First, take a user's messy notes or a call transcript and populate a structured form, formatted according to their sales methodology. Second, assess what was now in those fields against rubrics we had built from that same methodology, and score it. Third, read the gaps in that scoring and plan the next meeting, generating the specific questions the user needed to ask. Fourth, pull it all together into a follow-up email to the customer.
Four distinct actions, each with real work behind it. Plenty for an agent to route between.
The agent was the part that did not work. The methodology used very particular language, and the agent only picked the right action when a user happened to phrase their request in that language. That is not how people talk. It showed up as soon as we started testing: every single person we had testing the agent asked for the same thing in a slightly different way, and that variation alone was enough to send it down the wrong path often enough that nobody trusted it.
What fixed it was taking the interpretation away from the AI altogether. We moved to screen flows with buttons. Four labelled buttons, one per action, and the user did the routing by clicking. The flows and prompt templates behind them did not change at all. They had always worked. Input and output became far more consistent, because a button cannot misunderstand you.
Worth saying: this was early in Agentforce's life and the platform has moved on considerably since. The lesson that stuck was not that agents are bad. It was that the agent was the only part of that system doing any guessing.
The second build had no agent at all, and did not need one.
Abacus Playgrounds carry out around 1,000 site visits a year. Every visit needs an inspection captured, and the old routine was to make notes on site, drive back to the office, log into Salesforce and fill in a long survey form from memory. It took roughly an hour per visit.
Now they record a five-minute video on site, talking through what they are looking at. Their existing Dropbox to Salesforce integration picks it up, an automation in Make.com transcribes it through Deepgram, and the transcript is passed into a Salesforce flow along with an identifier that matches it to the right record. A series of prompt templates then turns that transcript into everything the site survey form needs, in the right format, in the right fields.
It also creates the follow-up activities. Where someone says on the video that a job needs doing and names who should do it, that becomes a task assigned to the right person and attached to the related opportunity.
The survey now takes about 15 minutes, and that time is review and approval rather than recall. The follow-up actions get captured properly, which they did not always before.
There is no conversation anywhere in that process. There is one path, every time. An agent would have added a front door to a building with no visitors.
The third build is a service agent on a car hire company's website, and here the agent is essential.
Someone arrives on the site and starts a conversation about booking a car. You cannot put four buttons in front of a stranger, because you have no idea what they want yet. The agent handles that conversation, holds the guardrails, and sits as a sensible layer between a member of the public and the Salesforce org behind it.
But notice where the difficult work happens. People do not describe cars the way the system stores them. Someone asks for "a small automatic" and the fleet list says something else entirely. What solves that is a flow that retrieves the full list of available cars and passes it into a prompt template, so the model can match what the customer said against vehicles that genuinely exist. Same engine as the other two builds. The agent is answering the door.
And even here, the agent was the hard part. The flows and prompt templates behaved themselves. Getting the agent to reliably pass the right information into them took the most effort by some distance. The system went live recently and produced its first genuine lead within a week, so it is working, but I would not pretend the agent was the straightforward bit.
It is tempting to reduce this to internal versus external, and that is roughly half right. For an external audience you often have no choice, because there are no buttons to click and the agent is the only way to surface anything at all.
Internally, you usually do have a choice, and the test is sharper than it first appears. Does natural language routing give you something a button could not? If your users are known, logged in, already governed by your permissions and sharing rules, and the process has defined steps, a button routes more reliably than an AI ever will. And the more specialised your internal vocabulary, the worse the agent performs, because that is precisely where it is most likely to misread what someone wants.
This is not a fringe observation. Agentforce adoption has been debated hard since launch, with pricing, messy orgs and weak enablement all cited, and early adopters asking for more control and visibility. Salesforce's own answer at Dreamforce in 2025 was Agent Script, a scripting language that blends deterministic rules with agentic reasoning so that behaviour becomes predictable. That is the vendor acknowledging the same thing: businesses need repeatable outcomes, and an unconstrained model does not give you them.
There is a longer-term reason to think this way, and it has become much clearer over the past few months.
With Headless 360, Salesforce has exposed effectively every platform capability as an API, an MCP tool or a CLI command, with the explicit intention of making the browser interface optional. Marc Benioff's framing was that the API is the UI, with agents reaching Salesforce data, workflows and tasks in Slack, in voice channels, or anywhere else. Parker Harris put it more starkly from the TDX stage, asking why you should ever log into Salesforce again.
Sit with that for a moment, because there is a tension in it. The whole premise of Headless 360 is that people stop opening the Salesforce interface. Yet today, an Agentforce agent is mostly reached through exactly the places that premise leaves behind: the Salesforce UI itself, or a website chatbot, with Slack as the one channel that already points the way out.
Now add MCP. An external assistant, Claude among them, can connect to an org and act against your flows, prompts and Apex through the same standardised tool calls. That assistant is already holding the conversation, and it is already doing the routing, which is the one job the agent was there to do.
So Headless 360 quietly exposes a genuine open question: where do Agentforce agents sit in this future, and for internal use at least, do you still need one? If the people involved are already authenticated, and an assistant they already work in can reach the engine directly, it is fair to ask what a dedicated agent in the middle is still adding.
There is a detail here that people miss. When an assistant connects over MCP, it authenticates as a specific user, so the sharing rules, permissions and profiles all travel with the connection. The security model is not bypassed, it applies exactly as it would if that person were clicking around in Salesforce themselves. And the Einstein Trust Layer, which masks sensitive data and checks what the model produces, wraps the prompt template rather than the agent, so it is doing its job the moment your engine calls that template, whatever sits in front of it. So internally, two of the things you might assume the agent is there to protect are already handled underneath it, which sharpens the question rather than softening it.
Externally is genuinely different, and here you do still need Agentforce. A member of the public on a website is not an authenticated Salesforce user, so there is no session carrying the security model, and something has to provide that controlled, anonymous front door between a stranger and your org. That is a real job, and it is exactly the job the car hire agent is doing.
Now the honest counterweight, because there is one. The moment you move the conversation out to an external assistant, the data that assistant handles is being processed somewhere the Trust Layer does not reach. The very thing that makes reaching the engine directly attractive, working in the tool your people already use, is also what steps outside that protection. Keep the conversation inside Agentforce and the whole exchange stays wrapped. Move it out and you gain the convenience but you are trusting the assistant's own data handling instead. That is a real trade-off, and how it nets out depends on the sensitivity of the data and your appetite for governance.
So I would not pretend the question is settled, because it genuinely is not. But internally, I think it is one worth asking now, before you commission an agent, rather than after.
Either way, notice which part of the stack the question hangs over. It is the conversational layer, the front door. Your prompt templates, your flows and your Apex classes still have to power whatever ends up sitting in front of them. That makes the front door the least durable thing you can invest in, and the engine the most.
None of this is an argument against AI in Salesforce. All three of those builds are live and delivering value right now. The difference between them is not whether the AI worked, it is how people reach it. One of them only got there once we changed the interface rather than the intelligence.
It is an argument about sequence. Start with the process and the work that genuinely needs doing. Build the engine that does it, in flows and prompt templates, where you can control the instruction, test the output and see what happened. Then, and only then, ask whether a conversation is the right way for people to reach it.
Get that order wrong and you spend your budget on the least predictable component, discover the hard part last, and tie your investment to the layer most likely to be replaced. Get it right and you have something useful long before you decide whether it needs a front door at all.
If you are weighing up where AI could genuinely help in your Salesforce org, and you would rather work out what to build before you build it, have an Agentforce conversation with us. We will look at the process first and the technology second.
Use of AI Disclaimer: Whilst these are my original thoughts, I have used AI to shape them into this article.