Salesforce Agentforce Architecture: Components, Data Flow, Agents, Actions, Data 360 & Security

Salesforce Agentforce architecture is fundamentally different from a traditional CRM automation architecture.

A conventional Salesforce automation might look like:

Record Change → Flow → Action → Record Update

An Agentforce architecture can look more like:

User / Event → Agent → Reasoning → Context → Action → Business System → Result

The difference is that an agent can interpret an objective, determine which capability is relevant, retrieve the required context and execute approved actions.

Salesforce describes Agentforce as an agent-driven layer of the Salesforce Platform, with agents designed to work across sales, service, marketing, commerce, Slack and other business experiences.

For enterprise deployments, however, Agentforce should not be viewed as an isolated AI component.

A mature architecture may involve:

• Salesforce CRM
• Agentforce
• Data 360
• Salesforce Flow
• Apex
• APIs
• MuleSoft
• Knowledge
• External applications
• RAG and retrieval
• Security controls
• Human approval
• Monitoring and observability

This makes architecture one of the most important decisions in an Agentforce implementation.

What Is Salesforce Agentforce Architecture?

Salesforce Agentforce architecture defines how AI agents interact with users, business data, enterprise systems, actions, workflows, security controls and other agents.

At a simplified level:

USERS / EVENTS
│
▼
┌──────────────────┐
│    Agentforce    │
│      Agent       │
└────────┬─────────┘
│
┌──────────┼──────────┐
▼          ▼          ▼
Subagents   Knowledge   Context
│          │          │
└──────────┼──────────┘
▼
Reasoning Layer
│
┌──────────┼──────────┐
▼          ▼          ▼
Flow       Apex       APIs
│          │          │
└──────────┼──────────┘
▼
Salesforce / External
Systems
│
▼
Business
Outcome

The actual architecture depends on the use case.

A simple Salesforce-native service agent may require only CRM data, knowledge and Flow.

A complex enterprise agent may require Data 360, external APIs, MuleSoft, multiple specialized agents and human approval.

Agentforce Architecture: Core Components

A practical Agentforce architecture consists of several layers.

1. Experience Layer

This is where users or systems interact with the agent.

Possible surfaces include:

• Website
• Messaging
• Salesforce applications
• Mobile applications
• Slack
• Customer portals
• Employee interfaces
• APIs
• Event-driven processes

Salesforce identifies channels as one of the core components that determine where an agent gets work done.

2. Agent Layer

The agent represents the business capability.

An agent has:

• A defined role
• Instructions
• Knowledge
• Subagents
• Actions
• Variables
• Guardrails
• Context
• Channels

Salesforce's current Agentforce documentation identifies role, knowledge, actions, guardrails and channels as key components of an agent.

For example:

Service Agent

Goal:

Resolve customer service requests.

Capabilities:

• Find customer
• Retrieve case
• Search knowledge
• Check order
• Create case
• Escalate

The architecture should keep this scope clear.

3. Subagent Layer

Salesforce changed the terminology from topics to subagents beginning in April 2026. Salesforce notes that the underlying functionality did not change during this terminology transition.

A subagent represents a specialized area of responsibility.

For example:

Customer Service Agent → Order Subagent → Returns Subagent → Billing Subagent → Technical Support Subagent

This is particularly useful for complex enterprise implementations.

Instead of building one enormous agent, responsibilities can be separated.

4. Instructions Layer

Instructions define how the agent should behave.

For example:

Verify the customer's identity before accessing account information.

Or:

Never issue a refund above the approved threshold without human approval.

Good instructions should define:

• Objective
• Scope
• Allowed behavior
• Restrictions
• Escalation conditions
• Required information
• Business rules

Instructions should not be treated as a replacement for deterministic business logic.

High-risk rules should be enforced through appropriate platform controls and workflows.

5. Action Layer

Actions are what allow an agent to do work.

Salesforce describes actions as predefined tasks an agent can execute, including capabilities such as running a Flow, using a prompt template or invoking Apex.

Examples include:

• Query a record
• Create a case
• Update an opportunity
• Run a Flow
• Invoke Apex
• Call an API
• Send a message
• Retrieve information
• Trigger another process

This is one of the most important architectural distinctions.

An LLM can generate an answer.

An action connects that answer to a real business operation.

Agentforce Action Architecture

A typical action flow looks like:

