At TDX 2025, Salesforce’s developer-focused event, Rachel Stephens chats with Avanthika Ramesh, Senior Director of Product at Salesforce, about the difference between bots and agents in the Salesforce ecosystem. They break down when to use a traditional chatbot versus an AI-powered agent, exploring real-world use cases and best practices.

Transcript

Rachel Stephens: Hi, this is Rachel Stephens. I am at TDX 2025. It is Salesforce’s developer-focused event, and it is Agentforce Week. We are learning all about how to build agents in the Salesforce ecosystem. And I am here today with Avanthika. Can you please introduce yourself?

Avanthika Ramesh: Hello, everyone. I’m Avanthika, Senior Director of Product here at Salesforce, working on our Agentforce team. And I specifically run up our prompt builder team, which is critical a part of the Agentforce stack. My journey at Salesforce has been here at the company for five years. Started off on our Einstein box team, and then gradually full circle, made my way to Agentforce.

Rachel Stephens: We have been having great conversations this week about the difference between bots and agents, when to use an agent, when not to use an agent, what is a good use case for this? And so I just… I had such a great time learning about it, and I thought that it would be a great thing to capture and help other people learn about it, too. So could we do just a quick overview. You gave a great example about what a bot is versus an agent is. Can you help people understand that and just talk about what… Just give us a quick definition.

Avanthika Ramesh: Sure. So first of all, I think bot and agents, those two terms often get intertwined because people are often talking about the interfaces and the interaction paradigm other than how it actually works in the background. Traditional chat bots, when we were building them, they’re often menu-based or you have It’s a very controlled or, let’s say, deterministic flows, dialog flows, of how you want it to operate based on certain conditions or sequences. You have a lot of control with the bot. It can detect some intent, but to detect an intent, you have to give it a bunch of examples of utterances or examples of conversations. Then based on that, you slowly train a little model for that bot to use, to detect intents, or follow a dialog. You can think about the lift for building a bot to be pretty high, but at least there’s a little bit more control. Now, on the other hand, that level of control with an agent is a little bit different because instead of having you build that out, you can actually have what we call a reasoning engine or a mega prompt, figuring out how to coordinate a series of actions and take action on a certain query.

Whereas traditional chat bots were great for Q&A or menu-based click-through options, agents are great not just for answering queries and more conversational queries, but also taking multi-step actions and making decisions on how to reason through a series of actions. So as you can see, we’ve really gotten a lot more advanced in what we can do between the two.

Rachel Stephens: I love this, and I think it’s so helpful. And so I think one of the things when you come to an event like this and you get very excited about agents, I think a lot of people here have been very excited to get hands-on, excited to learn and build. Can you give us some guidelines? When is a good use case to be using an agent versus when should we be doing other approaches? How should people be thinking about that?

Avanthika Ramesh: I love this question. There’s a whole spectrum of things you can do with AI and Agentforce, not just one solution. We see customers on all ends of the spectrum. The very simple use case is start with a single shot prompt. Send a single instruction to a model and get back an output. We’ve seen a lot of those use cases powering a lot of internal efficiency. Like, Hey, I want to summarize a bunch of content on a record across multiple layers of data and just get a single shot response. From there, I’ll either use that to populate some field on a record or take some action on it. Other use cases were saying, Hey, I want to generate a a listening campaign or an email, perhaps detect a sentiment. Those are great because those are single-step use cases. Then you can get a little bit more advanced. And when we start talking about orchestration, you have the ability to start combining prompts with other prompts or prompts with actions. So we see people doing multi-step use cases using things like flows to have a more deterministic orchestration. So maybe they’ll have a prompt to summarize information and then translate it through another prompt, and then they’ll take an action to update some information.

Then the final step is the agent. Agents, they’re great for multi-step and use cases where you feel like you need some reasoning to make a decision. Usually, if you don’t have… Let’s say you have a process, and maybe there’s multiple ways to execute that process depending on certain data or scenarios or some contextual and situational information. It’s great for an agent because as it collects that context, it has a reasoning element behind it that’s able to know which sequence of actions to take based on that scenario. Whereas on the other hand, if you want deterministic orchestration, it’s just simple prompts, well, then those are for use cases that are a fewer steps. You have a set process in place that you’ll do almost every single time. So as you can see, there’s a balance, and I think there’s great use cases for all, but you definitely want to make sure you’re not shoehorning agentic use cases into more simpler use cases when you really don’t need to. I think, think simple, see if the simple use cases work, if not, gradually progress from there.

Rachel Stephens: I love it. Well, Avanthika, thank you so much for your time, and thank you for sharing all your knowledge.

Avanthika Ramesh: Thank you. I’m glad I have the opportunity to.

Rachel Stephens: Wonderful. Thanks, everyone.