Choose Design for Agentic Integration: MCP, Headless 360, and Salesforce Agentforce — A CIO Decision Playbook

# Executive summary

Enterprises evaluating agentic AI inside Salesforce Agentforce and Headless 360 face a precise engineering choice: adopt the Model Context Protocol (MCP) as the context-exchange backbone and decide how MCP transport and discovery will sit inside your Headless 360 architecture. The MCP architecture documentation describes two clear transport patterns (stdio for local, Streamable HTTP for remote) and a JSON-RPC-based data layer with primitives for tools, resources, prompts and notifications. The Salesforce Agentforce product pages position Headless 360 as the platform for building and customizing Agentforce deployments with Builder, Dev Tools, and AgentExchange support.

Recommendation (single concrete decision): approve a 90-day technical pilot that implements a local MCP server for rapid prototyping (stdio) and a Streamable HTTP MCP endpoint for a representative production integration to Agentforce in Headless 360. The pilot will demonstrate end-to-end context discovery, tool execution, and notifications between Headless 360 components and Agentforce agents, and will produce a go/no-go decision with measurable acceptance criteria.

Why this decision matters (short)

• MCP is a protocol designed to separate context delivery from how models are run; choosing MCP aligns your integration strategy to a stable, documented exchange (discovery, tools, resources, prompts, notifications). (Source: MCP architecture documentation.)
• Salesforce’s Agentforce and Headless 360 packaging assume extensibility through developer tools and integrations — a successful MCP integration unlocks the ability to treat Agentforce agents as interoperable components in a larger enterprise signal fabric. (Source: Salesforce Agentforce pages.)

Acceptance criteria for the 90‑day pilot

• End-to-end context discovery and tool listing: Headless 360 can query an MCP server and receive tool/resource/prompts metadata.
• Transport proof-points: a local MCP server (stdio) supports low-latency dev flows; a Streamable HTTP MCP endpoint supports authenticated remote connections and SSE-style streaming behavior.
• Tool execution and notifications: an agent in Agentforce can call a Headless 360 hosted tool via MCP and receive notifications for long-running work.
• Security and governance baseline: OAuth or API-key auth configured for the Streamable HTTP endpoint and an audit trail for context exchange.

Concrete 6‑week technical plan (what engineers will do)

Week 1–2: design and scaffold
- Map the integration surface between Headless 360 components and Agentforce features (Builder, Dev Tools, AgentExchange).
- Choose test workloads and three representative tools (lookup, action, logging) exposed by an MCP server.

Week 3–4: prototype (local)
- Implement a local MCP server using stdio transport to serve context for a Headless 360 dev instance (stdio recommended by MCP for local processes).
- Validate discovery and tool execution flows with a locally running Agentforce agent emulator.

Week 5–6: remote transport and governance
- Expose the same MCP server via Streamable HTTP with OAuth/API-key auth and test with Headless 360 connecting remotely.
- Run security and audit tests; document token lifecycle and scope requirements.

Deliverable: pilot report with logs, latency measurements, security checklist, and a go/no‑go recommendation to proceed to production rollout.

Technical considerations (from the MCP architecture)

• Transport tradeoffs: use stdio for local, high-performance local process communication; use Streamable HTTP when you need multi-client remote access, standard HTTP auth, and streaming results. Choose both for the pilot to validate each lifecycle stage. (See MCP transport layer description.)
• Data-layer primitives: implement core MCP primitives (tools, resources, prompts, notifications) rather than ad-hoc HTTP endpoints — this preserves interoperability and future-proofs integrations. (See MCP data-layer description.)
• Discovery and versioning: ensure your MCP host (Headless 360) can call server/discover and handle capability/version discovery; use explicit version compatibility checks in CI. (See MCP discovery guidance.)
• Notifications: use MCP notifications for real-time updates and progress tracking of long-running tool executions; evaluate their fit against existing Salesforce eventing patterns.

Organisational & governance checklist

• Roles: assign an MCP integration owner (platform engineer), an Agentforce owner (product/ops), and an information-security reviewer.
• Policy: define allowed context types, PII filtering rules, and retention for context carried over MCP.
• Observability: capture request/response traces, transport-level latency, and tool execution errors; integrate with existing SRE dashboards.
• Procurement: if you adopt third-party MCP server implementations, track license and support terms.

Risks and mitigations

• Risk: transport mismatch (e.g., relying only on stdio for production). Mitigation: validate Streamable HTTP during the pilot and require it for multi-tenant/remote hosts.
• Risk: uncontrolled context leakage. Mitigation: apply context redaction, scope tokens, and strict resource access controls.
• Risk: developer fragmentation (multiple non‑standard adapters). Mitigation: standardize on MCP primitives and publish SDK usage patterns in your internal developer portal.

---

# Headless 360 operating-model: a concise point of view

Headless 360 should operate as the enterprise signal fabric that consistently supplies context to agents while decoupling model execution from context management. Practically, that means:
- Platform engineers own MCP server deployments and maintain the schema of tools/resources/prompts exposed to agents.
- Product teams consume those primitives through Headless 360 Builder and AgentExchange, focusing on business logic rather than transport details.
- Security and compliance own context governance and approval gates for any production MCP endpoints.

This operating model minimizes coordination friction: Headless 360 provides the “connective tissue” (context + developer tooling); MCP provides the protocol; Agentforce provides the agent runtime and business-facing orchestration.

---

Concise FAQ

Q: Why MCP instead of building a proprietary API?
A: MCP standardizes discovery, tools, and notifications in a JSON-RPC data-layer plus two transport options. That reduces the long-term cost of adapters and improves interoperability across internal and third-party agent runtimes. (Source: MCP docs.)

Q: Which transport should I pick for production?
A: For production multi-client and remote scenarios use Streamable HTTP with OAuth/API-key protections; use stdio for local development and single‑process scenarios. Validate both in the pilot. (Source: MCP docs.)

Q: Does this replace Salesforce security controls?
A: No — MCP endpoints must be governed alongside Salesforce controls. The pilot should validate authentication and token scope alignment between Headless 360 and your Agentforce instances. (Source: Salesforce Agentforce pages + MCP docs.)

Q: Where do I start as a product owner?
A: Approve a 90-day pilot, nominate owners (platform, product, security), and define the three acceptance criteria listed above.

---

References

• Salesforce — Agentforce MCP support: https://www.salesforce.com/agentforce/mcp-support/
• Model Context Protocol — Architecture overview: https://modelcontextprotocol.io/docs/learn/architecture
• Salesforce — News Explorer (Agentic Enterprise and Agentforce context): https://www.salesforce.com/news/stories/