Agent
│
▼
Determine required action
│
▼
Action
│
├── Flow
│
├── Apex
│
├── Salesforce API
│
├── External API
│
└── Other Agent
│
▼
Business System
│
▼
Result
│
▼
Agent

Salesforce's current architecture guidance describes actions as hooks that can access data, call flows, invoke external systems and call other agents.

6. Data Layer

The agent needs context to perform useful work.

This can include:

Salesforce Data

• Accounts
• Contacts
• Leads
• Opportunities
• Cases
• Orders
• Assets
• Activities

Knowledge

• Knowledge articles
• Policies
• Documentation
• Product information
• Internal procedures

Data 360

• Unified profiles
• Data model
• Data graphs
• Calculated insights
• External data
• Real-time information
• Retrieval data

External Systems

• ERP
• HR systems
• Payment platforms
• Data warehouses
• Order management
• Custom applications

The right data architecture depends on the use case.

7. Data 360 Layer

Data 360 can provide a broader context layer for Agentforce.

Salesforce's architecture documentation describes Data 360 as a foundation for agentic experiences, including unified data, external data, unstructured information and profile-based context.

A simplified architecture is:

CRM ──────────────┐
│
ERP ──────────────┤
│
Website ──────────┤
▼
Data 360
│
┌──────────┼──────────┐
▼          ▼          ▼
Unified     Data       Retrieval
Profile     Graphs      / RAG
│          │          │
└──────────┼──────────┘
▼
Agentforce

Data 360 is especially useful when the agent needs context that does not exist in a single Salesforce object.

8. Retrieval and Knowledge Layer

An enterprise agent frequently needs unstructured information.

Examples:

• Product manuals
• Policies
• Contracts
• Knowledge articles
• Support documentation
• Internal guides

Retrieval mechanisms allow the agent to obtain relevant information rather than relying only on the model's general knowledge.

Salesforce's current agentic architecture guidance describes Data 360 components, including vector stores and RAG retrievers, as ways to provide agents with structured and unstructured enterprise context.

9. Integration Layer

Most enterprise Agentforce implementations eventually encounter external systems.

Common integrations include:

• SAP
• NetSuite
• Microsoft Dynamics
• Oracle
• Workday
• ServiceNow
• Custom APIs
• Data warehouses
• Payment systems

A useful pattern is:

Agentforce
│
▼
Action
│
▼
MuleSoft
│
┌────────────┼────────────┐
▼            ▼            ▼
SAP        NetSuite      Custom API

Salesforce's architecture guidance positions MuleSoft as a bridge between Agentforce and external systems, including through modern interoperability patterns such as MCP.

10. Automation Layer

Agentforce should work with existing Salesforce automation rather than automatically replacing it.

Common technologies include:

• Flow
• Apex
• Platform Events
• APIs
• Webhooks
• Data Actions
• Approval processes

The principle is straightforward:

Use AI for reasoning and flexible interaction.

Use deterministic automation for predictable execution.

For example:

Agent

"Customer wants to change delivery address." → Flow

Validate eligibility. → API

Update logistics system. → Agent

Confirm the result.

11. Security Layer

Security is a fundamental part of Agentforce architecture.

Salesforce states that Agentforce integrates with the Einstein Trust Layer and that agents respect standard Salesforce access controls.

Security architecture should consider:

• User permissions
• Profiles
• Permission sets
• Role hierarchy
• Field-level security
• Record-level access
• Data classification
• Sensitive information
• Agent permissions
• External API credentials
• Human approval
• Auditability

Salesforce's security documentation also describes a shared-responsibility model in which Salesforce provides the foundational platform while administrators configure access, permissions and agent-specific controls.

12. Einstein Trust Layer

The Einstein Trust Layer provides security and privacy controls around generative AI interactions.

Salesforce documents capabilities including:

• Data protection
• Zero data retention policies with participating third-party LLM providers
• Toxicity detection
• Prompt injection detection
• Audit trails
• Grounded responses

This matters because Agentforce may interact with sensitive enterprise information.

13. Guardrails

Guardrails limit what an agent can do.

Examples:

Do not:

• Reveal sensitive information
• Modify protected records
• Approve high-value transactions
• Issue unauthorized refunds
• Bypass approval
• Expose internal information

Do:

• Verify identity
• Use approved knowledge
• Follow business rules
• Escalate exceptions
• Request human approval

