Headless CRM: a CRM served to agents and your code

A headless CRM keeps the back end of a CRM (the records, the data model, the business rules and the permissions) and lets you choose the front end. A traditional CRM ships one interface and treats its API as a sync channel for other tools. A headless CRM ships the API as the product and treats the vendor's screens as one client among others, next to your customer portal, an internal tool, a Slack bot or an AI agent. Salesforce's own headless CRM page defines it as back-end data and logic decoupled from the user interface. The term comes from headless commerce and headless CMS, where the same split separates the content back end from the storefronts and sites built on it. In a CRM each new front end reaches clients, deals and contracts, so each one has to respect who may see and change what.

Salesforce announced Headless 360, a program that exposes its CRM to AI agents without a browser, on April 15, 2026, in a news story titled “Introducing Salesforce Headless 360. No Browser Required.” The announcement states that “Everything on Salesforce is now an API, MCP tool, or CLI command, and agents can use all of it.” It adds: “in the Agentic Enterprise, humans aren’t the only ones doing the navigating.” On August 19, 2026, Salesforce expanded the program and wrote that “Pricing and packaging are subject to change.” A team picking a CRM in late 2026 can ask any vendor the same question: can an agent do the work without the screens, under the same rules as a person? Each fact below is dated as Salesforce published it (read October 2026).

A CRM API designed for agents tells the agent what exists, gives it only the actions its credential allows, and refuses the rest in a shape the agent can read and act on. Salesforce Headless 360 and Standards both serve their CRM as MCP tools; Standards lists only the tools a key can use and checks each call again against the record it touches. A REST API written for integration developers assumes a person reads the documentation first. The crmswitch headless CRM guide (updated September 2026) sums up the test as “Can everything the UI does be done without it?”

A headless CRM lets each team that touches customer data work from the tool it already uses, on one set of records and rules. With Standards, an AI agent connected over MCP searches, reads and updates records within its key's permissions. A CI script lists or updates records with the Standards CLI and reads the result as JSON or CSV. Your customer portal or internal tool calls your own server, which reads typed records through the Standards SDK, so no key reaches the browser. The sales team keeps working in the app on the same records and adds the fields it needs from there, and the next sync of your code keeps them. A new front end adds a client and leaves the data model and the permissions as they are.

Standards is a hosted back end for business data: you declare your objects in TypeScript, sync them, and every client reads and writes them through one REST API at https://api.standards.new/v1. The SDK, the CLI and the MCP server are three doors onto that API. They use the same API key and see the same permissions; the docs page How it works puts it as “Nothing you build with one is hidden from the others.” The key carries its workspace, so a request names none, and the key's roles decide which objects it may read and what it may change. Standards also hosts the database, search, file storage, the agents and the app at app.standards.new, where your team keeps working on the same records. Your repository holds the schema declarations and the code that calls the API, and the keys stay yours. The SDK runs on a server: createStandards refuses an API key inside browser code, so a front end of yours calls your own server, which calls Standards.

The three doors serve different readers:

• The SDK (@standards/client) gives your server typed records: a create or update refuses a select option the object does not declare, a filter refuses an attribute that does not exist, and TypeScript flags both before the API does.

• The CLI (@standards/cli) lists, searches, creates and updates records from a terminal, in JSON, table or CSV, for scripts and CI.

• The MCP server gives an AI agent the tools its key allows; the next section shows what it receives.

The developer page at standards.new/en/developers gathers the three entry points.

Point Claude Code, Codex or Cursor at https://api.standards.new/v1/mcp, the Standards Model Context Protocol server, sign in or paste an API key (Cursor takes a key only), and the client receives up to eight tools. A tool your key cannot use is absent from the list, according to the MCP tools documentation: an agent holding a read-only key never sees write or delete, as the agent workflow walkthrough shows with a live key. Standards then checks each call again against the object it touches; in a batch it reports a refused record on its own and lets the others succeed. On connection the server introduces the workspace. It lists the objects the key can read, one line each, then the usage rules and links to the documentation written for agents. The rules ask the agent to read an object's schema before writing to it and to confirm a delete with the user before calling it; deletes are reversible. search, query and read carry readOnlyHint, and the tools that overwrite or remove (write, edit_content, organize, delete) carry destructiveHint, so a client can decide when to ask you before a call.

In Standards, developers declare the data model in code, and the people who use the CRM still add fields of their own. The objects and attributes your code declares are system objects: the sync writes them, and nobody can rename, retype or delete them in the app. Your users add their own attributes and saved views on top, from the app or over the API with the right permission and without filing a ticket, and every later sync keeps them. A sync with no change answers in one request and writes nothing; a renamed attribute stops the sync before any write until you say whether to keep its values. Agents read the extended model too, because read schema:<object> returns the attributes people added alongside the ones your code declared. Salesforce's and crmswitch's headless CRM guides (read October 2026) do not say where those users add a field.

With a headless CRM, your team designs the front ends, decides what each agent may touch, and handles its failures. crmswitch's guide makes the same point and adds that most organizations will run a mix of screens and API for a long time. Standards answers part of this: the app stays available for the people who prefer screens, and the agents Standards runs act with their own role intersected with the roles of the person they work for. An agent you connect with a personal key or an OAuth sign-in never does more than that person's current roles allow. Standards has limits to weigh before choosing it, all stated in the security and hosting documentation:

• After a sign-out, an access token already issued stays valid until it expires, about one hour; a dedicated instance can be set to check each token with the auth server, which cuts that window to 30 seconds.

• Standards is not open source.

• The shared API runs at api.standards.new; a dedicated instance runs the same API under your hostname, and a licence lets your team run Standards on its own infrastructure.

Compare it with the CRMs you already know on the comparison pages.