Design Decisions: Mapping Salesforce Agentforce to an MCP Context Layer

# Today's Insight: Design Decisions for Agentic CX — Mapping Salesforce Agentforce onto Model Context Protocol

Executive summary

Salesforce Agentforce positions humans and AI agents on a single platform (Agentforce Builder, Voice, Dev Tools, AgentExchange, Operations, and a Headless Toolkit) to accelerate agentic customer experiences. The Model Context Protocol (MCP) provides a standard, JSON-RPC–based way to exchange context between an AI host and many context servers, with two transport options (stdio and streamable HTTP) and primitives for tools, resources, prompts, and notifications (MCP spec version 2026-07-28).

For enterprise technology leaders choosing how to integrate Agentforce into large-scale CX systems, the practical decision is not whether to adopt agents — it’s how to design context, security, and operational patterns so agents amplify human work without creating brittle, opaque behavior. This Insight gives a concrete, prioritized decision checklist to align Salesforce Agentforce adoption with an MCP-style architecture and Headless 360 operational practices.

Why this matters now

• Salesforce’s Agentforce product family explicitly targets agentic workflows, with builder tooling, voice capabilities, and an AgentExchange for partner agents.
• MCP defines a transport-agnostic, primitive-rich way to supply context and tools to AI applications, solving the core problem of consistent context delivery across agents and host applications.

Combine these: an enterprise that standardizes on MCP-style context exchange will reduce integration cost when running multiple agents, reduce duplicated connectors, and centralize policy enforcement — all while enabling faster iteration of agent behaviors.

Architecture implications (concrete)

1. Context as a first-class artifact

• Treat the customer state, CRM objects, conversational session history, and tool capabilities as discrete context resources that can be requested by agents. MCP calls these resources and tools at the data-layer level; Agentforce capabilities (Agentforce Builder, Agentforce Dev Tools, Headless Toolkit) expect the platform to supply sanitized, authorized context.

1. Use a layered transport strategy

• For on-prem or edge integrations (e.g., private data stores, regulated systems), prefer a local/stdio-style transport pattern for direct, low-latency context delivery to agent runtimes. For cloud-hosted agents and partner agents, the streamable-HTTP approach is appropriate — but assume you must implement robust authentication tokens and OAuth flows as MCP recommends.

1. Centralize discovery and capability advertising

• Implement a discovery endpoint that lists available tools, prompts, and resources (MCP discovery primitive). This reduces runtime errors when agents attempt tool executions and helps governance teams enforce allowed actions for each agent.

1. Design for notifications and change subscriptions

• Use MCP-style notifications where agents can subscribe to state changes (order status, SLA breach, consent revocation). Notifications support operational flows (escalation, human takeover) without polling or fragile cron jobs.

Implementation checklist (prioritized — 90-day cadence)

Week 0–4: Foundation

• Inventory “signals” (CRM records, session logs, external APIs) that agents will need. Map each signal to a resource name and minimal schema.
• Stand up a context-discovery service that implements a tool/resource index (can be light-weight initially).
• Choose transport mapping: which resources live behind local/stdio channels vs. streamable HTTP.

Week 5–8: Secure and connect

• Implement OAuth token issuance for streamable HTTP clients and service-to-service tokens for internal agents. Follow MCP guidance on transport authentication.
• Implement role-based access rules per resource and per tool; ensure least-privilege for agents.

Week 9–12: Operate and iterate

• Roll out a default notification subscription pattern for critical signals (payments, cancellations, escalations).
• Deploy human-in-the-loop patterns in Agentforce Builder: define handoffs and escalation triggers; test with live agents.
• Add AgentExchange partners incrementally; require them to register tools and resource usage via discovery.

Risk, governance, and observability

• Explainability and audit logs: use MCP primitives to require tool-execution recording and resource snapshots at time-of-action. Store those artifacts for audit and post-incident analysis.

• Drift and model behavior: version context schemas and require agents to declare compatible schema versions in discovery responses (MCP encourages versioning). Rollback quickly by removing a tool from discovery.

• Data residency and privacy: enforce dataset-level policies in the context server so that agents never receive unauthorized PII. Use transport choices to keep regulated data on-prem where necessary.

• Human-agent interaction policies: define explicit policies in Agentforce Operations for when an agent can act autonomously vs. when it must request human approval.

Headless 360 operating-model point of view

Headless 360 recommends treating the agent-enabled CX stack as a signal mesh rather than a monolith. Operationally: create a small centralized Context Services team that manages discovery, schema versioning, policy enforcement, and telemetry; product teams build agent behaviors against those services. The team’s charter is to deliver three outcomes:

1. Reliable signal delivery (low-latency, authenticated) so agent behaviors are consistent in production.
2. Policy-as-a-resource (access rules, redaction transforms) applied at the context layer, not inside each agent.
3. Signal Cartography: maintain a live map of which agents subscribe to which signals and which signals are used to make decisions — this is the single source for impact analysis and for simulated agent testing.

Operationally, the recommended org pattern is a thin platform team (Context Services + Observability) + multiple verticals (product/agent teams). This minimizes duplicated connectors and centralizes high-trust controls.

Concrete decision for technology leaders (single prioritized ask)

Approve a 90-day project to deliver a context-discovery service, an initial set of three critical resource adapters (CRM, orders, session history), and an OAuth token service. That minimal investment lets product teams onboard Agentforce agents safely while preserving centralized governance.

FAQ (concise)

Q: Do we need to fully implement MCP to use Agentforce?
A: No. MCP is a protocol model for context exchange. You can begin by implementing the MCP concepts (discovery, resources, tools, notifications) in your platform without a full MCP server; however, aligning to the MCP primitives will make future integrations and third-party agents easier.

Q: Which transport should we choose first?
A: Start with streamable HTTP for cloud-hosted capabilities and keep high-sensitivity data behind a local channel or private connector. The decision depends on latency, regulatory, and partner integration requirements.

Q: How do we limit an agent’s actions?
A: Enforce action limits at the tool/resource layer: advertise only permitted tools in discovery, and require an authorization check on every tool execution. Record every execution for audit.

Q: What telemetry should we capture?
A: Execution traces (tool invoked, inputs, outputs), resource snapshots at call time, latency, failure rate, and subscription events for notifications.

References

• Agentforce MCP Support — Salesforce: https://www.salesforce.com/agentforce/mcp-support/
• Model Context Protocol — Architecture overview (version 2026-07-28): https://modelcontextprotocol.io/docs/learn/architecture