Pilot Agentforce + MCP: A Practical Headless Plan for Agentic AI

# Pilot Decision: Integrate Salesforce Agentforce with an MCP Context Layer

Date: September 16, 2026

Overview

Enterprises that want operational, agentic AI at scale face two practical challenges: (1) delivering high-quality, discoverable context to agents and (2) deploying agents in a way that preserves data locality, governance, and low latency while still integrating with business workflows. The primary-source dossier supplied here points to a concrete architecture pattern for both problems: use Salesforce Agentforce as the agent orchestration and experience layer, and adopt the Model Context Protocol (MCP) as the standardized context exchange layer between LLM-driven agents and your data/services.

This Insight recommends a single, time-boxed business decision: run a 12–16 week pilot to validate an Agentforce + MCP headless stack for one high-value use case (for example: customer service triage or claims intake). The pilot is designed to test end-to-end context delivery, transport modes, discovery, tool execution, governance, and measurable operational criteria (latency, data residency controls, and developer velocity) before a broader rollout.

Sources used: Salesforce Agentforce product/solutions page and the MCP architecture documentation. See References.

Why this concrete decision — not more strategy

• Salesforce Agentforce is presented as the enterprise-facing agent orchestration and product portfolio (Builder, Voice, Dev Tools, AgentExchange, Headless Toolkit) that connects agents, humans, and business processes. The product page frames Agentforce as the place to build and operate agents inside Salesforce estate and across channels.

• MCP is a purpose-built protocol for exchanging context between AI hosts and context providers. Its architecture explicitly separates a data layer (JSON‑RPC-based discovery, tools, resources, prompts, notifications) from a transport layer (stdio for local, Streamable HTTP for remote) and specifies discovery, tool execution, and notifications as primitives.

Taken together, the dossier suggests a pragmatic headless pattern: keep the agent orchestration and business UX in Agentforce while serving authoritative, governed context from MCP servers that you control or trust. That separation enables velocity (developers can iterate on agents and flows) while preserving data governance and performance choices (local stdio or authenticated HTTP). (Source: Agentforce product pages; MCP architecture doc.)

The decision (explicit)

Authorize a 12–16 week pilot to validate a headless Agentforce + MCP integration for one prioritized workflow. Pilot goals: prove secure context delivery, validate transport and discovery primitives, measure developer cycle time for adding new tools/resources, and confirm governance controls for the selected data surfaces.

Deliverables at the end of the pilot:

• Working end-to-end demo: Agentforce agent (voice or chat) using context supplied by an MCP server to complete the workflow with human-in-the-loop escalation.
• Architecture playbook documenting chosen transport (stdio vs. Streamable HTTP), discovery patterns, tool and resource schemas, authentication model, and audit points.
• Risk and compliance report detailing where sensitive data was stored, how it was reduced/filtered before being given to LLMs, and operational controls for notifications and long-running operations.
• Recommendation: roll forward, iterate, or pause.

Implementation checklist (technical decisions to validate)

1. Scope the workflow and data surfaces
2. - Select a bounded workflow with clear success criteria (e.g., reduce triage time by X). Keep data inputs limited and well understood.

1. Choose MCP transport for the pilot
2. - Local, latency-sensitive test: use stdio transport with a local MCP server to validate tool execution and low-latency context delivery.
3. - Remote or multi-tenant test: use Streamable HTTP transport with OAuth/bearer tokens to validate authentication and remote discovery. (MCP supports both.)

1. Implement discovery and capabilities
2. - Expose a clear tool catalog (actions agents can request) and resource endpoints (documents, records, snippets). Use MCP discovery to let the Agentforce-hosted agent enumerate available capabilities.

1. Define prompts and resource filtering
2. - Standardize how prompts and templates are provided by MCP and ensure sensitive fields are redacted or tokenized before delivery to the model.

1. Instrument notifications and long-running operations
2. - Use MCP notifications for real-time updates and for progress tracking of long-running tasks.

1. Integrate with Agentforce Headless Toolkit and Dev Tools
2. - Map MCP tools/resources to Agentforce agent capabilities and test human-agent handoff patterns.

1. Operationalize governance
2. - Ensure audit trails on discovery and tool execution. Record what context was served and which agent actions were executed for compliance and retraceability.

(Technical primitives and transports referenced from the MCP architecture overview; Agentforce capabilities referenced from the Salesforce Agentforce product page.)

Risks and mitigations

• Data leakage: Mitigate by filtering and redaction at the MCP server boundary and by logging all context deliveries for audit.
• Latency and reliability: Validate stdio for local low-latency use cases; test HTTP transport with streaming for reliability and scalability.
• Dependency sprawl: Keep the pilot bounded to a single workflow, and register only the minimal set of tools/resources with MCP discovery.
• Governance and compliance: Keep a clear record of which systems contributed context. Use the playbook to codify retention and access rules.

Headless 360 operating-model point of view

Headless 360 recommends a “separation-of-concerns” operating model for agentic AI: treat the agent runtime and UX as the orchestration layer (Agentforce) and treat context as a first-class, discoverable product served by context teams (MCP servers). Operational responsibilities split as follows:

• Product / Business teams: define the workflow, user experience, success metrics, and edge cases for human handoffs.
• Context teams (data & platform): build and operate MCP servers that serve curated, versioned context and enforce redaction, retention, and authorization policies.
• AI / Engineering teams: map MCP tools/resources into agents, implement prompts/templates, and instrument agent behavior.
• Governance / Legal / Security: set the policies for what can flow to models and review audit logs produced by MCP.

This model accelerates agent launches because product teams iterate on Agentforce experiences while platform teams independently scale trustworthy context delivery. The explicit protocol boundary (MCP) reduces coordination friction and makes the architecture auditable and testable.

FAQ (concise)

Q: Why not only use Agentforce without MCP?
A: Agentforce is the agent orchestration and experience layer; MCP supplies a standardized, auditable context exchange. Using both separates UX velocity from data governance and gives transport choices (local vs remote) that matter for latency and residency.

Q: Does MCP require replacing existing data services?
A: No. MCP is a protocol layer: you can implement an MCP server that wraps existing services and applies filtering, discovery, and authorization before making context available to agents.

Q: Which transport should I start with?
A: For low-latency, single-host experiments, stdio is fastest; for multi-tenant or distributed deployments, use Streamable HTTP with OAuth. Validate both in the pilot.

Q: How long should this pilot run?
A: 12–16 weeks to cover architecture, integration, compliance review, and a small operational rollout.

References

• https://www.salesforce.com/agentforce/mcp-support/
• https://modelcontextprotocol.io/docs/learn/architecture