Structuring Agentforce the Smart Way: New Agent vs. New Topic

If you’ve ever stood in front of the Agent Builder screen wondering whether you should spin up a brand new Agent or just tack on another Topic—yeah, you’re not alone. It’s a decision that hits right at the core of Agentforce architecture. And while there’s no magic formula, there is a logic to it. 

So, let’s break it down; when do you create a new Agent, and when do you just add more topics to the one you’ve already got?

Think of Agents in Terms of Audience, Not Just Function

Let’s clear something up: Agents aren’t just chatbots with fancy names. Each Agent is a decision-maker designed to serve a specific audience—and that distinction matters more than you might think. Sure, you might have multiple Agents operating within the same department or business function, but if they’re speaking to different user groups, using different systems, or serving different intents, they should probably be separated.

So when you’re standing at the fork in the road—“Do I add a new Topic or spin up a new Agent?”—start by asking: “Who is this Agent meant to serve?” 

If the audience changes, odds are, so should the Agent.

Take Support, for example. You might have one Agent handling password resets and troubleshooting for existing customers. But now let’s say someone wants to ask about open roles or the application process. Technically, you could add a Topic about careers—but that audience isn’t a customer anymore; it’s a job seeker. Different needs, different voice, different context. That’s a solid cue for a separate Agent.

Audience often correlates with platform, too. If you’re embedding one Agent inside your customer support portal and another on your external careers page, there’s a good chance those Agents shouldn’t be the same—even if they both roll up under the same department. Bottom line? Grouping Agents by internal function or department isn’t enough. Agent boundaries should be drawn around who they’re supporting and how they need to respond. Get that part right and the architecture will start to fall into place a whole lot easier.

When a New Topic Makes More Sense

Now, on the flip side, when you’re still swimming in the same pool, but just need another lane, add a Topic. What do we mean by this?

Topics are the Agent’s “What do I do with this?” filter. Every user utterance is evaluated against the Agent’s Topics. So, if your service Agent’s job, for example, is already to support your app, and users now need help configuring notifications, or connecting their email, you don’t need a new Agent. You need more Topics.

Each Topic includes:

• A Classification Description (how to know when this Topic applies),
• A Scope (what it covers), and
• Instructions (what the Agent actually says or does)

It’s kind of like giving your Agent a script for different customer questions. You’re not hiring a new rep, you’re just giving the current one more training.

Rule of Thumb:
Different Mindset or Audience? New Agent.
Different Question? New Topic.

That’s a solid litmus test. So, ask yourself:

• Is this a fundamentally different kind of conversation?
• Does it need different integrations, different data, or a different tone?

Then it’s likely Agent-worthy.

But if it’s just a branch of the same core task—same systems, same persona—stick with your existing Agent and expand the Topics.

And hey, sometimes the answer’s hidden in the actions. If the new Flow you’re building taps into different systems or needs a different set of variables, that may push you into new Agent territory whether you planned on it or not.

A Quick Note on Actions (and a Common Pitfall)

Here’s a twist most people learn the hard way: Agents can only execute one Action per utterance. There was chatter about this loosening up around Spring ‘25, so if it’s been a while since you last checked, it might be worth poking around to see what’s changed.

And if you’ve updated your Flow inputs or outputs, don’t forget: you’ll need to recreate the Action from scratch. The Agent won’t just magically figure out the changes. Include version numbers in your Action names now, and save yourself a headache later.