Run Agentforce with MCP: A 90‑Day Pilot Playbook

# Today's Insight — September 1, 2026

Executive decision in one line

Adopt a measured 90-day pilot that pairs Salesforce Agentforce (running on the Headless 360 platform) with a Model Context Protocol (MCP) server deployed locally (stdio transport) to retain data control, validate agentic workflows, and shorten time-to-confidence before a broader rollout.

Why now

Salesforce positions Agentforce as a platform where “humans with agents drive customer success,” and Headless 360 is presented as the platform layer to build and customize Agentforce and Customer 360 integrations. The MCP architecture defines a clean, auditable contract for providing runtime context to AI hosts (clients) while separating transport choices and security models. Combining the two lets CIOs run agentic AI in production while keeping contextual data governance explicit and technically enforceable.

This is not a philosophy paper — it is a prescriptive operational choice: run the first production-grade agentic workflows with an MCP-backed context layer under Headless 360 so the organization can iterate safely and measure business outcomes.

Concrete 90-day pilot plan (decision-makers checklist)

1. Sponsor and scope (Days 0–7)
2. - Sponsor: CTO or Head of Automation. Identify a single high-value, low-regret use case (examples inside Agentforce product pages: service triage, sales opportunity enrichment, or an internal legal/HR assistant).
3. - Success criteria: measurable KPI targets (e.g., handle-rate improvement, average handling time reduction, or actionable lead enrichment) and compliance guardrails.

1. Architecture decision (Days 1–14)
2. - MCP server placement: choose a local MCP server (stdio transport) when data residency, latency and strict access control matter. Use Streamable HTTP only if you need a managed remote server or multi-tenant connectivity.
3. - Host/Client: configure your agent host (LLM runtime) as an MCP client that talks to the local MCP server. That keeps context exchange auditable and bounded by the MCP primitives (tools, resources, prompts, notifications).
4. - Platform: run Agentforce on Headless 360 to take advantage of prebuilt product integrations (Agentforce Builder, AgentExchange, Slack connectors) and to centralize lifecycle management.

1. Security and governance (Days 7–30)
2. - Authentication: use OAuth tokens for any streamable HTTP connections; for stdio local deployments, ensure OS-level process isolation and secrets management for the MCP server.
3. - Minimal surface exposure: define exactly which MCP resources/tools the server advertises during discovery. Use MCP discovery to keep context scope narrow and changeable.
4. - Audit and notifications: enable MCP notifications for context changes so you can log what live context the agent consumed for each action.

1. Implementation (Days 14–60)
2. - Build the MCP server adapters that expose scoped CRM records, customer 360 fragments, and the specific tools the agent needs (search, DB lookup, or a commerce API) as MCP resources.
3. - Implement the MCP discovery flow so the agent host can see version and capability metadata before any operation; make discovery part of the deployment checklist to prevent accidental capability drift.
4. - Integrate Agentforce components (Builder, Voice, or Sales/Service agent modules) and map each agent action to an MCP tool or resource.

1. Validation and measurement (Days 45–90)
2. - Run a shadow phase (agent suggestions shown to humans but not executed) for two–three weeks to collect precision/recall and human override rates.
3. - Measure the success criteria against baseline: time-to-resolution, % automation opportunities accepted, and compliance exceptions captured by MCP notifications.
4. - Decide: expand, iterate, or rollback. Keep the MCP server as the control plane — adding or removing tools/resources requires only server-side changes, not LLM retraining.

Architecture trade-offs — practical guidance

• Stdio transport (local MCP server): lowest latency and highest control. Prefer for sensitive customer data or when policy requires on-premise processing. It also simplifies authentication because the process runs locally, but you must still enforce local secrets and isolation.

• Streamable HTTP (remote MCP server): choose when you need centralized, multi-client provisioning and you can accept network hops and OAuth-based identity. Use this when operating a managed MCP service across multiple business units.

• Discovery first: use the MCP discovery exchange as an operational safety valve — agents should always perform capability discovery before invoking tools. Make discovery logs part of your compliance evidence.

• Notifications and change management: subscribe to MCP notifications for resource changes (e.g., customer record updates) so you can correlate agent outputs to the exact context snapshot used.

Headless 360 operating-model point of view

Headless 360 recommends treating the MCP server as the enterprise’s context contract: a single source of truth for what an agent can see and do. That means separating three responsibilities and assigning clear owners:

• Data Owner (Line-of-Business): Authorizes which CRM/Customer 360 fragments are exposed, defines retention and masking policies.
• Platform Owner (Headless 360): Deploys and operates the Agentforce runtime, integrates MCP client libraries into the host, and enforces lifecycle (staging → canary → prod).
• Security & Compliance (Central IT): Configures transport-level authentication (OAuth or process isolation for stdio), approves discovery schemas, and audits notification logs.

When each role treats the MCP server as the contract, agentic deployments can scale without hidden access or accidental context creep.

Risk checklist (must-haves before expand)

• Explicit discovery schema and versioning for all MCP resources.
• Logged MCP notifications and discovery events for each session.
• Role-based masking rules applied at MCP server layer (so agents never receive raw PII unless authorized).
• A shadow-mode reduction target (minimum human-acceptance threshold) before full automation.

Concise FAQ

Q: Why not connect the agent directly to the CRM?
A: Direct connections make it harder to reason about the exact context the agent consumed. MCP creates an auditable, versioned contract between the agent host and the context server, which simplifies governance and reduces blast radius.

Q: Which transport should I pick first?
A: Start with stdio-local MCP for pilots that require data control and low latency. Choose streamable HTTP later for multi-tenant or centralized managed MCP services.

Q: Does this require new engineering patterns?
A: Yes — instrument discovery, treat MCP resources as small, testable primitives, and bake MCP notifications into your audit and incident workflows.

Recommended next step (30-minute decision)

Approve a 90-day pilot budget and select a single B2B or support use case. Mandate local MCP (stdio) for the pilot, Headless 360 platform hosting of Agentforce, and a small cross-functional team (Platform, Security, and the sponsoring LOB). Require weekly demo and a go/no-go review on day 60 based on the pre-agreed KPIs.

References

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