Your Flow Isn't an Agent. Here's How to Tell the Difference.
A Flow with a prompt template isn't an agent — and that's fine. Here's the test for telling the difference, why it matters, and when to reach for each approach.
If the Flow is the brain, you built a smart Flow — not an agent.
I've been building Salesforce automations for years. When Prompt Builder came out, I did what most admins and consultants did: I plugged prompt templates into my Flows. Lead comes in, Flow fires, prompt runs, field gets populated. It felt like AI. It worked. My clients were impressed.
But it wasn't an agent. And for a while, I couldn't articulate why.
The distinction matters — not because there's anything wrong with using prompts in Flows, but because if you're going to tell a client (or your boss) that you're "building agents," you should know what that actually means. And more importantly, you should know when each approach is the right one.
What most people are actually building.
A Record-Triggered Flow fires on Lead creation. It calls a prompt template that summarizes the company's description. The result populates a field. Maybe there's some branching logic downstream — if the summary mentions certain keywords, route the Lead to a specific queue.
This is a Flow with AI in it. The Flow decides when to call the LLM. The Flow decides what to do with the response. The Flow controls the path. The LLM is a tool the Flow uses — like a formula field that happens to be really smart.
I call this "infusing reasoning into traditional logic." It's valuable. It's a legitimate pattern. But it's not an agent.
A Flow with a prompt template is the right tool when the AI is doing one discrete task and the path is predictable. Calling it an agent doesn't make it better — it just makes the label wrong.
What makes something a true agent.
In a true Agentforce agent, the relationship is reversed. The agent is the brain. It receives an input, reasons about what to do, selects which actions to invoke and in what order, observes the results, and adapts its plan.
Salesforce calls the underlying technology the Atlas Reasoning Engine. It runs a "plan, evaluate, act" loop — the same ReAct pattern from AI research. The agent isn't following a path you drew on a canvas. It's deciding the path based on what it sees.
| A Smart Flow | A True Agent | |
|---|---|---|
| Who controls the path | You — drawn on a canvas | The agent — at runtime |
| Decides its own steps | ✗ | ✓ |
| Selects which actions to invoke | ✗ | ✓ |
| Adapts the plan to what it observes | ✗ | ✓ |
| The LLM's role | A tool the Flow calls | The brain doing the reasoning |
| You describe the logic as | Decision diamonds | Natural-language judgment |
The anatomy of a real agent.
An Agentforce agent has four structural components:
The Agent is the top-level container, built in Agent Builder. It has a name, a description, and one or more Topics. Think of it as the person.
Topics are areas of responsibility — like items in a job description. Each Topic has a scope (tells the agent "this is your lane"), natural language instructions (tells the agent how to handle situations in this area), and a set of Actions it can invoke. The agent uses Topic descriptions to decide which Topic is relevant to the current input.
Actions are the things the agent can actually do. Each Action maps to an Invocable Flow, an Invocable Apex method, a Prompt Template, or an external API call. The agent doesn't call these in a fixed order. It reasons about which ones to call based on the input and the instructions you gave it.
Instructions are written in natural language, declaratively. Salesforce's own guidance says to be specific. Not "check order status" but "Check the Shipment_Status__c field on the Order object and compare it against today's date. If the shipment is more than 3 days overdue, escalate to a human agent." You're describing the judgment, not the path.
A real example: processing enriched Leads.
Here's a use case I'm building in my own org. I use Claude — Anthropic's AI — to enrich Leads by browsing company websites and populating qualification fields: a website summary, a pain hypothesis, AI readiness, red flags, and a verdict (Hot, Warm, Cold, or Disqualify). That's the thinking work, and Claude is the right tool for it because it can browse the web and make qualitative judgments.
But once enrichment is done, something needs to react. A Hot lead 12 miles from my office needs different handling than a Warm lead 200 miles away. A Hot lead with a duplicate Account match needs different handling than a Hot lead that's brand new. A Disqualified lead needs to be marked Unqualified with the reason logged.
I could build this as a Flow with branching logic. Verdict = Hot AND Distance < 30? Create a high-priority Task. Verdict = Hot AND Distance >= 30? Create a normal-priority Task. Verdict = Disqualify? Update Status. And so on, for every combination.
Or I can build an agent with a single Topic and let it reason.
The Topic instructions look something like this:
You process Leads that have been enriched by Claude AI. Examine the Lead's Enrichment Verdict, Website Summary, Pain Hypothesis, Red Flags, and Distance fields. For Hot leads within 30 miles, create a high-priority Task and check for duplicate Accounts — if found, note it in the Task. Send a notification. For Hot leads beyond 30 miles, same treatment but normal priority, no notification. For Warm leads, create a standard follow-up Task. For Cold leads, log an Activity with the assessment. For Disqualified leads, update Lead Status to Unqualified and log the Red Flags as the reason.
Eric Lovgren, lovgren.ai
The agent has five Actions available, each backed by a simple Invocable Flow that does one thing well:
- Check Duplicate Accounts
- Create Follow-Up Task
- Update Lead Status
- Log Enrichment Activity
- Send Hot Lead Alert
The agent decides which Actions to invoke, in what order, based on what it sees on the Lead. A Hot lead at 12 miles with a duplicate Account match gets a different treatment than a Hot lead at 45 miles with no match — and the agent figures that out from the instructions, not from branching logic I drew on a canvas.
Same Action library, same Topic, same type of input — and a genuinely different sequence of actions depending on what the agent reasons about the Lead in front of it.
When to use each approach.
A Flow with a prompt template is the right choice when the logic path is predictable and the AI is doing one discrete task — summarize this text, classify this case, extract these fields. The Flow is the right brain for simple, deterministic orchestration.
An agent is the right choice when the combination of inputs creates too many branches to draw on a canvas, and you'd rather describe the judgment in natural language than in decision diamonds. The agent is the right brain for complex, contextual decision-making.
And the two work together. In my pipeline, a Record-Triggered Flow fires when the Enrichment Verdict field is populated. That Flow invokes the agent. The Flow is the doorbell. The agent decides what happens after the door opens.
Salesforce's architecture team calls this "an autonomous, background pattern that introduces an agentic step into data operations." If you want to go deep on the pattern library, their Enterprise Agentic Architecture guide on the Salesforce Architects site is worth the read.
Why the distinction matters.
If you're a consultant, your clients are going to ask you to "build agents." Some of those requests are actually requests for smart Flows — and that's fine. Faster to build, easier to maintain, and perfectly appropriate for the task.
But some of those requests genuinely need an agent. When the decision space is wide, when the inputs are qualitative, when describing the judgment in English is easier than drawing it in branches — that's when you reach for Agent Builder instead of Flow Builder.
Knowing which is which is the skill. Building both well is the job.
Eric Lovgren, lovgren.ai
For more on how Claude and Agentforce work together in practice — and why the right answer is usually both — see Use Claude for Thinking. Use Agentforce for Reacting.