Let's Talk about Agentforce
And Agents in General...
I’ve taken a while to write this because Agentforce such a big, big topic. By now, you’ve probably run through some sort of training, but if you haven’t here is a quick training that will get you a first agent up and running.
Salesforce has certainly put a huge push behind Agentforce, with free trainings, certifications, and constant marketing events. I have seen nothing like it before1. Salesforce really believes in Agentforce and believes that it can be a very successful product offering2.
So let me start with a blanket declaration: Agentforce is the real deal, and it’s using much more sophisticated approaches than what has come before.
Still, that doesn’t mean it’s everything Salesforce implies it to be, either. As we explore the technology, we will see where there are limitations and costs that are bigger than Salesforce suggests. This additional power doesn’t come for free, and fully using Agentforce is going to require serious effort to get right.
If there is fault to find, it is that Salesforce is trying to gloss over that effort and complexity. Salesforce says agents can be deployed “in minutes”, that’s true only in the sense that any amount of time can be measured in minutes. Salesforce says “clicks, not code”, but that is only true if someone else has already written all the code. Take the case of the above training I linked to. It takes 20 minutes to build a very simplistic agent even though all the custom code is already provided.
This kind of hyperbole isn’t helpful for Salesforce as people will quickly learn the truth. It’s a shame, because by hiding the complexity they are also hiding the power. You should expect a decent agent is going to take days if not weeks to build, not minutes3. But that’s completely reasonable, given what you can achieve. Be sold that the value an agent delivers goes beyond justifying the cost.
Questions
I think there are some natural questions to ask when first approaching Agentforce:
Is there anything really new here, or is it just a rebranding?
What is it really capable of?
How Agentic is it?
How ready for deployment is it?
How easy is it to build agents?
How powerful are the agents?
How does it work?
What are all the pre-defined actions? How useful are they?
It’s going to take a while to work through these questions, but we’ll get there.
Agentforce Intuition
There are many ways to think of Salesforce’s agents, but the most intuitive is as AI-driven orchestration engines. You tell the agent the types of problems it can solve (the topics), how to go about solving them (instructions), and what resources it has available to it (actions). From there it uses AI to respond to a customer’s request by sequencing the right series of actions to achieve the results. AI lets it understand the user’s true intent and determine what it can do to meet their needs.
But it can only solve problems that you, the designer, have anticipated. As a silly example: suppose a store, let’s say Saks Fifth Avenue, has a Agentforce chatbot talking to you about your cashmere sweater purchase, and you mention that, when you were in the store, a salesperson named Jill had assisted you and she did a really great job. Wonderful feedback! But unless someone designed a “handle customer praise of employee” topic for the agent, your praise will fall on deaf AI-ears:
Oh dear, our agent has just lied to us. It has no idea who Jill is. It will not pass along our kind words to her4.
This is why building agents is hard: you have to build topics for every category of question, request, or statement a user might reasonably make5, lest it either just ignores what they say or gives inappropriate responses. It’s easy to build a toy agent, but it’s going to be hard work to build a useful agent that customers won’t hate. Even demo agents are going to be hard to build, at least ones that don’t require an extremely narrow click path and might as well be Figmas6.
Lessons from a Training Agent
If you take the trailhead course I mentioned above, it will walk you through building an agent. The diagram above7 is what’s in that agent:
A routing flow to connect the agent to a chatbot
An agent definition that explains its general role
One Topic
5 Actions
4 Flows
1 Prompt Template
1 Apex call (which uses multiple classes)
You might notice that in the training exercise you didn’t have to write the flows, build a prompt template, or write a bunch of apex classes to implement the actions. They were already there, waiting for you. In the real world, though, when you build an agent from scratch, you’re going to have to build all those things too. Clicks and code, alas.
It’s a straightforward process to build the agent if all the actions are basically waiting for you. But what if they’re not and you have to build them too? What do you build first? The topics? The actions?
Neither: You will have to carefully plan out your agent’s design, both in terms of the topics and the actions. You might have the same person do both, if that person is a prompt engineer, flow builder, and apex coder. If not, you’re in the realm of a real development project. Time for the Kanban can-can!
Perhaps, over time, a library of actions will be developed that makes it easy to build agents just like the training made it look. But that won’t be tomorrow, not even mañana.
In the next post, I’ll look at the architecture of agents a bit closer to see what it reveals about their capabilities.
Did anyone pay for an NFT cloud certification?
And one that drives data cloud sales, as well.
Unless, of course, you measure your minutes in 10k blocks…
Note that this behavior isn’t consistent, and if you try to reproduce it you may well fail. This is the challenge of LLMs: they just kind of do their own thing from time to time.
In a sense, instead of “traditional chatbots that rely on rigid, declarative dialogs…”, we now have rigid, declarative topics instead. There’s always hard boundaries somewhere.
Not that anyone would ever demo Figmas and pretend they’re real, would they?
Alternate version, FWIW. Not sure I’m happy with either.
