A smart CRM knows when the agent must stop
Agent-built, policy-governed CRM
People ask this as: smart crm framework with ai agents and human approval
Accordo is smart before the commercial decision: a coding agent can compose the CRM, while versioned policies calculate scores, gate discounts and preserve the evidence. The proof is a tested refusal — an agent actor cannot approve a discounted quote. This is not a hosted AI CRM, a runtime assistant or a claim that no model can run anywhere; the boundary is specific, local and only as strong as an asserted actor header.
Where this stops
Read this before the rest of the page. Every line below is a thing this does not do.
- Smart CRM here names an agent-built application with deterministic policy boundaries. It is not a hosted AI CRM, runtime assistant or autonomous salesperson.
- The proof is specific: a discounted-quote approval returns 403 to an asserted agent actor, and a renewal approval has its own refusal test. It does not prove a human gate on every action.
- The actor is asserted in a header, not authenticated. With no authentication, tenancy or RBAC, this is a behavior boundary for an honest agent and not a security boundary against an attacker.
- Lead scoring is a deterministic weighted rule set, not machine learning. Versioning and contributions make it explainable; they do not make the policy correct, unbiased or predictive.
- No ledger claim proves that a model never runs anywhere at runtime. This page makes no such universal statement and the broader question remains refused.
- The framework is local-development-only and SQLite-only. There is no hosted product, email or calendar integration, and no safe path for real customer data.
- The build benchmark has not been run, so this page makes no measured claim that an agent builds a better CRM.
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.
request POST /api/modules/quote/records/:id/actions/approve actor { type: "agent" } 403 HUMAN_APPROVAL_REQUIRED
The intelligence belongs before the final state change
Smart CRM means one narrow thing here: a coding agent may interpret the builder's goal and compose the application, but commercial state changes pass through explicit module services and named workflows. The framework does not ask a model whether a high-value renewal should proceed. The published policy is deterministic code: at or above its threshold, the move stops and waits for a named human (C-03). A test then sends an agent actor to the decision workflow and asserts the refusal (C-04).
The same split holds where a score is useful. Lead scoring is a deterministic weighted rule set, not machine learning: every score stores the model name, version, fingerprint, stable input references and one contribution per rule, so a number from last quarter can still be accounted for (C-07). The framework does not assert that the rules are good, unbiased or predictive. It makes the rule and its contribution inspectable; the person building the CRM still owns the policy.
The human boundary is executable, not conversational
An agent may create the catalog, quote and lines, submit the quote and read the resulting evidence. When that same agent actor asks to approve a discounted quote, quote.approve returns status 403 with code HUMAN_APPROVAL_REQUIRED; only actor.type user may decide (C-21). This page prints the receipt because a prompt that says 'ask a human' is guidance, while a server refusal is behavior.
The receipt is deliberately smaller than the category claim. It proves one discounted-quote approval boundary inside tests/commercial-e2e.test.js; that assertion is part of a composite end-to-end test rather than a test named only for the refusal. The renewal workflow has its own named refusal test. Neither one proves that every action in every application requires a human, and neither one says whether the human made the right decision.
Audit makes the decision answerable later
A refusal is only the stop. The surrounding evidence is the useful part: every mutation goes through a module service or a named workflow and leaves an audit event and a step-level trace (C-16). Quote versions are immutable, and the discount decision stores the policy name, version and fingerprint that produced it. Lead scores retain their model fingerprint and rule contributions. The result can be inspected after the coding agent session that assembled the system is gone.
That is why this is policy-governed rather than model-governed CRM. The coding agent is allowed to author and change source under review; the running commercial process executes the checked-in rule and records what happened. Accordo provides the mechanism and the tested examples. It does not provide a correctness oracle for a policy, an approval of the policy itself or a benchmark showing that an agent builds a better CRM. The build benchmark has not been run (L-03).
What Smart CRM does not mean on this site
It does not mean a hosted assistant, an autonomous salesperson or a CRM product a team can sign in to. There is no hosted CRM, free tier or account; the output is source in a repository that its owner runs (L-07). There is no email, calendar or marketing adapter that lets an agent contact a customer, and the in-memory notification provider sends nothing to anyone (L-05).
It also does not mean this repository has proved that no model can run anywhere at runtime. That universal statement has no ledger claim and remains a refused answer. The claim here is narrower and testable: the named commercial policies are deterministic, the named agent decisions are refused, and the named writes carry audit and trace.
Most importantly, the actor is asserted rather than authenticated. There is no authentication, tenancy or RBAC, and an actor header is a claim the caller makes about itself (L-01). The refusal holds against an honest coding agent that identifies itself; it is not a security boundary against a caller that lies. Persistence is local SQLite (L-02), and real customer data does not belong here because there is no export or erasure path (L-09).
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-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-07 Scoring is explainable and versioned: every score carries the fingerprint of the model version that produced it, so a number from last quarter can still be accounted for.
LimitDeterministic weighted rules, not a machine-learning model. Nothing trains, fits or backtests.
- 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-05 No email, calendar or marketing integrations. An in-memory notification provider contract exists. No adapter sends anything to anyone.
- 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-09 You cannot put real customer data in this yet. A CRM is a personal-data system by definition, and this one has no authentication, no tenancy, no export and no erasure path — so there is no way to service a data-subject access or deletion request with it. Data governance is designed and unimplemented. The one thing that does hold today: lead scoring is deterministic, versioned and explainable, not a model's judgement about a person.
Jobs it covers
- JTBD-02 Request commercial approval on a deal — validated end to end
- JTBD-LI-02 Calculate an explainable lead score — 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