One of the architecture questions I expect to hear much more frequently over the next few years is:
“Should we build this agent in Agentforce or build it outside Salesforce?”
This sounds like a product selection question.
I don’t think it is.
It is really a question about where the intelligence should live, which platform should own the interaction, what data the agent needs, what tools it should be allowed to use, and where the enterprise wants its security boundary to sit.
This distinction matters because an enterprise agent rarely operates in isolation.
A customer might start in Salesforce, but the information required to solve the problem could live in SAP, an enterprise data platform, ServiceNow, a billing system, a custom application, or another SaaS platform.
Similarly, an employee might start outside Salesforce but need Salesforce customer or opportunity information to complete a task.
So the architecture question is not:
“Can Agentforce do this?”
The more useful question is:
“Where should this agent belong?”
That is the question I would start with.
Agentforce and External Agents Are Not the Same Architectural Choice
I think about the distinction this way.
Agentforce
Salesforce is the natural business context, system boundary and execution environment for the agent.
External Agent
The business capability spans multiple enterprise platforms, and the agent needs to operate independently of Salesforce.
There can obviously be overlap.
An Agentforce agent can interact with external systems.
An external agent can interact with Salesforce.
So the decision is not really about technical capability.
It is about architectural ownership.
The First Question I Ask
When someone proposes an external AI agent for a Salesforce use case, I ask:
“Why does this agent need to live outside Salesforce?”
And when someone proposes Agentforce for an enterprise-wide use case, I ask the opposite:
“Why should Salesforce own this agent?”
Those two questions often reveal the right direction surprisingly quickly.
When Agentforce Is the Natural Choice
Agentforce becomes a strong candidate when the agent is fundamentally centered around Salesforce business processes.
For example:
- Sales assistance
- Customer service
- Case resolution
- Account research
- Opportunity support
- Lead qualification
- Service knowledge
- Customer communication
- CRM data updates
- Salesforce workflow execution
- Customer-specific recommendations
Consider a service agent that needs to:
- Understand a customer’s issue.
- Review the customer’s account.
- Look at recent cases.
- Review relevant knowledge.
- Determine the likely resolution.
- Update the case.
- Create a follow-up task.
- Communicate the outcome.
If most of the context and actions are already inside Salesforce, I would seriously consider keeping the agent within the Salesforce platform boundary.
There is little architectural value in introducing another platform simply to put an AI layer in front of Salesforce.
When an External Agent Makes More Sense
Now consider an enterprise procurement agent.
It may need to:
- Search SAP
- Check supplier information
- Review contracts
- Query an enterprise data platform
- Check inventory
- Validate budgets
- Create a purchase request
- Interact with ServiceNow
- Notify users through collaboration tools
- Update Salesforce
Salesforce might be one of its systems.
But Salesforce isn’t necessarily its center.
In that situation, I would consider an external agent architecture.
The agent’s responsibility is broader than CRM.
Its tools and security boundaries may span the enterprise.
That is an important architectural signal.
Platform Fit
The first dimension I evaluate is platform fit.
Ask:
Where does the business process primarily live?
If the process is:
Salesforce → Salesforce → Salesforce
Agentforce is a natural candidate.
If the process is:
SAP → Data Platform → Salesforce → ServiceNow → Custom Application
then an external agent may make more sense.
The number of systems isn’t the only factor.
What matters is where the business capability is centered.
Don’t Confuse “Multiple Systems” With “External Agent Required”
This is an important nuance.
Agentforce doesn’t need to operate only on Salesforce data.
If a Salesforce service agent needs information from an external billing system, that doesn’t automatically mean we need an external agent.
The Agentforce architecture can potentially use tools, APIs and integrations to access external capabilities.
The question becomes:
Is Salesforce still the natural home for this business interaction?
If yes, Agentforce can still be the right choice.
This is why architecture should be based on business ownership, not simply the number of systems involved.
Data Access
Data access is probably the most important architectural consideration after platform fit.
An agent is only as useful as the context it can safely access.
For a Salesforce service scenario, the agent may need:
- Customer profile
- Contact information
- Cases
- Orders
- Assets
- Entitlements
- Knowledge
- Interaction history
- Customer activity
- Data 360 context
If this information is already available within Salesforce’s data and security model, Agentforce has a natural advantage.
But consider an enterprise agent that needs:
- ERP data
- Finance information
- Supply-chain data
- Product telemetry
- Data lake information
- MDM
- HR information
- CRM data
The architecture becomes broader.
An external agent may be better positioned to coordinate those sources.
Data Access Doesn’t Mean Data Ownership
This is a distinction I strongly recommend making.
An agent may access data without owning it.
For example:
Customer Master
|
v
MDM
|
+----------------+
|
v
Agentforce
|
v
Customer Service
Agentforce may consume customer information.
That doesn’t mean Salesforce should become the master of customer data.
Likewise, an external agent can access Salesforce data without becoming the owner of CRM data.
This separation is critical for enterprise architecture.
Data 360 Changes the Conversation
Data 360 makes the Agentforce decision even more interesting.
If customer data from multiple sources has already been unified and made available within Salesforce, the amount of context available to a Salesforce-based agent becomes much richer.
For example:
CRM
ERP
Web
Service
Marketing
External Data
|
v
Data 360
|
v
Agentforce
|
v
Customer Action
This can significantly strengthen the case for Agentforce.
But again, I wouldn’t interpret that as:
“All enterprise data must move into Data 360.”
The architecture should still respect source ownership and enterprise boundaries.
Tools Matter More Than Models
When evaluating agents, architects often spend too much time discussing the underlying AI model.
I think the more important question is:
What can the agent actually do?
An agent needs tools.
Those tools might include:
- Salesforce actions
- Flow
- Apex
- APIs
- Data queries
- Knowledge search
- External services
- Enterprise applications
- Integration services
- Custom functions
A powerful model without useful tools isn’t a useful enterprise agent.
The architecture should therefore define the agent’s tool boundary.
Agentforce Tool Boundary
A Salesforce-centric agent might look like:
Agentforce
|
+---------------+---------------+
| | |
v v v
CRM Data Flow/Apex Data 360
| | |
+---------------+---------------+
|
External APIs
The agent reasons about the task.
Salesforce provides the tools.
The tools perform the actual business operations.
That separation creates a useful control boundary.
External Agent Tool Boundary
An enterprise agent may look more like:
External Agent
|
+------------------+------------------+
| | | |
v v v v
Salesforce SAP Data Platform ServiceNow
| | | |
+----------+----------+---------------+
|
Enterprise Action
Here, Salesforce is one tool among several.
That is a strong indicator that the agent may belong outside Salesforce.
The Number of Tools Is Not the Only Factor
An Agentforce agent can technically call multiple external systems.
An external agent can technically call Salesforce.
So simply counting integrations isn’t enough.
I look at:
- Who owns the business capability?
- Which platform owns the user interaction?
- Where is the primary context?
- Where are the critical controls?
- Which platform should audit the actions?
- Which team will operate the agent?
These questions provide a much stronger architectural signal.
Security Boundary
This is where the decision becomes much more serious.
An agent is not just another application.
It can potentially:
- Read data
- Create records
- Update records
- Invoke APIs
- Send messages
- Initiate workflows
- Execute transactions
Therefore, the agent needs a clearly defined security boundary.
For Agentforce, Salesforce’s existing identity, permissions, sharing and platform security model can become an important part of that boundary.
This can be particularly attractive when the agent is primarily working with Salesforce data and actions.
An external agent requires its own security architecture around:
- Identity
- Authentication
- Authorization
- Secrets
- API access
- Tool permissions
- Network access
- Data filtering
- Audit logging
That isn’t necessarily a reason to avoid external agents.
It is simply part of the architectural cost.
Never Give an Agent More Access Than It Needs
This principle applies regardless of platform.
Suppose a service agent only needs to:
- Read customer details
- Read cases
- Search knowledge
- Update case status
- Create follow-up tasks
It shouldn’t have:
- Full CRM administrator privileges
- Unrestricted customer data access
- Financial system write access
- Database-level credentials
I prefer capability-based access.
The agent should receive access to specific tools for specific business actions.
For example:
Agent
|
+---- Read Customer
|
+---- Read Cases
|
+---- Search Knowledge
|
+---- Update Case
|
+---- Create Task
This is much safer than giving the agent broad platform access.
Enterprise Boundaries
This is probably the area where the Agentforce versus external-agent decision becomes most interesting.
Large enterprises rarely have one technology boundary.
They have:
- CRM boundaries
- ERP boundaries
- Data boundaries
- Security boundaries
- Regional boundaries
- Regulatory boundaries
- Business-unit boundaries
An agent that crosses these boundaries needs explicit architectural governance.
For example:
Enterprise Agent
|
+--------------+--------------+
| | |
v v v
CRM ERP Data Platform
| | |
Customer Data Financial Data Analytical Data
The agent becomes a cross-domain orchestrator.
At that point, the organization needs to decide who owns that agent.
That may no longer naturally be Salesforce.
Regional and Regulatory Boundaries
This becomes particularly important for global enterprises.
An agent may need to operate across:
- Countries
- Data residency zones
- Business units
- Legal entities
- Regulatory regimes
For example, customer information may be subject to different rules depending on geography.
The agent architecture needs to understand:
Which data can this agent access?
From which region?
For what purpose?
Under which identity?
For how long?
These aren’t merely AI questions.
They are enterprise security and data governance questions.
Agent Identity
One architectural issue I would pay particular attention to is who the agent is acting as.
There is a big difference between:
Agent acting with the user’s permissions
and:
Agent acting using a shared technical identity.
The first provides stronger user-contextual authorization.
The second can be operationally easier but potentially creates excessive privileges.
For sensitive operations, I strongly prefer architectures where authorization remains connected to the actual user, business role and permitted capability.
The agent should not become a back door around existing security controls.
Human-in-the-Loop
Agent autonomy should also depend on the risk of the action.
For example:
Low risk
Search knowledge and summarize a case.
Agent can probably act autonomously.
Moderate risk
Update case classification and create a follow-up task.
Agent can potentially act within defined permissions.
High risk
Issue a customer refund.
Additional controls may be appropriate.
Very high risk
Approve a large financial transaction.
I would expect strong deterministic controls and potentially human approval.
A useful pattern is:
Agent
|
v
Understand / Recommend
|
v
Policy Check
|
+---- Low Risk ----> Execute
|
+---- High Risk ---> Human Approval
This pattern can work whether the agent is implemented in Agentforce or externally.
Where Agentforce Has an Architectural Advantage
I see several areas where Agentforce can have a natural advantage.
Salesforce-native context
The agent operates close to CRM data and processes.
Salesforce security model
The platform already has mature concepts around users, permissions and access.
Salesforce actions
The agent can work with existing Salesforce capabilities rather than building a separate application layer for every action.
CRM experience
If the agent is primarily supporting Salesforce users or customer interactions, keeping it within the Salesforce ecosystem can reduce architectural friction.
Operational ownership
Salesforce teams can potentially manage the agent using familiar platform governance.
These advantages can make a Salesforce-native agent particularly compelling for CRM-centric use cases.
Where an External Agent Has an Architectural Advantage
External agents can become attractive when:
The business capability is enterprise-wide
The agent isn’t fundamentally a CRM capability.
Salesforce is only one system
The agent needs equal access to multiple enterprise platforms.
The interaction starts outside Salesforce
For example, an employee, customer or application may interact with the agent through another channel.
Enterprise orchestration is central
The agent is coordinating multiple business domains rather than executing Salesforce processes.
Existing AI infrastructure already exists
The organization may already have:
- AI gateways
- Model infrastructure
- Agent frameworks
- Enterprise tool registries
- AI observability
- Security controls
- Prompt management
- Evaluation platforms
In that situation, duplicating the infrastructure inside Salesforce may not be the best architectural choice.
The “External Agent by Default” Anti-Pattern
Some organizations are tempted to build every enterprise agent externally because:
“We want AI to be independent of Salesforce.”
That can be a valid strategic direction.
But it can also create unnecessary architecture.
If the agent primarily works with:
- Salesforce data
- Salesforce users
- Salesforce processes
- Salesforce permissions
- Salesforce actions
then building another agent platform outside Salesforce may introduce an unnecessary layer.
You might end up with:
User
|
External Agent
|
Salesforce
|
Flow / Apex / Data 360
when the agent could potentially have lived closer to the business context.
The extra layer isn’t automatically bad.
But it needs to provide real value.
The “Agentforce for Everything” Anti-Pattern
The opposite is equally dangerous.
An organization may say:
“We are a Salesforce shop, so every agent should be Agentforce.”
Then the agent becomes responsible for:
- ERP processes
- HR
- Finance
- Supply chain
- Enterprise reporting
- Infrastructure operations
- Security operations
At that point, Salesforce may no longer be the natural home.
The agent’s business boundary has expanded beyond CRM.
Architecture should recognize that.
The Hybrid Pattern
In many enterprises, I expect the answer to be hybrid.
For example:
Enterprise AI Layer
|
External Agent
|
+-------------+-------------+
| |
v v
Agentforce Enterprise Tools
| |
Salesforce SAP / ERP
Data 360 Data Platform
Flow/Apex ServiceNow
CRM APIs Other Systems
Or the relationship can work in the opposite direction:
Customer
|
v
Agentforce
|
+---- Salesforce Actions
|
+---- External Agent
|
+---- ERP
+---- Data Platform
+---- Other Enterprise Systems
The important point is that agents can become tools for other agents.
That is where agent architecture starts becoming more interesting.
Agent-to-Agent Architecture Needs Governance
Once multiple agents exist, another problem appears.
Suppose we have:
- Sales Agent
- Service Agent
- Finance Agent
- Procurement Agent
- Enterprise Customer Agent
Who decides which agent should handle a request?
Who is allowed to invoke another agent?
What context can be passed?
Who owns the final action?
How do we prevent loops?
For example:
Customer Agent
|
v
Sales Agent
|
v
Finance Agent
|
v
External Payment Service
This is powerful.
But without clear ownership, it can become extremely difficult to operate.
Agent-to-agent communication needs the same architectural discipline we have historically applied to APIs and events.
Treat Agent Capabilities Like APIs
This is one principle I expect to become increasingly important.
An agent should expose clearly defined capabilities.
For example:
Customer Service Agent
|
+-- getCustomerContext()
+-- getOpenCases()
+-- searchKnowledge()
+-- updateCase()
+-- createFollowUpTask()
Another agent shouldn’t need to know how those capabilities are internally implemented.
This creates a cleaner architecture.
The same principles we use for APIs—contract, authorization, observability and versioning—will increasingly apply to agent capabilities.
Observability
With an external agent, I would want to know:
- Which user initiated the request?
- Which agent handled it?
- Which tools were invoked?
- Which systems were accessed?
- Which data was retrieved?
- Which decisions were made?
- Which actions were executed?
- What failed?
- Was human approval required?
With Agentforce, the same conceptual requirements remain.
The platform doesn’t remove the need for observability.
It may simply provide more native capabilities around the Salesforce portion of the architecture.
Cost and Latency
Another factor I wouldn’t ignore is operational efficiency.
An agent that performs:
Agent
|
+--> Salesforce
|
+--> Data Platform
|
+--> ERP
|
+--> External API
|
+--> Salesforce
may introduce considerable latency.
Each tool invocation has a cost.
Each additional reasoning cycle can add time.
The architecture should therefore minimize unnecessary tool calls.
A well-designed agent should not behave like:
“Let me ask five systems for everything just in case.”
It should gather the minimum context necessary to make a good decision.
My Practical Decision Matrix
| Dimension | Agentforce | External Agent |
|---|---|---|
| Salesforce-centric process | Excellent fit | Possible |
| CRM customer interaction | Excellent fit | Possible |
| Salesforce-native data | Excellent fit | Requires integration |
| Salesforce actions | Excellent fit | Requires tools/APIs |
| Enterprise-wide orchestration | Situational | Strong fit |
| Multiple non-Salesforce systems | Strong with integration | Strong |
| Cross-domain business capability | Situational | Strong |
| Salesforce security context | Strong fit | Requires integration |
| Enterprise AI platform integration | Situational | Strong fit |
| Centralized enterprise agent governance | Depends on architecture | Potentially strong |
| Agent primarily serving Salesforce users | Strong fit | Often unnecessary |
| Agent primarily serving enterprise processes | Evaluate | Strong fit |
This should be treated as an architectural framework, not a product ranking.
A Simple Decision Tree
When someone asks me:
“Agentforce or external agent?”
I would walk through these questions:
What is the business capability?
|
v
Is Salesforce the center?
/ \
Yes No
| |
v v
Agentforce External Agent
|
v
Does it need external
enterprise capabilities?
/ \
No Yes
| |
v v
Agentforce Hybrid
Then I add the most important question:
Who should own the agent?
That can change the answer.
My Rule of Thumb
My personal rule is:
If the agent primarily understands Salesforce business context and acts on Salesforce capabilities, start with Agentforce.
If the agent’s primary responsibility is:
“Understand an enterprise request and coordinate multiple business platforms.”
then I would seriously consider an external agent.
If the agent needs both:
Salesforce intelligence + enterprise orchestration
then I would explore a hybrid architecture before making a final decision.
The Boundary Is More Important Than the Brand
I don’t think the most important question is:
“Agentforce vs External Agent.”
The more important question is:
“Where should the intelligence boundary sit?”
If the boundary is inside Salesforce, Agentforce may be the natural fit.
If the boundary crosses the enterprise, an external agent may be more appropriate.
If the boundary changes depending on the business capability, we may need both.
That is a much more useful way to approach the architecture.
Final Thought
I don’t see Agentforce and external agents as competitors.
I see them as different places where enterprise intelligence can live.
Agentforce makes a lot of sense when the agent is deeply connected to Salesforce’s customer context, security model and business processes.
External agents become more compelling when the agent needs to operate across enterprise boundaries and Salesforce is only one participant in a larger business capability.
And in many mature organizations, the eventual architecture may look like neither one nor the other.
It may look like:
Agentforce for Salesforce-native intelligence.
External agents for cross-enterprise intelligence.
APIs, Flow, Apex and enterprise services for deterministic execution.
Data platforms and Data 360 for the context that agents need.
The mistake I would avoid is choosing the agent platform first and then forcing the business architecture around it.
I would do the opposite.
Start with the business capability.
Identify the data.
Define the tools.
Establish the security boundary.
Determine who owns the decision.
Then decide where the agent should live.
For me, that is the difference between adding an AI agent to an architecture and actually designing an enterprise architecture around agents.