Decision Guide: Running an Agentforce + MCP Pilot for Controlled Agentic AI

# Executive summary

Enterprises deciding whether to operationalize agentic AI should treat Agentforce (Salesforce) as a platform choice and Model Context Protocol (MCP) as a composability standard. The dossier shows Agentforce positions humans-and-agents together across Sales, Service, Marketing and Industry clouds, while MCP defines a JSON-RPC data-layer and two transport options (stdio and Streamable HTTP) for exchanging runtime context, tools, and notifications. The practical decision for senior IT and product leaders is not "whether" to use agents, but how to integrate Agentforce deployments with a context architecture that preserves security, observability, and rapid iteration.

# What the primary sources say (concise)

• Salesforce Agentforce (Agentforce MCP support page) frames Agentforce as a family of capabilities — Builder, Voice, Dev Tools, AgentExchange and Operations — intended to combine human expertise with automated agents inside the Salesforce portfolio. The materials emphasize platform integration, domain connectors, and commercial buying models through Salesforce's product taxonomy. (Source: Salesforce Agentforce MCP support).

• Model Context Protocol (MCP) architecture documentation defines a client-server protocol that separates a data layer (JSON-RPC primitives for discovery, tools, resources, prompts, notifications) from a transport layer that supports fast local STDIO and remote Streamable HTTP with OAuth or bearer authentication. MCP explicitly focuses on context exchange and does not mandate LLM usage or internal application logic. (Source: MCP Architecture documentation).

# Why this matters for an enterprise decision now

1) Speed without lock-in: Agentforce gives rapid access to pre-integrated agent capabilities inside a CRM-centric stack; MCP gives a standards-based way to surface enterprise context (tools, data, prompts) to any agent runtime. Combining them reduces the risk that an enterprise ties agent logic and context storage to a single runtime or hosting model.

2) Security and control: MCP’s transport and auth options let organizations choose local (stdio) servers for sensitive context or remote Streamable HTTP with OAuth for centralized service deployments — a critical choice when customer data and regulated records are in play.

3) Observability and operations: Agentforce Operations plus MCP notifications/ progress primitives provide a path to instrument agent behavior, escalate to humans, and trace decisions across the context exchange boundary.

# Decision criteria (what your leadership team should evaluate)

• Context sensitivity: How much of your agent context is regulated or sensitive? If high, prioritize local MCP servers with STDIO transport or private network Streamable HTTP with strict token governance.

• Integration surface: Do you need tight, low-latency integrations to in-house systems (ERP, billing, claims)? If yes, prefer MCP servers colocated with those systems to avoid cross-network latency.

• Governance model: Who owns prompts, tool registrations, and notification rules? If multiple business units will operate agents, choose an MCP-based discovery and capability registry to avoid ad hoc tool sprawl.

• Observability and audit: Can you capture tool executions, prompts, and notifications for compliance? Ensure Agentforce telemetry can be mapped to MCP notifications and the JSON-RPC tracing primitives.

• Buy vs build: Use Agentforce Builder and AgentExchange to accelerate domain agents; use MCP to make those agents interoperable with other runtimes and internal context providers.

# Recommended current decision: constrained, staged adoption

Decision (recommended): Approve a 9–12 week pilot that pairs Agentforce domain agents with an MCP-based context server under a clear production gate. The pilot should:

• Scope: 1 high-value use case (e.g., service contact center deflection or a sales opportunity orchestration flow) with clear success metrics defined by business users.
• Architecture: Deploy an MCP server that exposes only the minimal resources and tools required by the pilot. Use Streamable HTTP with OAuth for cloud-hosted test environments; run a local STDIO MCP server for any workflows that surface regulated PII or PHI during the pilot.
• Governance: Require tool registration and a change-review process before any new tool or prompt is discoverable to agents. Capture MCP discovery responses and tool-execution logs for audit.
• Ops: Integrate Agentforce Operations dashboards (or equivalent observability) with MCP notifications so human-in-the-loop escalation is automated.
• Exit criteria: Either promote the pilot to production when privacy, latency, and audit checks pass, or rollback to a narrow manual workflow.

This constrained pilot balances speed with control and leverages both Agentforce platform capabilities and MCP’s protocol strengths without committing the enterprise to a single runtime or irrevocable architecture.

# Headless 360 operating-model point of view

Headless 360 views agentic deployments as an integration challenge first and an ML problem second. Our operating model prescribes:

• Signal Cartography up-front: map where each signal (customer record, telemetry, knowledge base, third-party API) lives and which MCP server will own it. Build minimal, auditable resource surfaces for agents to access.
• Ownership split: Product teams own agent behavior and success metrics; Platform teams own MCP servers, transport, credentials, and observability; Security owns token lifecycle and tool-review gates.
• Iteration cadence: short pilot sprints (3–4 weeks) that iterate prompt/tool shape and record the changes in an immutable registry. Use MCP discovery snapshots as the canonical source of what an agent can call at any time.

# Practical risk & governance checklist (must-haves before production)

• Token policy and rotation for Streamable HTTP/OAuth endpoints.
• Least-privilege tool/resource registration in the MCP server.
• Audit trail: log discovery responses, tool execution requests/responses, and notification delivery.
• Human escalation hooks: ensure Agentforce Operations or an equivalent runway can pause or roll back agents.
• Data residency controls: prefer STDIO transport for high-sensitivity data flows.

# FAQ (concise)

Q: Do I have to rewrite existing agents to use MCP?
A: Not necessarily. MCP is a context-exchange layer; you can wrap existing agents with an MCP client or expose needed resources via an MCP server so agents can discover capabilities without rewriting core logic. (See MCP primitives for discovery and tools.)

Q: Which transport should I pick first — STDIO or Streamable HTTP?
A: Use STDIO for local, high-sensitivity experiments and low-latency dev work. Use Streamable HTTP with OAuth for cloud-hosted, multi-tenant deployments and where standard HTTP auth is required. (MCP supports both.)

Q: Can I use Agentforce while maintaining my own context servers?
A: Yes. Agentforce focuses on the human+agent product surface; MCP provides a way to surface your internal context to agents regardless of where they run. The two are complementary.

# References

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