Operational Decision: Pilot Agentforce with MCP for Secure, Composable Agents

# Executive summary

Enterprises adopting agentic AI face two immediate operational choices: pick an agent platform that ties into your customer and operational data, and select a context-distribution mechanism that scales safely across local and remote tools. Salesforce Agentforce (Agentforce MCP support) and the Model Context Protocol (MCP) present a practical pairing: Agentforce supplies agent-first product components and platform integrations, while MCP standardizes how context, tools, and prompts are discovered and delivered to models. This Insight recommends a single, concrete decision for enterprise leaders: run a focused 90-day pilot that pairs Agentforce with an MCP-backed architecture using a mixed transport strategy (local MCP for sensitive customer context; Streamable HTTP MCP for vetted external integrations). The goal is to validate operational controls, cost levers, and measurable business outcomes before broad rollout.

Why this matters now

Agentic agents change where and how customer, product, and IT work happens. Getting the integration model wrong — embedding agents directly into brittle pipelines or exposing sensitive context to remote model hosts — creates cost, compliance, and trust risks. MCP’s specification for context exchange (primitives, discovery, notifications, and two transport modes) gives an explicit operational surface you can design against. Agentforce’s product pages and support guidance show the vendor intent to operate with builder tooling, operations tooling, and platform hooks that match MCP’s goals. Together they let you move from proof-of-concept to repeatable deployment without inventing a bespoke context protocol.

The concrete decision (what to do this quarter)

1. Launch a single 90-day pilot scoped to one high-value workflow — e.g., first-contact customer-service routing or warranty claim triage — that will be converted to an agent-first flow. Keep scope limited to one user persona and one channel (chat or voice).
2. Architect the pilot to use MCP for context exchange: deploy a local MCP server for customer records and PII-sensitive context (stdio transport or locally hosted Streamable HTTP), and use a separate, hardened Streamable HTTP MCP connection for non-sensitive third-party tools (payment validators, shipping APIs). Treat MCP servers as explicit trust and audit boundaries.
3. Use Agentforce components for agent orchestration and builder tooling, and integrate them with your Customer 360 data only through MCP-mediated resources. Avoid hard-coded API calls from agents to backend systems during the pilot.
4. Measure three outcomes: operational cost (inference + orchestration), latency and success rate for the chosen workflow, and compliance trail completeness (auditability of context deliveries and tool executions). Define explicit SLOs at the outset.

Why mixed transport (local + Streamable HTTP)

MCP supports two transport modes. For enterprises, that is an advantage: you can colocate context with the model host for sensitive data and still integrate remote capabilities when necessary. The mixed approach lets you control data exposure while enabling partner services and SaaS integrations. Operationally:

• Local MCP (stdio or private network): use for high-sensitivity resources and to keep model inference and context on-prem or in your private cloud.
• Streamable HTTP MCP: use for vetted, non-PII services and third-party capabilities where latency and scale matter.

Design your ops playbook so switching a resource between local and remote MCP servers is an explicit change with review, rather than an ad-hoc config flip.

Implementation path (three-phase plan)

Phase 1 — Design and guardrails (weeks 0–2)
- Select the pilot workflow, stakeholders, success metrics, and fail-stop conditions.
- Define data classes and label what must remain local.
- Create an MCP contracts document (which tools/resources/prompts are discoverable and which transports are allowed).

Phase 2 — Build and instrument (weeks 3–8)
- Stand up an MCP server for local context and configure a separate Streamable HTTP MCP endpoint for non-sensitive tooling.
- Use Agentforce Builder and Dev Tools to author the agent flows that call MCP primitives rather than hard-coded APIs.
- Add audit logging, request/response capture, and rate controls at the MCP boundary.

Phase 3 — Validate and decide (weeks 9–12)
- Run live traffic (gradually increasing) against SLOs.
- Validate that context discovery, tool execution, and notifications behave as expected under failures.
- Decide: promote to production, extend to more workflows, or iterate on governance controls.

Headless 360 operating-model point of view

Headless 360 recommends treating agentic deployments as platform-enabled products. That means:
- Code, deploy, and operate agents as discrete product teams with a product owner responsible for outcome metrics (cost, latency, accuracy, compliance).
- Make MCP servers and Agentforce runtime plumbing a shared infrastructure responsibility (platform team) with SLOs and runbooks. The platform team owns secure transport choices, certification of third-party MCP endpoints, and the audit-log retention policy.
- Use declarative discovery and explicit capability manifests so teams can compose agents from re-usable resources without re-creating trust decisions.

This operating model prevents accidental proliferation of ad-hoc agent integrations and centralizes the most security-sensitive decisions where they belong: the platform team.

Risks and mitigations

• Data exposure: Mitigate by classifying data, using local MCP servers for PII, and enforcing transport-level policy in platform middleware.
• Vendor lock-in: Mitigate by insisting on MCP-compliant interfaces for in-house and partner MCP servers; keep resource manifests portable.
• Cost surprises: Instrument inference and orchestration costs (per-request), and run a “right-size” exercise to choose model sizes and caching boundaries.

FAQ (concise)

Q: Do we have to refactor all integrations to use MCP?
A: No — start with one pilot. Use MCP as the standard for new agent-facing integrations and incrementally migrate high-risk flows.

Q: Which transport should we choose first?
A: For sensitive customer context choose local MCP; for scale and rapid partner integrations choose Streamable HTTP where the partner is certified.

Q: How do we measure success?
A: Define SLOs for cost per resolution, average latency, and audit completeness. If the pilot meets SLOs and governance checks, expand.

Q: Will this lock us into a vendor?
A: MCP is a protocol contract; using protocol-based composition reduces vendor lock-in compared with embedding logic directly into a vendor-specific runtime.

References

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