Agentforce, MCP, and retrieval-augmented generation are often presented as competing answers. They are not the same kind of thing. Agentforce is a Salesforce agent platform. Model Context Protocol is a standard way to expose tools and context to compatible AI systems. RAG is a pattern for retrieving relevant source material before a model answers.
A production Salesforce AI system may use one, two, or all three. The right decision starts by separating the layers of the workflow instead of comparing product names in one flat feature table.
Choose where the work happens, how identity travels, where context comes from, what can take action, and who approves risk. Then choose the products that satisfy those decisions.
The five layers buyers accidentally collapse
| Layer | Question | Examples |
|---|---|---|
| Work surface | Where does the person or customer begin? | Salesforce, Service Cloud, Slack, Claude, ChatGPT, web or mobile chat |
| Agent or orchestration runtime | What plans the work and coordinates tools? | Agentforce, an AI application, an API workflow, or deterministic orchestration |
| Connection and action | How does the runtime inspect or change business systems? | MCP tools, Salesforce actions, Flow, Apex, APIs, integration platforms |
| Knowledge and retrieval | How does the model obtain relevant unstructured context? | RAG over approved documents, knowledge articles, policies, or transcripts |
| Control plane | How are identity, permissions, evaluation, approval, logging, and recovery enforced? | Salesforce security, OAuth, tool allowlists, approval gates, monitoring, runbooks |
This layered view is the foundation of GAT's Salesforce + AI consulting approach. It keeps a buyer from purchasing an agent platform when the real need is search, purchasing a connector when the real need is workflow redesign, or building custom RAG when approved Salesforce records already contain the necessary context.
What Agentforce is for
Agentforce is the natural architecture candidate when the agent should live in Salesforce and use Salesforce-native data, actions, channels, and administration. Typical examples include a service agent embedded in a customer channel, an employee-facing agent grounded in approved business knowledge, or an internal workflow where Salesforce is both the user surface and control center.
The implementation is still more than creating a topic and writing instructions. Teams must define actions, grounding, permission behavior, escalation, evaluation, deployment, and ongoing ownership. Use Agentforce consultingwhen that native operating model fits the job—not simply because the data happens to be in Salesforce.
What MCP is for
MCP is useful when an AI work surface or runtime needs a standardized way to discover and call tools against Salesforce or other systems. A consultant may inspect metadata from Claude. A revenue leader may ask ChatGPT for authorized pipeline context. A custom agent may call a narrowly defined tool that creates a task, retrieves a case, or validates a proposed change.
MCP does not decide the business workflow, guarantee least privilege, or make every exposed action safe. Those properties depend on the server, the authenticated identity, tool implementation, model client, approval policy, and connected systems. OpenAI's current MCP guidance explicitly recommends limiting available tools and requiring approval for sensitive actions.
Use a packaged connector such as ApexGeniuswhen its Salesforce scope fits. Use custom MCP architecture and implementationwhen tools must encode specialized business behavior, span systems, or satisfy an organization-specific control model.
What RAG is for
RAG is appropriate when the answer depends on finding relevant passages in a changing body of unstructured information: policies, knowledge articles, clinical or service guidance, contracts, product documentation, transcripts, or implementation records. Retrieval can improve grounding and allow the response to show its sources.
RAG is not a replacement for Salesforce queries, deterministic rules, or transactional actions. If the question is “which open opportunities are missing a next step?” use structured CRM data. If it is “which approved policy passages apply to this case?” retrieval may be the right layer. If the workflow must then create and route work, it also needs an action layer.
GAT's AI engineering workcombines RAG, chat interfaces, evaluations, APIs, and Salesforce actions when the business needs a purpose-built experience rather than a generic assistant.
Five common architecture patterns
1. Salesforce team working from Claude or ChatGPT
Use the preferred AI work surface plus a Salesforce MCP connection. Start read-only, authorize users deliberately, constrain tool scope, and add approvals before record or metadata changes. RAG is optional and only needed for knowledge outside the structured org context.
2. Customer service agent inside Salesforce channels
Agentforce may provide the native runtime and channel integration. Add approved knowledge grounding, structured actions for case work, and a visible handoff into the human service queue. A custom chat interface may still be appropriate when the experience or identity model extends beyond the native channel.
3. Purpose-built customer, patient, or employee chatbot
Use a custom interface and orchestration layer, RAG for bounded knowledge, and APIs or MCP tools for Salesforce work. Keep consent, eligibility, routing, and other policy deterministic. Design human handoff and conversation-to-case continuity before polishing the bot personality. See the full Salesforce AI chatbot architecture.
4. Cross-system revenue or service workflow
Use Salesforce as the system of record while orchestration coordinates forms, enrichment, support, documents, billing, or messaging. MCP can expose bounded AI-callable tools, but deterministic integration remains the better choice for stable event movement, reconciliation, and retry.
5. Knowledge assistant with no operational action
A well-governed retrieval system may be sufficient. Do not add a broad Salesforce write surface just because the assistant can answer a useful question. Add actions only when a specific job, owner, approval path, and recovery method are clear.
A decision sequence that survives product changes
- Locate the user: Salesforce, an existing AI client, or a purpose-built experience.
- Name the job: retrieve, synthesize, recommend, draft, transact, or coordinate.
- Classify the sources: structured Salesforce data, unstructured knowledge, or both.
- Define authority: per-user identity, service identity, roles, fields, actions, and environments.
- Separate rules from judgment: keep stable policy and validation deterministic.
- Tier the actions: read, draft, reversible write, and consequential action.
- Design evidence: citations, evaluations, logs, approvals, and recovery artifacts.
- Assign operation: access review, change control, regression testing, incidents, and adoption.
Run that sequence before finalizing licenses. It may lead to Agentforce, MCP, RAG, traditional automation, or a combination. The result should be the smallest architecture that safely completes the business job.
Official references
- OpenAI: MCP and connectors
- Model Context Protocol: introduction
- Salesforce: design and implement agents
- Salesforce Developers: context engineering with Agentforce
If the options still look interchangeable, bring the workflow rather than a preferred product. GAT can map the layers, identify the smallest viable architecture, and own the implementation. Book a consultation.