Agentforce + MCP: A 90‑Day Pilot Playbook for Signal Cartography and Safe Agentic CX

# Executive summary

Enterprises building agentic customer experiences now face a concrete infrastructure choice: externalize signal context to standardized context servers (Model Context Protocol, MCP) or continue ad‑hoc, proprietary context plumbing inside agent runtimes. The primary‑source dossier shows Salesforce positioning Agentforce as a platform for humans-and-agents together and explicitly documenting MCP support, while the MCP architecture spec defines the primitives, discovery, and two transport models (stdio and Streamable HTTP) that make context exchange predictable and auditable. The decision for CX and platform leaders is not philosophical — it is operational: launch an MCP‑backed Agentforce pilot within 90 days to harden data governance, accelerate agent developer velocity, and reduce risk from hidden context sprawl.

The decision today (concrete)

Authorize a 90‑day Agentforce + MCP pilot scoped to a single high‑value customer journey (e.g., post‑purchase support or returns). Objectives: validate MCP discovery and tool execution flows with Agentforce, prove secure transport choices for sensitive records, and produce an operational runbook that maps signal ownership and governance. Deliverables: an MCP server instance feeding Agentforce agents, a Signal Cartography inventory of signals, an integration playbook for production rollout, and compliance sign‑offs.

Why MCP matters now

• MCP standardizes the data‑layer primitives (tools, resources, prompts, notifications) and a JSON‑RPC 2.0 exchange pattern. That creates repeatable discovery and execution semantics for agent actioning. (See MCP architecture overview.)
• MCP separates the data layer from transport choices — you pick stdio for local/on‑prem low‑latency contexts or Streamable HTTP for multi‑tenant remote servers with standard auth patterns. This gives a predictable set of tradeoffs for latency, auditability, and security.
• Salesforce Agentforce is already the enterprise surface for agent development, deployment, and orchestration (Agentforce Builder, AgentExchange, Agentforce Dev Tools). Combining Agentforce with MCP turns contextual sources into reusable, discoverable services rather than buried integrations.

Source signals in the dossier: Agentforce product pages list Agentforce Builder, AgentExchange, and developer tooling alongside the Agentforce MCP support framing; MCP docs define the architecture and transport semantics. Use these two sources to align platform and architecture choices.

Headless 360 operating‑model point of view

Headless 360 recommends a productized, signal‑first operating model we call Signal Cartography: treat every customer interaction, event stream, and internal record as a discoverable signal surface mapped to an MCP resource. Operational rules:

• Map first, integrate second: build a Signal Cartography inventory before writing code. Identify owners, PII tags, retention, transformation rules, and SLA for each signal.
• Transport by intent: choose stdio for on‑prem context that must never leave the data center; choose Streamable HTTP where cloud‑hosted MCP servers provide centralized discovery and multi‑tenant reuse.
• Enforce discovery governance: require every new agent to run MCP discovery and to reference declared resource schemas, so runtime behavior is auditable and reproducible.
• Productize agent behaviors: expose agent skills through AgentExchange with MCP descriptors so business teams can assemble experiences without ad‑hoc engineering work.

This operating model reduces accidental data exfiltration, improves speed of delivery by removing bespoke context adapters, and creates a compliance boundary around agent actions.

90‑day pilot plan (week by week)

Phase 0 — week 0 (decision): scope journey, appoint sponsor (CX lead), platform owner (infra/AI), and compliance reviewer.

Phase 1 — weeks 1–3: Signal Cartography and discovery
- Inventory signals: customer events, knowledge sources, CRM records, external APIs.
- Tag signals for sensitivity, owner, and retention.
- Define MCP resources required (tools, prompts, resources).

Phase 2 — weeks 4–7: Infrastructure and integration
- Stand up an MCP server (local or cloud) implementing MCP data‑layer primitives.
- Configure transports: stdio for any on‑prem context; Streamable HTTP for cloud sources with OAuth or API keys as appropriate.
- Integrate MCP client in an Agentforce sandbox agent and run discovery exchange.

Phase 3 — weeks 8–11: Use‑case validation
- Run end‑to‑end flows: tool discovery, tool execution requests, and notification subscriptions.
- Validate audit trails: who requested what, what context was used, and why agent chose the action.
- Collect developer and operator feedback; measure time to integrate a new signal.

Phase 4 — weeks 12–13: Operate and decide
- Produce runbook, gating checklist, and go/no‑go criteria for broader rollout.
- Present findings to governance board with proposed rollout timeline.

Implementation checklist (minimum viable guardrails)

• Signal Cartography inventory completed and approved.
• MCP server deployed and reachable from Agentforce sandbox.
• Discovery responses include complete capabilities and resource descriptions.
• Authentication patterns documented and tested (OAuth for streamable HTTP where used).
• Monitoring and notifications enabled for tool execution and long‑running operations.
• Privacy and retention policy mapped to each MCP resource.

Risk & governance considerations

• Data residency: prefer stdio for contexts that must remain on‑premises; use Streamable HTTP only where encryption, auth, and contractual controls are aligned with legal requirements.
• Auditability: require that Agentforce agents persist discovery and execution logs in an immutable store mapped to the Signal Cartography entries.
• Vendor and protocol lock‑in: MCP is a protocol; retain the ability to run alternative MCP servers (local and remote) so you can switch providers without rearchitecting agent logic.

Concise FAQ

Q: What is MCP in plain terms?
A: MCP is a protocol for exchanging model context: it makes data sources, tools, and prompts discoverable to agent hosts and defines how they communicate (discovery, execution, notifications) using a JSON‑RPC structure.

Q: Why pair MCP with Agentforce?
A: Agentforce is the orchestration layer for humans and AI agents; MCP makes the context those agents use discoverable and auditable, turning one‑off integrations into reusable services.

Q: Is this only for greenfield projects?
A: No. Start with a single journey and incrementally onboard legacy sources as MCP resources. The Signal Cartography step prevents scope creep.

Q: How do we keep sensitive data safe?
A: Use transport selection (stdio vs. Streamable HTTP), strong auth (OAuth for remote servers), and map retention/PII controls to each MCP resource before the agent can access it.

References

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