Salesforce's current agentic architecture documentation describes guardrails as configurable rules and runtime checks that constrain agent behavior.

14. Human Escalation Layer

Enterprise agents should have a clear path to humans.

Example:

Customer
│
▼
Agentforce
│
├── Routine request
│        │
│        ▼
│     Automated action
│
└── Exception
│
▼
Human Agent
│
▼
Resolution

A good escalation architecture preserves:

• Conversation history
• Customer context
• Actions already performed
• Reason for escalation
• Relevant records

The human should not have to restart the entire conversation.

Agentforce Architecture Data Flow

Let's take a customer-service example.

Step 1: Customer Sends Request

"My order hasn't arrived."

Step 2: Agent Identifies Intent

Potential intent:

Order Status

Step 3: Retrieve Context

The agent retrieves:

• Customer
• Order
• Shipment
• Delivery estimate

Step 4: Determine Action

The agent identifies that tracking information is required.

Step 5: Execute Action

The action calls:

Order Management API

Step 6: Receive Result

Order: 58473

Status: Delayed

Expected delivery: Friday

Step 7: Generate Response

The agent explains the situation.

Step 8: Escalate if Required

If the order is beyond a defined threshold:

Create Case → Human Service Representative

This is the basic Agentforce architecture pattern.

Agentforce Architecture Diagram for Enterprise CRM

A more complete enterprise architecture looks like this:

CUSTOMER / EMPLOYEE
│
┌────────────────┼────────────────┐
▼                ▼                ▼
Website          Salesforce         Slack
│                │                │
└────────────────┼────────────────┘
▼
┌─────────────────┐
│   Agentforce    │
│     Agent       │
└────────┬────────┘
│
┌────────────────┼─────────────────┐
▼                ▼                 ▼
Subagents        Knowledge          Context
│                │                 │
└────────────────┼─────────────────┘
▼
Reasoning Layer
│
┌────────────────┼─────────────────┐
▼                ▼                 ▼
Flow            Apex              APIs
│                │                 │
└────────────────┼─────────────────┘
▼
┌────────────────────┐
│    Data / Systems  │
└─────────┬──────────┘
│
┌─────────────────┼──────────────────┐
▼                 ▼                  ▼
Salesforce         Data 360          External
CRM                                  Systems
│
SAP / ERP / APIs

Agentforce Multi-Agent Architecture

Large enterprises may require more than one agent.

For example:

Supervisor Agent
│
┌───────────────┼───────────────┐
▼               ▼               ▼
Sales Agent      Service Agent    Finance Agent
│               │               │
▼               ▼               ▼
CRM Actions      Case Actions     ERP Actions

This allows each agent to specialize.

Salesforce's architecture guidance describes multi-agent orchestration as a core design pattern for Agentforce and identifies specialization and decomposition as ways to manage complexity and improve reliability.

Supervisor and Specialist Agents

A supervisor agent can act as the entry point.

For example:

Customer asks:

"I want to change my order and also update my billing address."

The supervisor can determine that the request contains two responsibilities.

Supervisor → Order Specialist → Billing Specialist

Each specialist operates within its defined scope.

This is preferable to creating one giant agent with hundreds of unrelated responsibilities.

Single-Agent vs Multi-Agent Architecture

Start with a single focused agent unless the business process genuinely requires specialization.

Agentforce and MCP

Modern Agentforce architectures can also use interoperability mechanisms such as the Model Context Protocol (MCP).

MCP can help agents interact with external tools and systems through standardized interfaces.

For enterprise architecture, this creates a potential pattern:

Agentforce
│
▼
MCP Client
│
▼
MCP Server
│
▼
External Tool / System

Salesforce's current architecture guidance includes MCP among its interoperability patterns for connecting agents to external functionality.

The appropriate integration method should still be selected based on security, latency, system ownership and operational requirements.

Agentforce and APIs

APIs remain important for enterprise Agentforce implementations.

An agent may need to:

• Query external information
• Create a transaction
• Update a record
• Check availability
• Submit a request
• Retrieve status

Salesforce provides Agentforce APIs and SDKs for building, testing and using agents programmatically. Its current developer documentation includes Agent Script, Agentforce DX, Python SDK, Testing API and Agent API.

Agentforce Architecture and Event-Driven Automation

Not every agent interaction begins with a user message.

An agent can also respond to events.

Example:

