One of the most interesting architecture conversations I am having these days is not simply about where AI fits into Salesforce.
It is a more fundamental question:
Does this business process actually need an agent?
With Salesforce moving deeper into agentic experiences, it is tempting to look at an existing workflow and ask:
“Can we replace this with an AI agent?”
Technically, in many cases, we probably can.
Architecturally, that doesn’t mean we should.
There are plenty of business processes where I would still choose a traditional deterministic workflow without hesitation.
And there are also situations where forcing an agent into a rigid workflow creates more complexity than value.
The architectural skill is knowing the difference.
For me, the decision comes down to one principle:
Use deterministic automation when the path to the outcome is known. Use an agent when the path itself requires interpretation, reasoning, adaptation or decision-making.
That sounds simple.
In practice, it requires quite a bit of architectural judgment.
The First Question I Ask
When someone proposes an agent for a business process, I usually ask:
“What exactly is the agent expected to figure out?”
If the answer is:
“When an Opportunity becomes Closed Won, create an Order, update the Account and notify the implementation team.”
I don’t need an agent.
The process is already known.
There is no meaningful reasoning required.
A workflow is better.
But if the requirement is:
“Understand the customer’s request, determine what they are trying to accomplish, gather the relevant information, decide which business process applies, and take the appropriate action.”
Now we have something different.
The agent is not merely executing instructions.
It is interpreting the situation.
That distinction is at the heart of agentic architecture.
Workflow and Agent Solve Different Problems
I think about them this way.
Workflow:
Given condition X, execute actions A, B and C.
Agent:
Given objective X and the available context, determine the appropriate steps and execute them within defined boundaries.
The difference is decision variability.
A workflow expects the architect to define the path.
An agent can determine the path within constraints.
That doesn’t make an agent inherently better.
It makes it useful for a different class of problems.
Where Workflow Wins
There are many situations where I would strongly prefer deterministic automation.
For example:
- Update a record when a field changes
- Create a task after an opportunity closes
- Route a case based on known criteria
- Send a notification
- Calculate a predefined value
- Start an approval process
- Synchronize a known field
- Publish a platform event
- Apply a fixed business rule
- Enforce a predictable process
Consider:
If Opportunity Stage = Closed Won, create the implementation record.
There is nothing to reason about.
The business rule is explicit.
A Flow is easier to test, easier to audit and easier to predict.
Introducing an agent here would be architectural overengineering.
Deterministic Automation Has a Major Advantage
The biggest advantage of a workflow is something we sometimes underestimate:
Predictability.
If the same input enters the process, we expect the same outcome.
That is extremely valuable for:
- Financial transactions
- Compliance processes
- Regulatory reporting
- Contractual obligations
- Revenue recognition
- Data synchronization
- Security controls
- Customer eligibility
- Pricing rules
In these situations, predictability is often more important than flexibility.
I don’t want an AI agent deciding differently tomorrow because the context was interpreted differently.
I want the rule to remain the rule.
Where Agents Start Making Sense
Now consider a customer service interaction.
A customer says:
“My shipment arrived damaged, I was charged twice, and I need the replacement before Friday because I’m leaving the country.”
There isn’t necessarily one clean workflow.
The system needs to understand:
- What happened?
- Is there a duplicate payment?
- Is there a damaged shipment?
- What product is involved?
- What replacement options exist?
- Is the customer eligible?
- What is the urgency?
- What policies apply?
- Which systems need to be consulted?
- What action should happen first?
This is a much better candidate for an agent.
The agent can interpret the request, gather context and determine which capabilities it needs.
The workflow can still be part of the implementation.
The agent simply becomes the reasoning layer.
Agent Does Not Mean Uncontrolled Automation
This is another misconception I try to address.
An agent should not mean:
“Let AI do whatever it wants.”
In an enterprise architecture, I would never design it that way.
A well-designed agent should operate within:
- Defined goals
- Authorized actions
- Trusted data sources
- Business policies
- Security boundaries
- Tool permissions
- Transaction boundaries
- Escalation rules
- Human approval requirements
The agent gets freedom to reason within boundaries.
That is very different from giving it unrestricted access to enterprise systems.
The Adaptive Reasoning Spectrum
I find it useful to think about automation as a spectrum.
More deterministic More adaptive
Fixed Rule ---- Workflow ---- Orchestration ---- Agent ---- Human
| | | |
Predictable Structured Variable Reasoning
The further we move toward the agent side, the more decision variability we introduce.
That variability can create significant business value.
It can also introduce significant risk.
The architecture needs to balance both.
The Key Question: How Variable Is the Path?
This is probably the most useful test.
Imagine the business process has ten possible paths.
If the business can clearly define all ten paths using rules, workflows may still be appropriate.
But if there are hundreds of possible combinations and the correct path depends on context, language, historical interactions and available information, the problem starts looking more agentic.
For example:
Workflow
If customer is Platinum and case priority is Critical, route to Tier 3.
Agent
Understand the customer’s problem, evaluate the customer’s history, determine urgency, identify the appropriate support capability and decide whether escalation is necessary.
The second problem is fundamentally different.
Don’t Confuse Complexity With Intelligence
This is an important distinction.
A process can be extremely complicated without requiring AI.
For example:
Calculate tax based on jurisdiction, product category, customer type, transaction type and effective date.
That’s complicated.
But if the rules are known, deterministic logic is still appropriate.
Conversely, a relatively simple-looking problem can require reasoning.
For example:
“Why is this customer unhappy?”
The data may be straightforward.
The interpretation isn’t.
So I don’t use complexity alone as the reason to introduce an agent.
I use uncertainty and decision variability.
Workflow Is About Execution
A workflow is excellent when humans have already decided what should happen.
The system simply executes the decision.
For example:
Opportunity Closed Won
|
v
Create Order
|
v
Create Implementation Task
|
v
Notify Team
|
v
Publish Event
The workflow doesn’t need to understand the business situation.
It simply executes the defined process.
That is a strength, not a limitation.
Agent Is About Decision and Execution
An agent changes the model.
Customer Request
|
v
Understand Intent
|
v
Gather Context
|
v
Reason About Options
|
v
Choose Action
|
v
Execute Tools
|
v
Evaluate Result
|
+---- Retry / Adjust
|
v
Complete / Escalate
The important addition is the reasoning loop.
The agent can determine what to do based on context.
That is where adaptive behavior creates value.
The Agent + Workflow Pattern
In enterprise Salesforce architecture, I don’t think the future is:
Agents replace workflows.
I think the more interesting architecture is:
Agents decide. Workflows execute.
For example:
Customer Request
|
v
Agent
|
| Determine intent
| Gather context
| Decide next action
|
v
Business Workflow
|
+---- Update Case
+---- Create Task
+---- Start Approval
+---- Invoke Integration
+---- Notify Customer
This creates a useful separation.
The agent handles ambiguity.
The workflow handles deterministic execution.
That combination can be significantly stronger than trying to make one technology do everything.
A Practical Example: Case Management
Consider a traditional service process.
A customer opens a case.
The rules are:
- Premium customer → priority high
- Product category = hardware → hardware queue
- Severity = critical → escalate
- SLA < 4 hours → notify manager
This is a perfect workflow.
There is no reason to introduce an agent.
Now change the requirement:
“Analyze the customer’s message and conversation history, identify the underlying problem, determine whether it is a technical issue, billing issue or product issue, assess urgency and recommend the appropriate next action.”
Now we have a reasoning problem.
An agent can interpret the information and then invoke deterministic processes.
That is where the combination becomes powerful.
Another Example: Sales
Consider a simple sales automation:
When an opportunity reaches 90%, create the contract review task.
Workflow.
No debate.
Now consider:
Review the account’s recent activity, open opportunities, support issues, product usage and engagement history. Identify accounts where the sales strategy may be at risk and recommend the next best action.
This requires interpretation.
An agent can potentially:
- Gather context
- Identify patterns
- Summarize the situation
- Recommend actions
- Prepare communications
- Ask for additional information
- Trigger approved actions
This is a very different architectural problem.
The Cost of Adaptability
Adaptive reasoning isn’t free.
Introducing an agent creates additional architectural considerations:
- Model selection
- Prompt or instruction management
- Context management
- Tool permissions
- Hallucination risk
- Guardrails
- Evaluation
- Observability
- Security
- Cost management
- Latency
- Failure handling
- Human escalation
A workflow doesn’t have all of these concerns.
That’s why I don’t recommend introducing agents simply because the technology is available.
The value needs to justify the additional architecture.
Determinism Is a Feature
In the AI era, there is sometimes a tendency to treat deterministic systems as old-fashioned.
I disagree.
Determinism is extremely valuable.
If I am calculating:
- Commission
- Tax
- Credit limit
- Discount
- Contract entitlement
- SLA
- Regulatory classification
I want predictable logic.
I don’t want an agent interpreting the rules differently.
AI should enhance areas where reasoning creates value.
It shouldn’t replace deterministic business rules simply because it can.
Where I Would Be Very Careful With Agents
I would be particularly cautious about autonomous agents making decisions involving:
- Financial commitments
- Legal obligations
- Regulatory decisions
- Credit approval
- Sensitive customer eligibility
- Irreversible transactions
- Large monetary transfers
- Security privileges
- Data deletion
- Contractual commitments
An agent may still participate.
But I would normally introduce:
- Strong guardrails
- Deterministic policy checks
- Approval steps
- Human oversight
- Audit trails
The agent can recommend or prepare.
A deterministic control can decide whether the action is allowed.
Agent Guardrails Should Be Architectural, Not Just Prompt-Based
This is an important lesson from enterprise AI architecture.
I wouldn’t rely solely on:
“We told the agent not to do that.”
Prompt instructions are not the same thing as enterprise controls.
For critical actions, enforcement should exist outside the model.
For example:
Agent
|
v
Request Action
|
v
Policy / Authorization Layer
|
+---- Allowed ----> Execute
|
+---- Not Allowed -> Escalate
The agent can reason.
The platform still controls what the agent is permitted to do.
That separation is essential.
Observability Becomes More Important With Agents
Traditional automation is relatively easy to inspect.
You can look at the Flow and understand the path.
With an agent, you need to understand more:
- What input did it receive?
- What context did it use?
- Which tools did it call?
- What decision did it make?
- What information influenced the decision?
- What action did it take?
- Did it retry?
- Why did it stop?
- Why did it escalate?
Agent observability therefore becomes a first-class architectural capability.
If the business cannot explain why an agent took an action, I would hesitate to give that agent significant autonomy.
Testing Changes Too
Testing a workflow is relatively straightforward.
Given:
Input X
Expected:
Output Y
Agent testing is different.
The same intent can be expressed in many ways.
The agent may encounter different context.
The tool response may vary.
The reasoning path may change.
Therefore, agent testing needs:
- Scenario-based evaluation
- Negative cases
- Boundary conditions
- Tool failure testing
- Security testing
- Prompt/instruction regression testing
- Hallucination testing
- Outcome-based evaluation
This is one reason why an agent should not automatically replace a workflow that already works well.
A Simple Decision Framework
When deciding between an agent and workflow, I usually ask:
Is the path known?
If yes, lean toward workflow.
If no, consider an agent.
Are the rules explicit?
If yes, workflow.
If interpretation is required, agent.
Is the input predictable?
If yes, workflow is usually sufficient.
If natural language and unstructured context dominate, agent becomes more attractive.
Is the outcome deterministic?
If yes, workflow.
If multiple valid paths exist depending on context, agent.
Is the action high-risk?
If yes, prefer deterministic controls even if an agent participates.
Does the process need adaptation?
If yes, agent may add meaningful value.
Does the process change frequently?
If business rules change frequently but remain deterministic, configuration/workflow may still be better.
Does the process require understanding?
If the system needs to interpret language, intent, context or ambiguous information, agent becomes more compelling.
My Decision Matrix
| Dimension | Workflow | Agent |
|---|---|---|
| Predictability | Excellent | Variable |
| Deterministic rules | Excellent | Usually unnecessary |
| Structured processes | Excellent | Often unnecessary |
| Natural-language input | Limited | Strong |
| Ambiguous requests | Limited | Strong |
| Adaptive decisions | Limited | Strong |
| Auditability | Strong | Requires additional design |
| Explainability | Strong | Requires additional controls |
| Performance predictability | Strong | Variable |
| Cost predictability | Strong | Requires monitoring |
| Complex reasoning | Limited | Strong |
| Tool orchestration | Strong | Strong |
| Autonomous decision-making | Limited | Strong |
| Compliance-sensitive execution | Strong | Requires guardrails |
| Maintenance | Predictable | More sophisticated |
Again, this isn’t a rulebook.
It is a way to frame the architecture conversation.
The “Agent Everywhere” Anti-Pattern
One of the patterns I would actively avoid is converting every Salesforce automation into an agent.
Imagine:
Update Account Owner → Agent
Create Case → Agent
Send notification → Agent
Update Status → Agent
Create Task → Agent
This adds reasoning where none is required.
It also introduces unnecessary:
- Cost
- Latency
- Variability
- Testing
- Monitoring
- Security considerations
There is nothing intelligent about using intelligence where deterministic automation is already the better tool.
The “Workflow Everywhere” Anti-Pattern
The opposite can be just as problematic.
Suppose a business process requires:
Understand customer intent → interpret unstructured information → research multiple systems → evaluate possible resolutions → determine next action.
Trying to represent every possible path using hundreds of workflow branches can become unmanageable.
At some point, we are effectively trying to encode human reasoning as a decision tree.
That is where I would start looking at agentic architecture.
Think in Terms of Decision Density
One concept I find useful is decision density.
A process with low decision density has:
- Few decisions
- Known paths
- Stable rules
- Predictable inputs
Workflow is usually ideal.
A process with high decision density has:
- Many possible paths
- Context-dependent decisions
- Unstructured input
- Exceptions
- Dynamic information
- Multiple possible outcomes
That is where agents start becoming valuable.
The higher the decision density, the stronger the case for adaptive reasoning.
Another Useful Concept: Reversibility
I also consider whether an action can be reversed.
If an agent makes a recommendation that a human reviews, the risk is relatively low.
If an agent changes a customer record, that is more significant.
If an agent sends an irreversible financial transaction, the architecture becomes much more sensitive.
A useful principle is:
The less reversible the action, the more deterministic control you should put around the agent.
The agent may still provide intelligence.
The final execution path should remain tightly controlled.
Where This Fits in Salesforce Architecture
I see the emerging Salesforce architecture looking something like this:
Customer / Employee
|
v
Agent Experience
|
v
Reasoning Layer
|
+------------+------------+
| |
v v
Data / Context Tools
| |
v v
Data 360 / CRM Flow / Apex / APIs
|
v
Enterprise Systems
This architecture is interesting because it doesn’t require us to replace existing Salesforce engineering practices.
Instead, agents become another layer above them.
The agent determines what needs to happen.
Existing deterministic services determine how the action is safely executed.
My Rule of Thumb
My personal rule is simple:
If I can describe the process as a flowchart with stable decision points, I probably don’t need an agent.
If I find myself drawing:
“If this, then this. Unless that. Except when the customer says this. Unless the previous interaction indicates something else…”
then I start asking whether the problem is really a workflow problem anymore.
At that point, adaptive reasoning may provide real value.
But I still don’t let the agent own everything.
I separate:
Reasoning
from
Execution
and
Control.
That separation is becoming increasingly important in enterprise agent architecture.
The Future Isn’t Agent vs Workflow
I don’t think the future Salesforce architecture is going to be:
Agents replace Flow.
Nor:
Flow remains the center of everything.
I expect the architecture to become more layered.
Business Intent
|
v
Agent / AI
|
Understand / Reason
|
v
Deterministic Layer
|
+---------+---------+
| | |
v v v
Flow Apex APIs
| | |
+---------+---------+
|
v
Business Systems
The agent provides adaptability.
The deterministic layer provides reliability.
The underlying systems provide the actual business capabilities.
That combination is much more powerful than trying to make one technology responsible for everything.
Final Thought
The arrival of agents doesn’t make workflows obsolete.
It makes the distinction between execution and reasoning more important.
There are business processes where I want absolute predictability.
There are others where forcing every possibility into predefined rules creates brittle architecture.
The skill of the Salesforce architect is recognizing which is which.
My approach is therefore:
Use workflow when the business knows the path.
Use an agent when the system needs to determine the path.
Use both when reasoning is needed to decide what should happen, but deterministic automation is needed to execute it safely.
And perhaps the most important principle I would leave with an architecture team is this:
Don’t introduce an agent because the process can use AI. Introduce an agent because adaptive reasoning creates measurable business value that deterministic automation cannot provide economically or maintainably.
That distinction will become increasingly important as Salesforce moves from traditional automation toward agentic enterprise architectures.