Headless 360, MCP and AI coding agents

Headless Salesforce is an architectural pattern in which you decouple the backend (the Salesforce data, business logic, validation rules, automation and permissions) from the frontend (the presentation layer the user sees). The “head” is the interface; “headless” means you leave that head out or replace it with something of your own.

In a traditional Salesforce setup, data and UI are tightly interwoven: users log in to Lightning Experience or an Experience Cloud site and the screens are rendered by Salesforce itself. In a headless setup, Salesforce exposes its capabilities through APIs, and an external layer (a React or Vue app, a mobile technician app, an IoT system or an AI agent) consumes that data. Users often do not even notice that Salesforce is the engine under the hood.

Important: headless is not the same as “just using APIs”. It is a deliberate choice to move the presentation layer outside the platform while keeping governance, security and the data model inside Salesforce. That way Salesforce remains the single source of truth, even when the interface is fully your own. Headless is not a way to leave Salesforce; it is a way to use it more deeply and more broadly.

Yes. Salesforce is technically well suited as a backend or headless CRM, and in practice it has been used that way for years before the official term existed. The building blocks were already there: the REST and SOAP APIs, the Bulk and Streaming APIs, the Connect API, the Composite API for bundling calls, and User Interface APIs that return metadata and layout information.

Service-intensive and asset-intensive organisations use Salesforce-as-a-backend for things like a customer portal with its own design system, a field service app that works offline on the installed base, a consumption or telemetry frontend for assets, or an integration in which another system provides the screen while Salesforce keeps the truth about customer, asset, work order and case.

The real question is not whether you can, but whether you do it wisely: authentication (OAuth 2.0, JWT bearer flow for server-to-server), respecting governor and API limits, enforcing sharing rules and field-level security outside the standard UI, and keeping the extra codebase you maintain yourself manageable. That is exactly where architecture choices and experience make the difference.

Salesforce Headless 360 is the programme Salesforce presented at TrailblazerDX (15 April 2026) to make the entire platform API-first. The principle: every capability that used to require a logged-in user, a Setup menu or a Lightning page becomes reachable through three surfaces. According to Salesforce this covers over 4,000 existing REST APIs, more than 60 new Model Context Protocol (MCP) tools and more than 220 CLI commands. On top of that, over 30 preconfigured coding skills provide context to MCP-compatible AI coding agents such as Claude Code and Cursor, and more broadly agents such as Codex and Windsurf.

The Model Context Protocol (MCP) is an open standard that lets AI agents discover and invoke tools. In a Salesforce context this means an agent can dynamically find which actions are available and execute them with the right context: field definitions, validation rules and object relationships. Salesforce sums it up as “the new consumer is the agent”.

It is worth keeping two kinds of MCP servers apart. The Salesforce DX MCP Server (Beta, present by default in Code Builder) runs on the developer machine, uses local auth files and is meant for development against sandboxes and scratch orgs. The Salesforce-hosted MCP servers (GA for Enterprise Edition and up) are hosted, authenticated and permission-enforced by Salesforce itself, serving mainly business and runtime scenarios. They are not the same service, and that distinction matters for both data security and governance.

For Outbirds, headless is not a future promise but daily practice. We already help organisations build headless and custom Salesforce with AI coding agents: Claude Code and Cursor, and more broadly MCP-compatible agents such as Codex and Windsurf. This is applied agentic engineering ON Salesforce: the agents work in the IDE or CLI the developer already uses and talk to the org through MCP, without a separate toolchain.

Concretely, those agents build on your Salesforce DX project and metadata. Through the DX MCP Server they query object schemas, write and modify Apex classes, triggers, flows and validation rules, run tests, create scratch orgs and deploy metadata, without leaving the IDE. Quality tools such as ApexGuru (which flags anti-patterns like SOQL or DML in loops) and the coding skills with built-in validator hooks bring reviews and best practices straight into the workflow. The result: faster, more reliable building on DX and metadata.

This is precisely the foundation under a good headless architecture. The APIs, custom frontends, integration layers and agent tools you use headless are themselves built, tested and deployed, and that is exactly where AI coding agents accelerate the work. For us, implementation, headless and agentic are not three separate products but three facets of one partnership in which Salesforce remains the core. And to be honest about it: Salesforce provides the access layer, but no built-in code governance layer that automatically checks agent output for technical debt or conventions. Your own quality gates, reviews, tests and deploy gates remain necessary and are part of the Outbirds approach.

