What is a CRM for LLMs?

Most CRMs assume a person. They are built around screens: a sidebar, a record page, a drag-and-drop board, a form with required fields hidden three tabs deep. That design is fine when a sales rep is doing the work. It falls apart the moment you hand the job to an LLM. The agent has no eyes, no mouse, and no patience for a modal that pops up on save. What it needs is a clean contract it can call.

A CRM for LLMs - also called an API-first CRM or a CRM for AI agents - inverts the usual priority. The REST API and the MCP server are the product. The human dashboard is a thin layer over the same data, useful for spot-checks but never required. This is the same shift email made with Resend and payments made with Stripe: the interface a developer or an agent touches is the actual product, not an afterthought bolted onto a UI.

Why UI-first CRMs fight agents

Give an agent a HubSpot, Attio or Pipedrive account and you will feel the friction immediately. These systems were designed UI-first, and their APIs inherit every assumption that made sense for a human and none that help a machine:

• The API is a second-class citizen. Coverage is partial, naming is inconsistent between endpoints, and half the useful actions only exist as UI behaviors. The agent hits a wall the moment it needs something the marketing team never exposed.
• Nothing is self-describing. To know that a deal stage must be one of six specific values, the agent has to already know. Send a wrong value and you get a vague 400, or worse, a silent default. There is no way for the model to discover the valid options at runtime.
• Errors are written for logs, not for models. A human reads "invalid property" and knows to check the settings page. An agent reads it and hallucinates a fix, then retries the same broken call.
• IDs are opaque integers. 4815162342 tells the model nothing about what it is holding. Paste it into the wrong endpoint and the failure is confusing instead of obvious.
• The last resort is scraping. When the API cannot do the job, teams reach for browser automation - driving the actual UI with a headless browser. It is slow, brittle, and breaks on the next redesign.

None of this is a bug in HubSpot. It is the correct design for its user, who happens to be a person. The problem is only that the user is now sometimes a language model, and a language model wants a different shape.

What an API-first, MCP-native CRM does differently

Relm is built for the model as the primary operator. A handful of deliberate choices make the difference between an agent that works and one that flails:

• One key, two transports. A single relm_live_ bearer key works over REST at https://api.relmcrm.com/v1 and over the native MCP server at https://api.relmcrm.com/mcp. Function-calling agents use REST; MCP clients like Claude get typed tools. Same data, same auth.
• A live, self-describing schema. GET /v1/schema returns every object, field and enum value that currently exists in your workspace. The agent reads it before writing, so it never guesses.
• Errors a model can act on. Every error is RFC-9457 problem+JSON with a stable type and, where it helps, valid_options and suggestion. This is the "never confused" contract: the response tells the agent exactly how to fix its own call.
• Prefixed IDs. con_ for contacts, cmp_ for companies, deal_ for deals, act_ for activities. The model can tell what it is holding at a glance and route it correctly.
• Idempotency and modes. An Idempotency-Key header makes a retried write safe. A relm_test_ key writes to an isolated, free, unmetered dataset so an agent can rehearse before it touches live data.

The object model

The data model is small on purpose. Four core objects cover the vast majority of CRM work, and each has full CRUD over REST and a matching MCP tool.

Object	ID prefix	What it holds
Contact	con_	People. Email is optional, so phone-only or LinkedIn-only leads are valid.
Company	cmp_	Accounts. Contacts and deals link to them; filter or search by domain.
Deal	deal_	Opportunities that live in a pipeline and stage and carry an amount.
Activity	act_	Notes, calls, emails and meetings, backdatable via occurred_at.

Around those sit the pieces that make the CRM operable without a human: multiple named pipelines each with their own ordered stages, custom fields and enum types you can create at runtime, automations and drip sequences triggered by events, signed webhooks for outbound delivery, and transactional email on your own Resend key. All of it is reachable with the same key.

How an agent actually uses it

The pattern is always the same: read the schema, then act. First the agent learns the shape of the world, then it writes into it. Over REST that looks like one call to create a contact:

curl https://api.relmcrm.com/v1/contacts \
  -H "Authorization: Bearer relm_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "email": "[email protected]", "first_name": "Ada", "last_name": "Lovelace" }'

{
  "id": "con_x8f3k2m9q2",
  "object": "contact",
  "email": "[email protected]",
  "created_at": "2026-07-09T12:00:00.000Z"
}

If the agent sends a field value the workspace does not recognize, the error hands it the answer instead of failing blind:

POST /v1/contacts   { "type": "prospect" }

422 Unprocessable Entity
{
  "type": "https://relmcrm.com/errors/unknown_value",
  "title": "Unknown Value",
  "detail": "'prospect' is not a valid type.",
  "code": "unknown_value",
  "valid_options": ["lead", "customer"]
}

The agent reads valid_options, retries with "lead", and moves on. No human, no guessing.

Inside an MCP client like Claude the plumbing disappears entirely. You point the client at the server once:

{
  "mcpServers": {
    "relm": {
      "type": "http",
      "url": "https://api.relmcrm.com/mcp",
      "headers": { "Authorization": "Bearer relm_live_..." }
    }
  }
}

Then you talk to it in plain language - "add these five leads and open a deal for each in the sales pipeline" - and the model calls relm_describe_schema, then batches the writes. For the full walkthrough see how to give your AI agent a CRM and the MCP CRM server guide.

Who this is for

If you are building an SDR agent, a support copilot, an onboarding bot, or any workflow where an LLM needs to remember people and track opportunities, a CRM for LLMs is the missing piece of state. You get durable, structured memory the agent can read and write without you babysitting a browser. Developers get a clean REST surface; agents get an MCP server; both get the same schema, the same errors, and the same bearer key. Full reference lives in the docs, and the agent hub collects the machine-readable manifests.

FAQ

What is a CRM for LLMs?

A CRM for LLMs is a customer-relationship database whose primary interface is an API and an MCP server, not a dashboard. An LLM authenticates with a bearer key and creates contacts, companies, deals and activities directly - no browser automation, no screen scraping. The human UI is a thin read-only-ish layer on top of the same data.

How is an API-first CRM different from HubSpot or Pipedrive?

UI-first CRMs like HubSpot, Attio and Pipedrive are designed for a human clicking through screens; their APIs are bolted on and inconsistent. An API-first CRM like Relm inverts that: the REST API and MCP server are the product, with a self-describing schema, machine-readable RFC-9457 errors, prefixed IDs and idempotency so an agent can operate reliably without a human in the loop.

Can an AI agent use Relm without any UI?

Yes. Everything you can do in the dashboard is available over REST at https://api.relmcrm.com/v1 or through the native MCP server at https://api.relmcrm.com/mcp using the same relm_live_ bearer key. Agents typically read GET /v1/schema first, then create and update records.

How much does a CRM for LLMs cost?

Relm's Free plan gives 1,000 API requests a month with no card. Pro is $29/mo for 100,000 requests and Scale is $249/mo for 2,000,000. Test mode is free, unmetered and never counted.