Relaticle, or a coding agent that writes the CRM rather than operating it?

Relaticle, the agent-operated open-source CRM

People ask this as: relaticle alternative when the agent should reshape the crm rather than operate it

Relaticle describes itself as an open-source CRM with native AI agent support, and the research this page reads credits it with the most agent-forward claim among the incumbents: a first-party MCP server with 30 tools that agents use to operate the CRM. This framework points the agent the other way — at writing the application as code you own. The distinction the research file draws is operate versus reshape, and this page exists to keep the two categories from being confused with each other. Every Relaticle fact traces to that one dated file; nothing was installed or run.

Where this stops

Read this before the rest of the page. Every line below is a thing this does not do.

Every fact about another project on this page is single-sourced to docs/strategy/COMPETITOR_MAP.md and dated 2026-08-04. Nothing from another project was installed, configured or run, and there is no network access here to re-verify any of it.

  • No hands-on evaluation: nothing from Relaticle was installed, configured or run to produce this page.
  • Every competitor fact is single-sourced to docs/strategy/COMPETITOR_MAP.md and dated 2026-08-04.
  • Licence descriptions are factual summaries of published texts, not legal advice.
  • The MCP server here is stdio and local only, with no hosted or authenticated endpoint, and it inherits the local process's authority.
  • No authentication ships; in local-development mode an actor header is an assertion, not an identity (L-01).
  • The synchronous factory uses SQLite; the async factory supports one tenant on dedicated PostgreSQL databases. Shared-database row tenancy and general production readiness are not claimed (L-02).
  • This is a framework whose output you run; the managed Cloud hosts a free Blueprint-configured workspace, and custom code only on a paid Dedicated Cell (L-07).
  • The published create-accordo@0.1.0 scaffolds vendored source; it is the August 19 snapshot, not the current repository feature set. Use a current source checkout for the capabilities described here; upgrades require merging source (L-08).
  • No claim that an agent builds faster or more reliably here — the benchmark has not been run (L-03).

No authentication ships: the framework authenticates nobody. Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim. Every claim and every limitation is on one page.

Where Relaticle wins

On the axis it chose, it is ahead of everything else in the researched set — including this project's own runtime story. The research file — docs/strategy/COMPETITOR_MAP.md, dated August 4, 2026 — records a first-party MCP server with 30 tools, calls it the most agent-forward incumbent claim, and names Relaticle the first mover on agent-native CRM language. It is a working application on a modern PHP stack — Laravel, Filament, PHP 8.4, Postgres — that a developer-led team or an AI-forward SMB can self-host and point an agent at today. The MCP server here, by contrast, is stdio and local only, with no hosted or authenticated endpoint (C-18), and the only hosted product around it is the managed Cloud, which runs Blueprint-configured workspaces for free and custom code on a paid Dedicated Cell (L-07).

Runtime flexibility without a deploy. The file records 22 custom field types and no-migration schema changes — a record can be reshaped inside the running app without touching a repository. And the baseline asymmetry holds here as everywhere on this site: Relaticle is a CRM you can use, while this framework has no authentication ships, and a deployment must supply the verifier (L-01), supports SQLite and dedicated-database PostgreSQL (L-02), and arrives vendored — `npm create accordo` copies the framework source into the project, so ownership means keeping that copy and upgrading means merging (L-08).

Where this is different

One sentence in the research file carries the whole comparison: agents can operate the CRM via MCP but cannot reshape it — the customization is runtime configuration inside a fixed app. Here, reshaping is the point. A module manifest becomes a migration, a service, a REST resource, an SDK method and Admin screens with no page code (C-01); a customer-authored domain package attaches and detaches with the kernel's fingerprint unchanged, reaching other packages only through declared capabilities (C-13); and one command reads checked-in source and reports what the application actually is as deterministic JSON (C-14). The agent's output is a diff a human reviews, not a sequence of tool calls against a schema someone else fixed.

The two projects also disagree about what an agent should be free to do at runtime. Thirty tools operating a live CRM is a large writable surface. The surface here is deliberately narrow and refusal-shaped: anything that generates code or destroys state is dry-run unless an explicit apply flag is passed (C-18), and the boundary that matters commercially is asserted by a test — an agent cannot approve on the human's behalf (C-04). Nothing in the research file proves either posture superior; they are different bets about where an agent's mistakes are cheapest to catch.

The file's category note is the reason this page exists at all: Relaticle defines the adjacent category — AI agents working in a CRM — that this project must not be confused with. A reader who wants agents operating a CRM should take Relaticle's category. A reader who wants an agent to build the CRM, as reviewable code with approvals, audit and trace as primitives, is in this one.

How to choose