Yes, provided you set it up deliberately. The core line: your work environment and data, always secure and enterprise-grade. In custom development, the AI coding agents work primarily on source code, metadata and configuration in your own environment. We work sandbox-first and scratch-first; a scratch org by definition contains no data or metadata from your production org, so you develop and test without customer data going to the model. Customer data stays in the Salesforce org.

At the same time, we are not naive: the Headless 360 tools can also run against production with read-write access and include SOQL queries, creating or updating records, and data export. The technology does allow data traffic. That is why deliberate restriction leads. We work with a dedicated least-privilege integration user, encrypted auth files, explicit org allowlisting (the –orgs flag, with ALLOW_ALL_ORGS discouraged) and selective tools (the –tools flag), so an agent can only do what it genuinely needs to do.

The org remains the system of record. Headless 360 enforces four layers regardless of the entry point: identity (the agent acts as a specific user), access (sharing rules, field-level security and permission sets determine what is allowed), invocation scope (only explicitly exposed tools), and governance (validation rules, triggers, approval chains and governor limits always fire). From API version 67.0 onwards, database operations also run in user mode by default rather than system mode. For runtime agents such as Agentforce, the Einstein Trust Layer adds zero data retention and grounding.

Headless pays off most where an own channel, a specific UX or asset data justify it. For service-intensive and asset-intensive organisations we see four recurring patterns.

Technician apps and field service: an own, offline-capable app for engineers that shows work orders and service appointments and updates service history per asset, while Salesforce (Service Cloud and Field Service, with the shared Work Order object) keeps the truth. Field Service itself already offers an offline-first mobile app; headless is the choice when you need a brand-specific or highly specialised flow.

Customer portals: a portal with its own design system where customers see contracts, maintenance subscriptions, open cases and invoices on their installed base. For many portals Experience Cloud is faster and cheaper; go headless when pixel-perfect branding or an existing frontend team tips the balance.

IoT and asset data: telemetry and consumption data from assets flowing into the platform through Streaming and Bulk APIs or Data 360, so preventive maintenance (Maintenance Plans and Maintenance Assets) and usage-based billing in Revenue Cloud / RLM can run on real usage data.

Service channels and agents: chat, messaging, voice or an AI agent as an entry point onto the same Salesforce core, where the agent gets exactly the actions you allow through MCP tools. That way you connect new channels without fragmenting your data model or governance.

These three terms describe how strongly your system is decoupled, and they are not mutually exclusive.

Monolithic means data, logic and interface form one whole. A standard Salesforce org with Lightning pages is essentially monolithic: quick to set up, little to maintain, but you are bound to how Salesforce renders the UI.

Composable refers to an architecture built from separate, reusable business capabilities (often via APIs) that you combine like building blocks. It is about modularity on the backend and integration side: you pick the best service per function and connect them. Headless is specifically about decoupling the presentation layer from the backend. A system can be headless without being fully composable, and composable without necessarily being headless.

In practice it is a sliding scale. Most organisations benefit most from a hybrid: the majority inside Salesforce (fast, governed, low maintenance), and only those screens or integrations headless where an own UX, performance or a specific channel truly demands it.

This is the most concrete headless choice Salesforce customers face: do you let Salesforce render the portal screens (Experience Cloud) or do you build your own frontend (for example in React) on the APIs?

Experience Cloud is the right choice when: you want to go live quickly, the UX can stay close to standard Salesforce patterns, you want little frontend maintenance, and authentication, sharing and security should come out of the box. You get LWR templates, built-in Salesforce identity and direct access to the data model without your own middleware.

A custom React frontend is the right choice when: you need a brand-specific, pixel-perfect UX or complex interaction the standard does not offer, you have an existing design system or frontend team, or you want to reuse the same backend across multiple channels (web, mobile, kiosk, technician app). The price: you maintain your own codebase, arrange your own hosting, and must explicitly ensure sharing rules and field-level security are respected in your layer. This is exactly where AI coding agents help build and maintain that codebase faster and more consistently.

New since Headless 360 is the multi-framework approach: React can also run on-platform. Embedding React as a micro-frontend inside Lightning Experience was in developer preview at the time of writing. That shrinks the historical either-or of “choose React or Salesforce governance”: increasingly, you can have both.

Headless gives freedom but relocates complexity. The main trade-offs:

Governor and API limits still apply. A headless consumer counts towards the same limits as any integration. For an Enterprise org that is in the order of 100,000 API calls per 24 hours, with per-transaction limits such as 100 SOQL queries, 150 DML statements and 6 MB heap. AI agents can drain those limits faster: an agent conversation often consists of multiple actions and can fire many queries in a short time. Concurrency and limit monitoring become a design concern, not an afterthought.

