Headless CRM for Claude and Codex, three ways

2026-09-30 · edited by Aetha Editorial

"Headless CRM for Claude" currently means three different bets, and most confusion in the threads comes from comparing one against another without naming them. Here they are, with the question that picks each.

Vendor facts below come from docs/strategy/COMPETITOR_MAP.md, researched August 4, 2026 with a re-check pass on August 20, 2026. Per-entry dates say which pass each fact comes from. We refresh comparison content on a 90-day clock.

Bet 1: a CLI the agent shells out to

One public repo literally carries the sentence "the headless CRM for Claude and Codex" (map, August 20, 2026): 114 stars, 428 commits, an a16z-speedrun backing claim in its own description — and two awkward facts recorded in the same row. It declares no licence at all (no root LICENSE file, no licence field in package.json, checked August 20), and its public repo froze in June 2026 on a commit pointing at a monorepo nobody outside can see, so its real velocity is unobservable. Its architectural stance is the interesting part: it rejects MCP on context-economics grounds and ships a CLI plus SDK instead. Pick this bet if you want "Claude runs my existing pipeline" with minimal context burn — after checking the licence situation yourself, because unlicensed source is not open source.

Bet 2: MCP tools against a fixed app

Relaticle (re-checked August 20, 2026) advertises 32 MCP tools: agents operate the CRM — read, update, create — inside a fixed Laravel app they cannot reshape. HubSpot's remote MCP server is in public beta since May 2026 (developer changelog, re-verified September 30, 2026): Cursor and Claude interacting with hosted CRM data. Salesforce announced the platform-scale version of this shape at TDX 2026 — capability reachable by API, MCP tool and CLI without a browser, aimed at coding agents by name. The announcement is recorded; every tool count attached to it comes from search-index excerpts only, so no count appears here. Pick this bet if the CRM already exists and the job is operating it. See Accordo vs Relaticle for the fixed-app caveat in full.

Bet 3: generated code you own

The third bet inverts the relationship: instead of the agent operating a fixed CRM through tools, the agent generates the CRM as reviewable code in your repository. That is this framework. A module manifest becomes migrations, services, REST resources and Admin screens (C-01); one command tells an agent what the application actually is, read from checked-in source (C-14); a project MCP server exposes context plus narrow write tools, with code generation and state destruction dry-run unless an explicit apply flag passes (C-18); the agent cannot approve on the human's behalf, asserted by a test (C-04); every mutation leaves an audit event and a step-level trace (C-16). Pick this bet if the sentence you want true is "Claude builds me the CRM and I own the repo" — and read what an agent-built CRM is plus the approval boundary in Q/A form first.

Ownership here means vendored source rather than a dependency to bump (L-08): the scaffolder copies framework source into your project. The standing boundaries apply throughout: a framework for developers, not a hosted product (L-07), and no authentication ships (L-01). Every claim and every limitation is on one page.

What this post does not mean

These pages describe this repository at this commit. None of them implies the framework is deployable, and none of them is a roadmap: nothing that is not merged appears on this site, in any tense.

  • 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.
  • 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.
  • Timers exist; a service that runs them for you does not. Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included.
  • No email, calendar or marketing integrations. An in-memory notification provider contract exists. MK1 marketing records supplied funnel observations and human-reviewed proposals only; it has no sending, publishing or spending path.
  • 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.
  • 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.

Every claim and every limitation is on one page, and the questions this project refuses to answer are published beside them.

The evidence this post rests on

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-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-16 Every mutation goes through a module service or a named workflow, and leaves an audit event and a step-level trace behind it.

    LimitAudit records what the process did under an asserted actor. It is not a tamper-evident or externally attestable log, and it is not a compliance control.

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

Grounded in

  • docs/strategy/COMPETITOR_MAP.md

Editor of record

  • Aetha Editorial