Opportunity changes stage → Event → Agentforce → Check opportunity completeness → Identify missing information → Notify salesperson → Create task

This enables proactive agent behavior.

Salesforce's current agentic architecture documentation describes event-driven patterns using sources such as Platform Events, Change Data Capture and other event mechanisms.

Proactive Agent Architecture

A proactive architecture can look like:

CRM / External Event
│
▼
Event Platform
│
▼
Agentforce
│
▼
Context Retrieval
│
▼
Decision / Reasoning
│
▼
Action
│
▼
Business Outcome

Example:

High-priority case approaching SLA → Agent identifies risk → Retrieves case context → Checks customer history → Notifies responsible team → Escalates if required

This is different from waiting for a customer to ask for help.

Agentforce Architecture for Real-Time Use Cases

Real-time scenarios may require:

• Event ingestion
• Real-time data
• Low-latency APIs
• Data 360
• Data Graphs
• Streaming information
• Fast action execution

Data 360's architecture supports real-time and event-oriented data patterns that can provide context for agentic experiences.

For example:

Customer enters website → Customer identified → Recent activity retrieved → Agent receives context → Recommendation generated → Action performed

The architecture must be designed around the required latency rather than simply adding more systems.

Agentforce Architecture for RAG

Retrieval-Augmented Generation, or RAG, can help ground agent responses in enterprise information.

The pattern is:

User Request
│
▼
Agentforce
│
▼
Retrieve Relevant Information
│
├── CRM
├── Knowledge
├── Data 360
└── External Data
│
▼
Context
│
▼
Reasoning
│
▼
Response / Action

The benefit is that the agent can use current, relevant business information rather than relying exclusively on general model knowledge.

Agentforce Architecture and Knowledge

Knowledge should be treated as an architectural component.

Before implementation, identify:

• Where knowledge lives
• Who owns it
• How often it changes
• Whether it is approved
• Whether conflicting versions exist
• Whether access restrictions apply

Poor knowledge architecture can create poor agent outcomes even when the agent itself is technically well configured.

Agentforce Security Architecture

A secure Agentforce architecture should operate across multiple layers.

Layer 1: Identity

Who is interacting with the agent?

Layer 2: Authorization

What is that user allowed to access?

Layer 3: Data Security

Which records and fields can the agent access?

Layer 4: Action Security

What actions can the agent execute?

Layer 5: AI Security

How are prompts, responses and sensitive information protected?

Layer 6: Governance

How are agent actions monitored and audited?

Salesforce states that Agentforce agents operate within Salesforce's broader security model and can inherit user permissions, role hierarchies and field-level security.

Agentforce Architecture: Permissions Matter

One of the biggest mistakes is treating the agent as a separate security boundary.

An agent that can access sensitive information needs carefully designed permissions.

For example:

Agent can read:

• Account
• Contact
• Order

Agent cannot read:

• Sensitive financial fields
• Internal employee information
• Restricted records

And:

Agent can create:

• Service cases

Agent cannot approve:

• High-value refunds

Security should be designed before the agent is deployed.

Agentforce Architecture Best Practices

1. Start With the Business Process

Do not start by drawing the technology stack.

Start with:

What should the agent accomplish?

2. Keep Agent Scope Narrow

A focused agent is easier to test, monitor and govern.

3. Separate Reasoning From Deterministic Logic

Use:

Agentforce

for flexible reasoning.

Use:

Flow / Apex / APIs

for deterministic execution.

4. Give Agents Only Required Access

Apply least-privilege principles.

5. Treat Data Quality as Architecture

Bad data produces poor decisions.

6. Design Human Escalation

Do not make human handoff an afterthought.

7. Make Actions Explicit

Every action should have:

• Purpose
• Inputs
• Outputs
• Permissions
• Failure behavior
• Audit requirements

8. Build for Observability

Monitor:

• Agent interactions
• Actions
• Errors
• Escalations
• Response quality
• Business outcomes

9. Test Failure Scenarios

Don't test only successful conversations.

Test:

• Missing data
• Wrong information
• Unauthorized requests
• Prompt injection
• API failures
• Conflicting data
• Ambiguous requests
• Human escalation

Salesforce's current implementation guidance includes testing as a distinct phase of the Agentforce lifecycle, with Testing Center and other testing capabilities available for agent validation.

Common Agentforce Architecture Mistakes

Mistake 1: One Giant Agent

