Agentforce + MCP: A Practical 90‑Day Decision Path for Enterprise Architects

# Decision Insight: Should Your Enterprise Run Salesforce Agentforce with MCP-enabled Context?

Enterprises evaluating agentic AI face a practical operational choice: run agents as cloud-first services tied to vendor-managed context, or adopt a Model Context Protocol (MCP) architecture that separates the agent (model) from context providers you control. This briefing translates the primary-source dossier into a concrete decision framework and an actionable 90-day plan for CTOs, heads of automation, and platform architects.

The concrete decision to make today

Decide whether to pursue a hybrid MCP rollout for Agentforce (pilot remote MCP, then selectively localize) or to accept a cloud-managed Agentforce-only deployment. Choose hybrid MCP if any of these are true for your org:

• You require strong data residency, egress controls, or on-prem context for regulated workloads.
• You need sub-100ms local tooling latency for operational agents (e.g., contact-center routing, edge automation).
• You want to instrument, version and evolve the context layer independently of vendor agent releases.

Choose a cloud-managed Agentforce-only path if your priority is maximal product velocity, minimal ops overhead, and you can accept vendor-managed context and transport.

What the sources say (short)

• Salesforce’s Agentforce materials list a modular product family (Agentforce Builder, Voice, Dev Tools, AgentExchange, Headless Toolkit) intended for enterprises to combine human agents and AI agents across sales, service, and other domains. These building blocks support developer and operations workflows for agentic deployments.

• The Model Context Protocol documentation describes an explicit client–server architecture (MCP host / MCP client / MCP server), two transport options (stdio for local, Streamable HTTP for remote), JSON-RPC based data primitives (tools, resources, prompts, notifications), and best practices such as OAuth for authorization. MCP separates context delivery from LLM use, enabling local context servers and hybrid topologies.

(See References for source URLs.)

Decision checklist (quick)

• Data policy fit: Is customer data allowed to flow to vendor-managed remote context? If no → favor hybrid MCP with local servers.
• Latency & availability SLAs: Are strict local latencies required? If yes → use stdio/local MCP for sensitive agents.
• Developer velocity: Do product teams want fast Agentforce Builder + managed context to iterate? If yes → cloud-first Agentforce deployment.
• Observability & governance: Do you need traceable context snapshots and resource versioning? If yes → MCP gives separation of concerns and audit points.
• Cost profile: Are you prepared to operate additional infrastructure (local MCP servers)? If no → favor managed deployment.

Recommended architecture (Headless 360 practical pattern)

1. Pilot: Streamable HTTP MCP server + Agentforce Builder
2. - Use a remote MCP server behind your corporate VPC with OAuth tokens to prototype data flows, Agentforce dev tools, and Slack integrations. This lets product teams move quickly and proves agent behaviors without committing to localized infra.

1. Harden & localize critical agents: local stdio MCP servers
2. - For regulated workloads or low-latency agents, run MCP servers on-prem or in a private cloud using the stdio transport for direct, low-latency connections to the agent runtime. Keep the same MCP primitives (tools, resources, notifications) so client code is portable.

1. Operate a hybrid control plane
2. - Centralize discovery, policy, and telemetry in a control-plane layer that can route certain agent requests to remote MCP servers and others to local MCP servers depending on data classification and latency policies.

1. Integrations & ecosystem
2. - Use the AgentExchange and Agentforce Dev Tools to package and distribute agent skills. Because MCP separates context, the same skill can be pointed at different context backends for testing and production.

Practical 90-day roadmap (concrete milestones)

• Days 0–30 (Pilot): Stand up Agentforce Builder sandbox, register a Streamable HTTP MCP server, validate identity flow (OAuth) and basic tool/resource exchanges. Define 2–3 candidate agents (e.g., a knowledge retrieval agent for service, a scheduling assistant).

• Days 31–60 (Harden): Add observability (request tracing, notifications), classify data by residency needs, and run compliance review. Convert one pilot agent to use a local stdio MCP server for a high-sensitivity dataset.

• Days 61–90 (Decide & Scale): Evaluate metrics (time to iterate, latency, ops effort, compliance sign-off). If local approach passes, implement rollout plan for additional agents and build the hybrid control plane.

Headless 360 operating-model point of view

Headless 360 recommends operating agentic stacks as a composable two-layer platform: an immutable agent runtime layer (models + execution) and a versioned context layer (MCP servers). Treat MCP servers as productized internal services with standard SLAs, feature flags, and telemetry. This reduces blast radius when model or prompt changes occur, and allows decentralized teams to develop agent skills while central platform teams own data governance and observability.

Why this matters: splitting responsibilities aligns with enterprise security, compliance, and developer velocity objectives—teams iterate on skills while platform maintains trust boundaries.

Risks and mitigations

• Operational overhead: Running local MCP servers increases ops work. Mitigate by containerizing servers, automating deployment pipelines, and adopting a standardized MCP SDK.
• Fragmentation: Multiple MCP backends can cause drift. Mitigate with CI tests that run skills against both remote and local MCP endpoints.
• Vendor lock-in perception: MCP reduces lock-in by decoupling context, but Agentforce product features (Builder, Voice, AgentExchange) will still be vendor-managed; treat them as high-velocity UI/platform tools and keep critical context logic in your MCP layer.

Concise FAQ

Q: Will MCP force me to run everything on-prem?
A: No. MCP supports both stdio (local) and Streamable HTTP (remote) transports. You can mix them according to data classification and latency needs.

Q: Can I use the same Agentforce skills across local and remote contexts?
A: Yes — MCP’s primitives (tools, resources, prompts) are designed so that skills can be pointed at different context providers without rewriting skill logic.

Q: How does authentication work between Agentforce and MCP servers?
A: The MCP documentation recommends standard HTTP authentication flows (OAuth for tokens) for Streamable HTTP transport; local stdio transports rely on host-level protections. Implement enterprise identity federation as appropriate.

Q: What should platform teams own vs. product teams?
A: Platform teams should own MCP servers, discovery, policy enforcement, and telemetry. Product teams should own agent skill logic, prompts, and evaluation metrics.

References

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