Comp AI's agentic CRM, or an approval boundary the agent cannot cross?
Comp AI CRM, the agentic-first CRM
People ask this as: comp ai crm alternative when the agent must not decide commercial questions alone
Comp AI's CRM is the loudest version of a thesis this project deliberately inverts: an autonomous background agent doing CRM work inside the product, with a work queue, evidence-based facts and a sandbox. Here the agent builds the application instead, and the decision that matters commercially is the one it is refused — a test asserts that an agent cannot approve. The research file credits Comp AI with proving demand for the narrative and with a genuinely novel design, and records in the same row why it reads as a thesis demo rather than infrastructure. Every fact traces to that dated file; nothing was 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 Comp AI 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; the star and commit figures are that date's snapshot.
- Licence descriptions are factual summaries of published texts, not legal advice.
- No background agent, no work queue and no scheduler exist in this framework — nothing here runs unattended (L-04).
- No authentication, tenancy or RBAC; an actor header is an assertion, not an identity (L-01).
- SQLite only. PostgreSQL is on a track, not in the code (L-02).
- This is a framework, not a product you sign up for: no hosted CRM, no free tier, no account (L-07).
- Nothing installs from npm: ownership is copying source, and upgrading is merging (L-08).
- No measured comparison in either direction — the benchmark has not been run (L-03).
No authentication, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network. Every claim and every limitation is on one page.
Where Comp AI's CRM wins
It proved the demand is real. The research file this page reads — docs/strategy/COMPETITOR_MAP.md, dated August 4, 2026 — records 4.4k GitHub stars gathered in weeks for an agentic-first CRM: an autonomous background agent with a work queue, evidence-based facts and a sandboxed design the file calls genuinely novel, under an MIT licence, TypeScript end-to-end on Next.js, NestJS and Prisma. If what you want is a CRM in which the agent is a worker inside the product, that is its entire thesis — and nothing in this framework attempts it. There is no background agent here, no work queue, and no scheduler for either: nothing in this framework runs unattended at all (L-04).
It is also far simpler to stand up. The file records deployment as three Vercel deployments. This project is not a product at all — no hosted CRM, no free tier, no account (L-07) — with no authentication, tenancy or RBAC (L-01), persistence in local SQLite (L-02), and a bootstrap that runs from a checkout of the repository rather than from a registry, so ownership means copying source and upgrading means merging (L-08).
Where this is different
The direction of the agent. The file's sentence is exact: the agent is in the product, not building it. Here it is the reverse. The application is generated as code in your repository — a module manifest becomes a migration, a service, a REST resource, an SDK method and Admin screens (C-01) — and the runtime surface an agent gets is refusal-shaped rather than autonomous. Commercial policy is deterministic code, and a renewal at or above the threshold stops and waits for a named human (C-03). An agent actor asking to approve a discounted quote is refused with a 403 and code HUMAN_APPROVAL_REQUIRED, and only a human user actor can decide (C-21). The refusal is asserted by a test, so the boundary is a property of the system rather than a promise in a README (C-04), and every mutation leaves an audit event and a step-level trace behind it (C-16). Autonomy is not the pitch here; the approval boundary is.
Ownership shape. The file records Comp AI's customization as none meaningful — fixed schema, single-tenant, Vercel-coupled — with no MCP and 18 internal agent tools. Here the schema is whatever your manifests declare, generated into source you own and evolve through explicit revisions (C-01), and the lock-in the file records for this framework is none by design — a framework as dependency, though today that means copying source rather than installing one (L-08).
The measurement caveat cuts both ways and belongs on this page. The file records 81 commits behind those 4.4k stars and calls the project a manifesto, not a platform — but the same file warns that stars in this category are marketing-inflected, citing Krayin at 23.6k stars with modest activity, and says to measure forks, usage and benchmarks instead. Held to its own standard, this project's benchmark has not been run, so no measured comparison exists in either direction and none appears here (L-03).
How to choose
Choose Comp AI's CRM if you want an autonomous CRM worker inside a product today; if MIT licensing, a TypeScript-end-to-end stack and Vercel deployment fit; and if the fixed schema and single-tenant shape the file records are acceptable for what you are running.
Choose this framework in the narrow case: the deliverable is a bespoke commercial process as reviewable code in your repository, where the agent does the writing and a human owns every approval — and you can supply authentication, hosting, PostgreSQL and data governance yourself, because none of them is here (L-01, L-02).
If the question is which agent should touch revenue decisions, the two answers differ in kind rather than degree: theirs works the queue, and this one is stopped at the approval and told to wait for a person. Choose by which failure you would rather explain afterwards.
What this comparison does not cover
No hands-on evaluation. Nothing from Comp AI 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 review of the evidence model or the sandbox. The file records the design as genuinely novel and does not describe how it works, so this page cannot and does not.
No feature matrix and no pricing. The file carries neither for Comp AI, so no statement about its CRM features, data model or cost appears here.
The commit and star figures are a snapshot from one date, in a category where the file itself says stars are marketing-inflected. Check the current repository before drawing conclusions from either number.
No build-rate or speed comparison in either direction — the benchmark has not been run (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-03 Commercial policy is deterministic code, not a model's judgement: a renewal at or above the threshold stops and waits for a named human.
LimitProven for the built-in renewal object and its single value threshold. A general policy engine over arbitrary custom objects does not exist.
- 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.
LimitThe actor is asserted, not authenticated: there is no auth, tenancy or RBAC, and an actor header is not identity. This holds a boundary against an honest agent, not against an attacker with network access.
- 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-21 The same refusal holds where the money is: an agent actor asking to approve a discounted quote is refused with a 403, and only a human user actor can decide.
LimitThe assertion lives inside a composite end-to-end test rather than a test named for it, so the citation is a file and a line rather than a test name. Extracting it into a named test is tracked in docs/strategy/GO_TO_MARKET.md; until then, cite the line.
Limitations
- L-01 No authentication, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network.
- L-02 SQLite only. Persistence is Node's built-in SQLite adapter. PostgreSQL is on the Production Spine track and is not implemented.
- 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-04 No scheduler, no reminders, nothing on a timer. Follow-up Tasks and an Activity timeline are one shared model that a person moves by hand: a due date changes no state. There is no recurring work, no delayed workflow, no queue — so nothing fires on a renewal notice period either.
- L-07 This is a framework, not a product you sign up for. There is no hosted CRM, no free tier and no account. The output is an application in your repository that you run.
- L-08 Ownership today means copying source, not installing a dependency. There is a project bootstrap and there is no published package, and the two are different facts. The repository's bootstrap command scaffolds a project that boots, reports `valid` from `app inspect` and exits 0 from `project doctor`, offline and with no install — run from a checkout of this repository. The package published under the reserved npm name is still an empty 0.0.1 placeholder, so the `npm create` route installs nothing until a human publishes it. Either way the framework is vendored into the project rather than depended on by version: you own the result outright, and upgrading means merging, not bumping.
Jobs it covers
- JTBD-02 Request commercial approval on a deal — validated end to end
- JTBD-CO-03 Request a discount under a deterministic policy — validated end to end
- JTBD-15 Enforce team / tenant permissions — not supported