Security partly shifts to your responsibility where you leave the standard UI. Headless 360 keeps identity, access, invocation scope and governance uniformly in place, but in your own frontend you must also present and enforce those outcomes correctly. And because Salesforce provides the access layer but not the code governance layer, your own reviews, tests and deploy gates remain essential.

Costs sit in maintenance and knowledge. Your own codebase, hosting, CI/CD, monitoring and a team that understands both Salesforce and frontend. In return you get better UX, faster channel-independent redevelopment and future-proof agent access, and AI coding agents lower the build and maintenance burden. The honest rule of thumb: go headless where it adds value, and keep the rest on-platform.

An honest decision framework belongs here. Headless is often not the best choice when:

Your workflows are mostly sequential and transactional and the standard Lightning or Experience Cloud UX suffices. Then an own frontend mainly adds maintenance and risk without clear gains.

Your API budget is tight or you expect many concurrent users or agents; you will hit governor and API limits sooner than you would like.

You have no frontend capacity in-house or through a partner to sustainably maintain the self-built layer. A headless project nobody maintains becomes technical debt. Likewise, when the need is mainly “live fast, standard UX, low TCO”, Experience Cloud or standard Lightning are usually faster, cheaper and safer.

Headless is a means, not a goal. The right question is not “how do I become headless?” but “which screens, channels and agent interactions call for decoupling, and which do not?”. Often the answer is a hybrid architecture: a governed Salesforce core with targeted headless components where UX, performance or an AI agent justify it. That way you avoid needlessly giving up the simplicity and governance of the platform.

What is headless Salesforce in one sentence?

Headless Salesforce is using Salesforce as an API-first backend for data, logic and workflows, while the user interface (the “head”) runs separately, for example as a custom React app, technician app or AI agent. Salesforce remains the single source of truth.

What is Salesforce Headless 360?

Salesforce Headless 360 is the programme launched at TrailblazerDX (15 April 2026) that makes every Salesforce capability reachable through over 4,000 REST APIs, more than 60 MCP tools and more than 220 CLI commands, even without a browser. Salesforce sums it up as “the new consumer is the agent”: MCP-compatible AI agents can drive the platform the way only users and developers could before.

Does Outbirds already build headless and custom Salesforce with AI coding agents?

Yes. Outbirds already helps organisations build headless and custom Salesforce with AI coding agents such as Claude Code and Cursor, and more broadly MCP-compatible agents such as Codex and Windsurf. Those agents work on your Salesforce DX project and metadata (Apex, flows, validation rules, tests, scratch orgs and deployments), sandbox-first and scratch-first, so you build faster and more reliably while customer data stays in the org.

Is AI-assisted building on Salesforce secure and enterprise-grade?

Yes, provided it is set up deliberately: your work environment and data, always secure and enterprise-grade. In custom development the agents work primarily on source code, metadata and configuration against sandboxes or scratch orgs, which contain no production customer data. The Headless 360 tools can technically run SOQL, DML and exports against production, so we deliberately restrict that with a least-privilege integration user, org allowlisting (–orgs) and selective tools (–tools). The org enforces identity, sharing rules, field-level security and governor limits; for runtime agents such as Agentforce, the Einstein Trust Layer provides zero data retention and grounding.

Which headless use cases fit service-intensive and asset-intensive organisations?

Four in particular: offline-capable technician apps on work orders and assets, customer portals with their own design system on contracts and the installed base, IoT and asset data through Streaming, Bulk or Data 360 for preventive maintenance and usage-based billing, and service channels or AI agents as entry points onto the same Salesforce core.

Does headless Salesforce replace my existing org?

No. Headless decouples the presentation layer, but your data model, automation, security and governance stay in Salesforce, which remains the system of record. In practice a hybrid works best: a governed Salesforce core with targeted headless components where an own UX, channel or AI agent truly justifies it.

Do governor limits also apply in a headless Salesforce architecture?

Yes. Headless consumers count towards the same governor and API limits as any integration (for Enterprise in the order of 100,000 API calls per 24 hours, and per-transaction limits such as 100 SOQL queries, 150 DML statements and 6 MB heap). AI agents can drain those limits faster, so limit monitoring and concurrency belong early in the design.

When do I choose Experience Cloud over a custom frontend?

Choose Experience Cloud when you want to go live fast, a UX close to standard Salesforce suffices and you want little frontend maintenance; identity, sharing and security come out of the box. Choose a custom (React) frontend when you need a brand-specific UX, an existing design system or channel-independent reusability, and accept that you then maintain your own codebase (with AI coding agents speeding up building and maintenance).