What 'Agent-Native CRM' Actually Means

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, 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.

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

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): 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.

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

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

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

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.

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

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, 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. "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.