Dreamforce returns to Moscone Center on September 15–17 with 1,600-plus sessions organised around what Salesforce is calling the Agentic Enterprise. The session catalog is worth reading when it lands, but the architecture it will describe is not speculative — most of it shipped between April and July, and you can evaluate it now without waiting for a keynote.

Three things are already in developers’ hands, and one design decision runs through all of them that is more interesting than the branding.

What actually shipped

Headless 360, announced at TDX 2026 on April 15, exposes the platform’s capabilities — CRM, Agentforce, Data Cloud, Slack — as APIs, MCP tools, and sf CLI commands. The stated scope is 60-plus new MCP tools, 30-plus preconfigured coding skills, native React support for custom UIs, and the Agentforce Experience Layer.

The Agentforce Experience Layer (AXL) separates what an agent does from how it renders. An agent returns a decision tile or a renewal summary, and that component renders natively inside Slack, Teams, ChatGPT, Claude, Gemini, or any MCP-compatible client. Build the logic once, let the layer handle surface-specific rendering.

The Headless 360 MCP Server entered beta in early July. It runs as a Salesforce-hosted server, activated in Setup under Salesforce Hosted MCP Servers, and its beta scope covers user management (create, deactivate, reset passwords, assign permission sets), Apex trigger read/write/deploy, event-driven integration surfaces (platform events, Change Data Capture, event relays), and named credential management.

The Data 360 MCP Server has been in Developer Preview since May. It is open source, speaks stdio transport, and connects to MCP clients including Claude Code, Cursor, and Codex. It runs locally, single user per org instance, and needs Java 17+, Maven 3.9+, and a Data 360-enabled org. Its tool families cover Data Streams, Mappings, Data Transforms, Identity Resolution, Calculated Insights, Segments, Connections, Query, Activation, Semantic Data Models, AI and search indexes, and GDPR handling.

Alongside that, @salesforce/mcp — the DX MCP server — lets AI coding agents connect directly to orgs, with the core package available since April.

The design decision worth copying

Both MCP servers solve the same problem the same way, and it is the most transferable idea in the whole release.

Salesforce’s API surface is enormous. A naive MCP server would register a tool per operation — thousands for the platform, roughly 200 for Data 360 alone — and hand the model a tool list so large it consumes the context window before any work happens. Tool-selection accuracy also degrades badly once the list gets long.

Instead both servers expose a handful of facade tools and make discovery a runtime operation:

  • Data 360 ships three: Search (find capabilities by intent or keyword), Payload Examples (fetch JSON templates for complex requests), and Execute (run the operation).
  • Headless 360 ships four: Discover (semantic search across APIs and skills, returning ranked candidates), Describe (technical specification — APIs, parameters, dependencies, and the ordered steps), Dispatch, and Dispatch Read Only.

Salesforce’s own framing is that this “saves context window space and improves the accuracy of the AI’s actions.” That is the right justification and it generalises. If you are building an MCP server over any large internal API, the instinct to map endpoints one-to-one onto tools is wrong, and this is the pattern to reach for instead: a search tool, a schema tool, and an execute tool, with the catalog itself as data rather than as tool definitions.

The split between Dispatch and Dispatch Read Only is a second detail worth stealing. It gives the surrounding system a way to grant an agent broad read access and narrow write access without maintaining two servers or a permission matrix over hundreds of individual tools.

The security model is the part to actually read

For MarTech integration work, this is where the evaluation should concentrate, because it is where a bad answer creates a real incident.

Headless 360 MCP transactions run as the authenticated user, through an external client app with the mcp_api scope. Standard platform controls apply unchanged — CRUD, field-level security, sharing rules, profile permissions, and permission sets. Actions are attributed to users in the audit trail.

That is the correct design, and it means the hard questions move where they belong: to provisioning. An agent operating as a user inherits that user’s access. If the integration user was created years ago with a wide profile because narrowing it was inconvenient, the agent now has all of it — and unlike a scripted integration, an agent’s action set is not enumerable in advance.

Before any of this reaches a production org, settle: which user the agent authenticates as, what that profile can actually reach, whether read-only dispatch is sufficient for the use case, and how the audit trail is monitored. “It runs as a user with permission sets applied” is a guarantee about enforcement, not about whether the permissions are appropriate.

What it means for integration work

The near-term effect on MarTech engineering is less about autonomous agents doing the work and more about the shape of the integration layer changing.

Historically, connecting Salesforce to the rest of a marketing stack meant writing and maintaining bespoke client code against specific endpoints. The MCP surface does not remove that need for deterministic, scheduled data movement — you still want an ETL job to be an ETL job. What it changes is the exploratory and operational half: schema discovery, one-off segment work, identity-resolution debugging, and the long tail of “can you check whether X is configured” requests that currently land on an engineer.

Two practical notes on maturity. The Headless 360 server is beta and the Data 360 server is developer preview, single-user and local — neither is a foundation for a production dependency yet, and Salesforce says the Data 360 server is intended to eventually arrive as a hosted GA server. And the June agreement to acquire Contentful, positioned as a content layer for Headless 360 and Agentforce, is not expected to close until Q3 of Salesforce’s fiscal 2027, so nothing in that direction is buildable now.

The useful thing to do before Dreamforce is install the Data 360 preview against a sandbox and watch how the three-tool facade behaves on a real org’s schema. Whatever the sessions say in September, that hour will tell you more about whether this fits your stack than the keynote will.