What Agent-Native CRM Means: 5 Testable Properties - Relaticle Blog             [  Back to blog ](https://relaticle.com/blog) 

 ![What 'Agent-Native CRM' Actually Means](https://relaticle.com/storage/ink/01M17KWER35G1NK6TDDS6KQSZN.png)Agent-native CRM is not a product category defined by marketing. It is a set of verifiable architectural properties: an AI agent can do everything a human can do in the UI, writes are governed by a safety model built for agents rather than borrowed from human permissions, self-hosted and cloud deployments carry identical agent capability, the product's own surfaces speak machine-readable formats to agents, and the agent tooling ships as a first-party part of the product's own release, not a bolted-on integration. Every one of those five properties has a concrete test you can run against any CRM in about five minutes. "Has an MCP server" is not on the list, because it is table stakes now. [Twenty shipped a first-party MCP server in 2026](https://relaticle.com/blog/relaticle-vs-twenty-an-honest-comparison), documented for both its cloud and self-hosted deployments. Having one tells you nothing about whether it can set a custom field, whether it asks before it deletes 50 records, or whether any of it works if you self-host.

This post lays out the checklist, explains how to run each test yourself, and scores Relaticle against it, including the places it falls short today.

![The five properties of an agent-native CRM: full write surface, safety model, deployment parity, machine-readable surfaces, first-party tooling](https://relaticle.com/storage/ink/01M09E1Z3ANQT32PBZFDFZ054B.png)

[](#property-1-full-write-surface-for-agents "Permalink")Property 1: full write surface for agents
--------------------------------------------------------------------------------------------------

The test: create a custom field in your CRM that exists nowhere else, one your engineering team didn't anticipate, then ask the agent to set it. If the agent says "I can't do that" or silently ignores the field, the write surface is a subset of the UI, and every custom field your team adds becomes something your agent quietly can't touch.

In Relaticle, custom fields are not hardcoded into the agent tooling. `CustomFieldsSchemaDescriber` (`packages/Chat/src/Services/Tools/CustomFieldsSchemaDescriber.php`) builds a per-tenant description of every active custom field for chat, including type, format hints, and the exact option labels for choice fields, and inlines it into the tool schema the model sees. On the MCP side, `BaseCreateTool` and `BaseUpdateTool` (`app/Mcp/Tools/`) accept a `custom_fields` object validated by the same `App\Rules\ValidCustomFields` rule used by chat. Add a field in the Custom Fields admin UI and both surfaces expose it immediately, no code change required.

That coverage has one honest boundary: file-type custom fields. The schema describer labels them "file (read-only via chat)" on purpose, because neither the chat tool schema nor the MCP tool schema has a binary upload channel, only JSON. An agent can read that a file field exists and reference its value, but it cannot upload the file itself over a text-protocol tool call. That's a constraint of text-based agent protocols generally, not something more code fixes here, but it means "full write surface" has a real asterisk.

[](#property-2-a-safety-model-designed-for-agents-not-borrowed-from-humans "Permalink")Property 2: a safety model designed for agents, not borrowed from humans
---------------------------------------------------------------------------------------------------------------------------------------------------------------

The test: ask the agent to delete 50 records in one request, then check what actually happened to your database before you can undo it. A safety model built for humans (a delete button with a confirm dialog) doesn't map cleanly onto an agent that can issue the same request a thousand times a minute. An agent-native CRM needs two distinct answers: one for a conversational agent acting on a user's behalf in real time, and one for a scoped integration acting autonomously.

Relaticle answers this with two different mechanisms for two different trust levels. Chat writes never touch the database directly. Every create, update, or delete proposed in conversation becomes a `PendingAction` row (`packages/Chat/src/Models/PendingAction.php`) with a `pending` status, an expiry, and the diff the user is being asked to approve; nothing executes until a human clicks approve. MCP is the other half ([how to connect a client](https://relaticle.com/blog/how-to-connect-claude-to-your-crm-with-mcp)): a scoped integration authenticated with an OAuth token or personal access token acts directly, no approval step, because the trust boundary was already crossed at token-issuance time, not at write time. Every MCP tool that performs a destructive action declares an explicit destructive hint in its MCP tool annotations (`app/Mcp/Tools/Company/DeleteCompanyTool.php` and its four siblings for people, opportunities, tasks, and notes) so any MCP client, human or agent, can see which calls are irreversible before it makes them. Token abilities are checked per-call in `ChecksTokenAbility`, and OAuth clients get exactly one scope, `mcp:use`, deliberately coarse because the finer-grained boundary is which team's data the token is bound to, not which verbs it can call.

This is the property where "has an MCP server" tells you the least. A server can expose write tools with no approval step and no destructive annotations at all, and you'd only find out by testing it, not by reading a feature list. Run this test against any CRM's MCP server: ask it to delete something, and see whether the tool call itself declares that it's destructive before you approve the client to use it.

![A Relaticle chat pending-action card showing the old to new diff for an opportunity update before the write commits](https://relaticle.com/storage/ink/01M09G7HW5H8W6X736JJVEGT6Y.png)

[](#property-3-deployment-parity "Permalink")Property 3: deployment parity
--------------------------------------------------------------------------

The test: point the same agent workflow at a self-hosted instance with no internet-routed cloud dependency, and see what breaks. If chat degrades to a stub, or MCP just isn't there, the agent capability was cloud infrastructure wearing a CRM's branding.

Relaticle's chat and MCP routes are gated by `EnsureHostedWorkspaceAccess`, which delegates to `HostedWorkspaceAccess::allows()` (`app/Services/Billing/HostedWorkspaceAccess.php`). That gate checks a `Billing` feature flag first, and returns `true` unconditionally when it's off, which is the self-hosted default. There's no separate "self-hosted tier" of the agent tooling; it's the same billing gate the rest of the product uses, off by default outside the hosted product. `config/ai.php` configures Ollama (`OLLAMA_BASE_URL`, defaults to `localhost:11434`) and a generic `selfhosted` OpenAI-compatible provider alongside the hosted providers, so the model backing chat can run entirely on infrastructure you control. Facts file: 37 MCP tools, chat, and Ollama all work self-hosted (`resources/data/competitor-facts.php`, verified 2026-08-30).

Our own facts entry for Twenty used to read "marketed for Cloud workspaces," phrasing lifted straight from the vendor's pricing page. Checking Twenty's docs instead of its marketing showed self-hosted MCP has been documented since March 2026, so we corrected the entry. That is exactly the kind of claim the checklist exists to force you to verify rather than take on faith, ours included.

[](#property-4-agent-legible-surfaces "Permalink")Property 4: agent-legible surfaces
------------------------------------------------------------------------------------

The test: request a documentation page with `Accept: text/markdown` instead of `text/html`, and see what comes back. If you get the same HTML with the same navigation chrome and marketing script tags an agent has to parse around, the surface wasn't built with agents as a first-class consumer.

Relaticle's `/developers` and `/help` routes run through `Spatie\MarkdownResponse\Middleware\ProvideMarkdownResponse` (`packages/Documentation/routes/web.php`). This is real content negotiation, not a static markdown mirror: the middleware inspects the `Accept` header, converts the HTML response to markdown on a cache miss, and returns it with `Content-Type: text/markdown`, a `Vary: Accept` header, and an estimated token count. An `/llms.txt` route (`packages/Documentation/src/Http/Controllers/HelpController.php`) lists what's available, explicitly documented in its own code comment as a discovery aid for agents, not a search-ranking mechanism, since general web search doesn't read it.

[](#property-5-first-party-versioned-with-the-product "Permalink")Property 5: first-party, versioned with the product
---------------------------------------------------------------------------------------------------------------------

The test: check whether the MCP server or agent tools live in the product's own repository and ship with its own releases, or whether they're a separate package, a community wrapper, or something that can silently drift out of sync with the core product's version.

Relaticle's 37 MCP tools live in `app/Mcp/`, the same directory tree as the CRM's Filament resources and Eloquent models, registered on a single `RelaticleServer` class versioned at `2.0.0`. The chat package (`packages/Chat/`) has no `composer.json` of its own; it's autoloaded straight from the root `composer.json` under the `Relaticle\Chat` namespace, which means it has no independent version number to fall out of sync, no separate release cadence, and no possibility of a chat feature announcement that describes a version of the tools nobody has installed yet. Whatever commit ships the CRM ships the agent tooling.

[](#scoring-relaticle-honestly "Permalink")Scoring Relaticle honestly
---------------------------------------------------------------------

Two of these five properties have real gaps worth naming plainly, both found by tracing the write path rather than reading a feature list.

The first is board ordering. Moving an opportunity to a different pipeline stage works from chat or MCP, because stage is itself a custom field and flows through the same bridge as every other custom field. But reordering a card within a stage, the `order_column` value the Kanban board uses for its decimal-position drag-and-drop, is not in `UpdateOpportunityTool`'s schema and not in the `UpdateOpportunity` action's allowed attribute list. An agent can tell you a deal moved to "Negotiation." It cannot currently put it above or below a specific other deal in that column. That's UI-only today.

The second is the file-field boundary already noted in property 1: file-type custom fields are readable but not writable through either agent surface, because neither is a binary transport.

| Property | How to test it | Relaticle | Typical SaaS CRM |
|---|---|---|---|
| Full write surface | Add a custom field, ask the agent to set it | Every active custom field auto-exposed to chat and MCP; file-type fields are read-only (no binary channel in a text tool call) | Custom fields often invisible to the agent or require you to hand-build the schema bridge |
| Safety model for agents | Ask the agent to delete many records, then check what happened before undo | Chat proposes, a human approves (`PendingAction`); MCP writes directly under a scoped token, destructive tools carry an explicit annotation | Frequently all-or-nothing: either everything needs a human, or nothing does, with no declared distinction |
| Deployment parity | Run the same workflow against a self-hosted instance with no cloud dependency | Chat, MCP, and Ollama all run self-hosted, gated by the same billing flag as the rest of the product (off by default self-hosted) | MCP server marketed for cloud workspaces; self-hosted parity undocumented |
| Agent-legible surfaces | Request docs with `Accept: text/markdown` | Real content negotiation returns markdown with token-count headers; `/llms.txt` served at the root | Usually plain HTML regardless of `Accept`, or a hand-maintained markdown mirror with no negotiation |
| First-party, versioned with the product | Check whether the tooling ships in the product's own repo and release | 37 MCP tools and the chat package live in the CRM's own repository with no separate version to drift | Varies; some vendors ship agent tooling as a separate package or a marketing-only cloud feature |

Neither gap is disqualifying on its own, and neither is hidden behind a caveat nobody will read. They are what "full write surface" actually looks like once you go looking for the edges instead of taking the headline at face value.

[](#the-test-to-run-on-any-vendor "Permalink")The test to run on any vendor
---------------------------------------------------------------------------

None of the five properties above require trusting a vendor's word. Each one is a specific action you can take in under ten minutes: create an unusual custom field and ask the agent to set it, ask an agent to delete something and see what happens before undo, point the workflow at a self-hosted deployment, request a docs page with a markdown `Accept` header, and check whether the agent tooling lives in the product's own repository or a side project.

Run those five tests against Relaticle at [relaticle.com/developers/mcp](https://relaticle.com/developers/mcp), and against whatever else you're evaluating, including Twenty. The full breakdown of pricing, self-hosting, and AI capability differences between the two is at [relaticle.com/compare/relaticle-vs-twenty](https://relaticle.com/compare/relaticle-vs-twenty). "Agent-native" should be a claim you can fail. If a vendor's checklist only ever produces green checkmarks, you're reading marketing copy, not an architecture.

 Tagged: [ #mcp ](https://relaticle.com/blog/tag/mcp) 

 Related posts
-------------

 [  Guides   Aug 28, 2026  

 How to Connect Claude to Your CRM with MCP 
--------------------------------------------

Connect Claude to Relaticle via MCP in minutes: OAuth setup, all 37 tools explained, and why MCP writes commit directly with no approval gate.

 ![How to Connect Claude to Your CRM with MCP](https://relaticle.com/storage/ink/01M17KWD0RMP42X0P5Z8T29ZYP.png) ](https://relaticle.com/blog/how-to-connect-claude-to-your-crm-with-mcp) [  Guides   Aug 18, 2026  

 Self-Hosting an AI-Native CRM in 2026 
---------------------------------------

Self-hosting Relaticle with Docker, Coolify, or Dokploy, plus a local Ollama model: the AI chat and full MCP tool suite with no cloud subscription.

 ![Self-Hosting an AI-Native CRM in 2026](https://relaticle.com/storage/ink/01M17KW7J3RKP1743041AJCDMP.png) ](https://relaticle.com/blog/self-hosting-an-ai-native-crm-in-2026) 

    ###    On this page