Choose Relaticle if you want a working CRM now, operated by agents through a first-party MCP surface; if a modern PHP stack fits your team; if self-hosting is acceptable — the file records self-host as the only deployment; and if AGPL fits what you are shipping. The file also records solo-maintainer risk at 1.5k stars and 167 forks: weigh that as you would for any dependency this central, and check the current state yourself, because those figures are a snapshot from one date.

Choose this framework in the narrow case: the deliverable is a bespoke commercial process that must exist as source in your repository, written mostly by a coding agent and reviewed as a diff, with the approval boundary asserted by a test — and you supply deployment authentication, hosting, connector mapping and complete personal-data operations; dedicated PostgreSQL and bounded customer imports already exist (L-01, L-02).

If your requirement is a hosted, authenticated agent endpoint, neither column is the answer today: the file records Relaticle as self-host only, and the MCP server here is stdio and local, with no identity behind any call (L-01).

What this comparison does not cover

No hands-on evaluation. Nothing from Relaticle was installed, configured, benchmarked or run in producing this page. Every fact traces to docs/strategy/COMPETITOR_MAP.md, researched on August 4, 2026, and this environment has no network access to re-verify any of it.

No tool-by-tool review. The file records that the MCP server has 30 tools and records nothing about what the individual tools do, so nothing about them is described or evaluated here.

No feature matrix and no pricing. The file carries neither for Relaticle, so this page carries neither.

Licence descriptions are factual summaries of published texts, not legal advice.

No build-rate or speed comparison in either direction — the benchmark has not been run, and any number quoted for this project is not ours (L-03). When the competitor research is refreshed, this entry must be re-read against it.

The evidence this page rests on

Claims and limitations are printed from site/claims.json word for word. Job statuses come from docs/benchmarks/jobs.json; a job with no page of its own is listed with its status rather than linked.

Claims

  • C-01 Write a module manifest; the agent turns it into a migration, a service, a REST resource, an SDK method and Admin screens — with no page code.

    LimitGenerated CRUD only. The factory does not generate workflows or approvals for a custom object — that is still handwritten (JTBD-06, partially supported).

  • C-04 The agent cannot approve on the human's behalf. A test asserts the refusal, so the boundary is a property of the system rather than a promise in a README.

    LimitIn local-development mode the actor is asserted, not authenticated: no authentication ships, so an actor header there is not an identity. This holds a boundary against an honest agent, not against an attacker with network access.

  • C-13 A customer-authored domain package attaches and detaches with the kernel's fingerprint unchanged, and reaches another package only through a capability it declares.

    LimitThe scaffold that starts one writes an empty package and nothing else: no business logic, no composition, no global identity-uniqueness check. There is no registry, no marketplace, no publication and no sandboxing — package code runs with the host process's authority. Detaching leaves its data behind; there is no uninstall.

  • C-14 One command tells an agent what an application actually is — packages, capabilities, resources, actions, policies, providers — read from checked-in source, in a single deterministic JSON report.

    LimitSource-only and read-only. It never opens the database, contacts a provider, reads a secret, or reports runtime, CI or authorization state — and it lists those blind spots as machine-readable limitations in its own output.

  • C-18 The MCP server exposes project context and narrow write tools to a coding agent; anything that generates code or destroys state is dry-run unless you pass an explicit apply flag.

    LimitStdio only, local only. There is no hosted or authenticated MCP endpoint, and the server inherits the local process's authority.

Limitations

  • L-01 No authentication ships: the framework authenticates nobody. Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim.
  • L-02 Not shared-database tenancy. createAccordoAppAsync can boot one tenant onto dedicated PostgreSQL databases. Shared-database row-level tenancy is not implemented, and this is not a production-readiness claim.
  • L-03 The build benchmark has not been run. The protocol is designed and published; no Successful Agent Build Rate exists yet. Any number you see quoted for this project is not ours.
  • L-07 The framework is source you run; the Cloud hosts only what a Blueprint expresses. The framework is not a hosted service: its output is an application in your repository that you run. The managed Cloud is a separate offer: a free workspace on shared capacity configured through a Project Blueprint (record types, fields and approval gates), and a paid Dedicated Cell for custom application code.
  • L-08 Ownership means vendored source: there is no framework dependency to bump. The published create-accordo@0.1.0 scaffolds vendored source; it is the August 19 snapshot, not the current repository feature set. Use a current source checkout for the capabilities described here; upgrades require merging source (L-08). The framework is copied into the project, not installed as a framework library dependency. The accordo npm name is an empty reservation; the @accordo scope is claimed and deliberately empty.
  • L-06 Bounded customer imports and logical identity; incomplete data operations. Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search.
  • L-09 Personal-data readiness requires deployment work beyond the foundation. Customer Data Foundation supplies bounded import and identity governance, not complete personal-data operations. Authentication must be supplied by the deployment, and complete subject export and erasure remain absent; the framework alone does not establish compliance or suitability for real customer data. Lead scoring remains deterministic, versioned and explainable.

Jobs it covers

Documented in

Proved by