Trying to create one agent for every department creates unnecessary complexity.

Mistake 2: Using AI Where Flow Is Better

If the rule is deterministic, keep it deterministic.

Mistake 3: Ignoring External Systems

Enterprise processes rarely live entirely inside Salesforce.

Mistake 4: Adding Data 360 Without a Data Requirement

Data 360 should solve a real context problem.

Mistake 5: Over-Permissive Agents

The agent should not have unrestricted access.

Mistake 6: No Human Escalation

Every important agent should have defined exception paths.

Mistake 7: No Observability

If you cannot understand what the agent did, optimization becomes difficult.

Agentforce Architecture Implementation Roadmap

A practical implementation can follow this sequence.

Phase 1: Use-Case Definition

Define:

• Business problem
• User
• Agent responsibility
• Expected outcome
• KPIs

Phase 2: Architecture Discovery

Map:

• Salesforce objects
• Data sources
• Knowledge
• APIs
• External systems
• Existing automation

Phase 3: Security Design

Define:

• Users
• Permissions
• Data access
• Action permissions
• Sensitive information
• Human approvals

Phase 4: Agent Design

Define:

• Role
• Instructions
• Subagents
• Actions
• Guardrails
• Variables
• Channels

Salesforce's current Agentforce Builder supports configuring agent instructions, subagents, actions and variables, as well as preview and testing workflows.

Phase 5: Data and Integration

Connect:

• Salesforce
• Data 360
• Knowledge
• APIs
• External applications
• Integration middleware

Phase 6: Testing

Test:

• Normal scenarios
• Edge cases
• Security
• Permissions
• Actions
• API failures
• Escalations
• Performance

Phase 7: Deployment

Deploy to:

• Internal users
• Customer channels
• Website
• Messaging
• Slack
• Other approved interfaces

Phase 8: Monitoring

Track:

• Adoption
• Resolution
• Escalation
• Errors
• Action success
• Customer satisfaction
• Business KPIs

Agentforce Architecture Checklist

Business

• Business problem defined
• Agent responsibility defined
• Success KPI defined
• Human ownership defined

Data

• Salesforce data identified
• External data identified
• Knowledge sources identified
• Data quality reviewed
• Data 360 requirement assessed

Agent

• Agent role defined
• Instructions defined
• Subagents defined
• Actions defined
• Guardrails defined
• Variables defined

Integration

• Flow requirements defined
• Apex requirements defined
• APIs identified
• MuleSoft requirements assessed
• External systems mapped

Security

• User access reviewed
• Record access reviewed
• Field-level security reviewed
• Action permissions reviewed
• Sensitive data identified
• Human approvals defined

Testing

• Functional testing
• Security testing
• Edge-case testing
• Prompt injection testing
• Integration testing
• User acceptance testing

Operations

• Monitoring
• Logging
• Error handling
• Escalation
• Feedback loop
• Optimization process

How MoreYeahs Can Support Agentforce Architecture

Agentforce architecture becomes particularly important when AI needs to operate across Salesforce and external enterprise systems.

MoreYeahs' Salesforce services include Salesforce implementation, custom object and workflow design, data migration and validation, marketing automation, analytics, training and adoption, and managed support.

MoreYeahs also states that it has built dozens of Salesforce integrations with SAP, NetSuite, Dynamics 365 and custom systems using real-time API, near-real-time middleware and batch integration patterns.

That experience is relevant for Agentforce architectures where the agent must move beyond Salesforce CRM data.

A practical architecture might therefore combine:

Agentforce → Salesforce CRM → Data 360 → Flow / Apex → Enterprise Integrations → Security and Governance → Human Oversight

The objective should not be to create the most complicated agent architecture.

It should be to create the simplest architecture capable of reliably delivering the required business outcome.

Final Takeaway

A successful Agentforce architecture is not simply:

LLM + Salesforce

It is:

Agent → Business Context → Trusted Data → Actions → Enterprise Systems → Security → Human Oversight

The strongest architecture uses each technology for what it does best.

Agentforce handles flexible reasoning and agentic interaction.

Data 360 provides broader enterprise context where required.

Flow and Apex handle deterministic Salesforce processes.

APIs and MuleSoft connect external systems.

Knowledge and retrieval provide grounded information.

Security and guardrails control what the agent can see and do.

Human escalation handles exceptions and high-risk decisions.