Open source · Toolchain for coding agents · CRM is the domain it proves it in
Accordo gives a coding agent a way to see, plan, build, check and prove — instead of just generating code and telling you it went well. Eight commands, each with a deterministic contract and an exit code. Five of them report their own blind spots as machine-readable limitation codes, so the agent knows what it did not establish.
app inspectwhat this project already issolution checkand whether the plan still bindspackage scaffoldconforming from the first filepackage testagainst the framework’s own contractfalsifybreak the rules and watch tests catch it701 tests · no third-party runtime dependencies · Node 22 · MIT
# the line the whole framework is organised around POST /api/modules/quote/records/:id/actions/approve actor: { type: "agent" } 403 HUMAN_APPROVAL_REQUIRED
That refusal is a merged test, not a prompt instruction: tests/commercial-e2e.test.js asserts the discount boundary, and “approval workflow rejects an agent pretending to make the human decision” asserts the renewal one. The 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.
# clone it, install nothing, and watch it compose itself npm run tour modules 70 resources 41 policies 7 packages 6 actions 56 providers 5 # then the part most tools leave out production posture — local development only: no authentication, tenancy or RBAC exists, and actor headers are not identity
It composes the starter's application, not yours, and it runs entirely locally against SQLite with no authentication. The counts describe what that starter applies; a different composition gives different numbers. Wall-clock time varies by machine and is deliberately not claimed.
npm run falsify — Five rules can be removed on purpose in one command, and the suite catches every one in about two seconds — naming the test that caught it. Anything that survives is reported as a gap, not omitted.
It falsifies six named rules, not the claims in this ledger, and it proves only that a test holds each one — a rule that is wrong but faithfully defended passes every mutation. It is not mutation testing: nothing is generated or sampled, and no score is derived.
Where to go from here
Each area below is a pillar page over its own set of pages, and every one of those pages prints what it does not do next to what it does. Links say the name of the thing they lead to; the information architecture behind them is written down in docs/marketing/SITE_ARCHITECTURE.md.
Can it do my commercial process?
Lead to Order to delivery, one domain per page — what the code does today, the tests that hold it, and the boundary each domain stops at.
What can my coding agent actually do here?
The commands and MCP tools an agent has: inspect an application's real composition, check a Solution Plan against it, run a read-only doctor, scaffold and conformance-test a package. Contracts and exit codes, not prose.
Why is it built this way?
Why every mutation goes through a service or a named workflow, why approval is deterministic policy rather than a prompt, and why a domain is a package whose one static import you can delete.
Why this and not that?
Against configuring a CRM platform, and against writing one from scratch. Sourced from docs/strategy/COMPETITOR_MAP.md with its citations, including the cases where the alternative is the right answer.
Is this specific job supported?
Every catalogued job with its status and its evidence, generated from the matrix in the repository. “Not supported” is the default status, and it is still the status most rows carry.
A direct question, directly answered.
The questions a sceptical developer asks first, answered against the ledger — and the list of questions this project refuses to answer, published rather than avoided.
Checking rather than reading: every claim and its tests · jobs.json · answers.json · llms.txt
The whole idea, in one exchange
This is the demo that ships in the repository. npm run demo runs it; scripts/smoke.js asserts the outcome on every push.
you → Renewals of €50,000 or more shouldn't reach Proposal without a manager signing off. agent→ reads AGENTS.md, ARCHITECTURE.md and the renewal workflow encodes the threshold as deterministic policy, not a prompt runs npm run verify → 701 passing then → €20,000 renewal → Proposal €80,000 renewal → Approval Pending — waiting on a named human and → a test named "approval workflow rejects an agent pretending to make the human decision" now fails if that boundary is ever removed.
The last line is the part that matters. An agent wrote the policy; an agent cannot execute the decision the policy defers to a person. That is not a convention in a style guide — it is a test in the suite.
How it works
What is actually built
These are not roadmap items. Each card is generated from a ledger that names the tests proving it, and the build fails if a claim loses its evidence — or its limitation. The full list of twenty is on the evidence page.
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.
tests/module-factory-e2e.test.jstests/admin-modules.test.jsLimitGenerated CRUD only. The factory does not generate workflows or approvals for a custom object — that is still handwritten (JTBD-06, partially supported).
Commercial policy is deterministic code, not a model's judgement: a renewal at or above the threshold stops and waits for a named human.
tests/workflow.test.jstests/api.test.jsLimitProven for the built-in renewal object and its single value threshold. A general policy engine over arbitrary custom objects does not exist.
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.
tests/workflow.test.jsLimitThe 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.
A lead is captured, scored, routed, qualified and converted into Company, Contact and Opportunity through explicit actions, each one atomic and audited.
tests/lead-intelligence-e2e.test.jstests/lead-conversion-e2e.test.jsLimitEnrichment runs against a fixture provider — no real external data source is wired. The Lead model is the starter's, not a built-in core module.
Quotes price on the server from a catalog — one-time and recurring, flat, per-unit, volume and graduated tiers — and freeze into an immutable version when a discount goes for approval.
tests/commercial-e2e.test.jsLimitCatalog sync runs against a fixture provider; no real external catalog (Stripe, Zuora, ERP) is connected. Money is integer cents with no FX — currencies are never summed.
A signature envelope produces verified events and a hashed signed artifact, and exactly one immutable Order is built from the approved quote version.
tests/signature-order-e2e.test.jsLimitA fixture signature provider with a test-only webhook key. No DocuSign, Adobe Sign or Dropbox Sign adapter exists, and the artifact hash is provider-reported rather than independently recomputed.
Pending obligations hand over into a Delivery Project with work packages, milestones and an optional partner — atomically, idempotently, and across a package boundary the kernel never learns about.
tests/delivery-handover-e2e.test.jstests/delivery-execution-e2e.test.jsLimitIt hands work over and runs it through human-driven transitions. Nothing schedules, staffs, computes percent complete or bills. Deliverables and recorded customer acceptance exist as of M14b2, and acceptance there is evidence a user actor recorded — never an authenticated customer, a legal signature or authorization to bill.
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.
tests/app-inspect.test.jsLimitSource-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.
Zero third-party runtime dependencies. Node 22 and a checkout — no build step, no bundler, no framework underneath your framework.
package.jsontests/api.test.jsLimitDevelopment dependencies and the eventual PostgreSQL adapter are separate questions. Having no runtime dependencies is a property of the framework, not of whatever you add on top of it.
Where this sits
If the vendor disappears tomorrow, what are you left with?
With a CRM platform you configure: a runtime you now have to operate, and customization expressed as metadata inside someone else's database. With this: an application in your repository, in a language your team reads, with a dependency you could delete.
| Configure a CRM platform | Build it from scratch | This framework | |
|---|---|---|---|
| What the agent produces | Extensions deployed into the platform's runtime | Whatever it invents, differently each time | A standalone application in your repository |
| Who runs the system | The platform | You | You — nothing of ours runs underneath your application |
| How you get the code (today) | You do not — you configure a running platform | You write it | You copy the source into your project. There is no create-project CLI; the two names held on npm are empty reservations that install nothing |
| Process semantics | Their workflow engine and permission model | Re-derived per project, usually late | Deterministic workflows, approval policy, audit and trace as primitives |
| Deep customization | Fork the platform and carry its release train | Unlimited, and entirely your problem | Regenerate or extend your own code |
| Honest downside | Works today, at a ceiling you meet later | Total freedom, no governance until you build it | No auth, no hosting, no scheduler — see the limits below |
Read this before the rest
This section is not a disclaimer at the bottom of a page. It is the reason to trust the section above it. Each item is tracked in the repository's own jobs-to-be-done matrix, where “not supported” is the default status and evidence is required to leave it.
The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network.
Persistence is Node's built-in SQLite adapter. PostgreSQL is on the Production Spine track and is not implemented.
The protocol is designed and published; no Successful Agent Build Rate exists yet. Any number you see quoted for this project is not ours.
One follow-up Task is created inside lead qualification. There is no recurring work, no delayed workflow, no queue — so nothing fires on a renewal notice period either.
An in-memory notification provider contract exists. No adapter sends anything to anyone.
Table stakes in every commercial CRM, and none of them has a milestone yet. This is recorded deliberately rather than left for you to discover.
There is no hosted CRM, no free tier and no account. The output is an application in your repository that you run.
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.
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.
If you are an agent reading this
No MCP server is required, no network call, no credential, no long-lived process. Two commands and a checkout cover it — the compatibility contract is written down in docs/AGENT_HARNESS_COMPATIBILITY.md.
# what does this application actually contain? npm run crm -- app inspect --json # is this plan still valid against that composition? npm run crm -- solution check my-plan.json # exit codes are the contract, not the prose 0 valid 1 problems — the full report is still printed 2 could not be read at all
A single plain-text file describing the framework, its boundaries and where each document lives.
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.
tests/mcp.test.jsLimitStdio only, local only. There is no hosted or authenticated MCP endpoint, and the server inherits the local process's authority.
A Solution Plan is a checked-in file with a contract and a canonical fingerprint, validated against a real inspection — so a plan written against a composition that has since moved reports itself stale.
tests/solution-plan.test.jsLimitA document contract, not a planner and not a runtime. Nothing executes a plan, and the validator refuses a plan that carries a command.
Straight answers
No. There is no authentication, no tenancy and no role model, and an actor header is an assertion rather than an identity. The framework says so itself: crm app inspect reports a production posture of “local development only” in its own machine-readable output. Building the production spine is the next platform track, not a footnote.
Their agents extend a running platform; this one authors an application. The distinction is not marketing — it decides who operates the system, who owns the schema, and what you hold if the project stops. The comparison, including the places where the alternative is the better answer, is maintained in the repository rather than curated here.
It composes and recommends; it never decides. Approval is deterministic policy, and there is a test asserting that an agent presenting itself as the approver is refused. If that property ever breaks, the build breaks with it.
Because the benchmark has not been run. The protocol for measuring how often an agent can build a working CRM from a brief is designed and published in the repository; until it has been executed, publishing a rate would be inventing one. When it runs, the number and the full transcripts — including the failures — get published together.
“Accordo” is the chosen name; the trademark screen has not been run. It was chosen over two shortlisted alternatives that each had a live word-mark in an adjacent class; the research and the eliminated candidates are in docs/marketing/NAME_VERIFICATION.md. The screen is a job for a person, not for this repository, so treat the name as settled and unscreened. Everything on this page is generated from a single tokens file, so if it has to change, the rename is one edit rather than a rewrite.
Today: by copying the source into your project. The one working installer copies the framework packages and the app into a new directory, applies the module manifests, and leaves you with a repository that has no runtime dependency on us. That is real ownership, and it is not the same thing as npm create plus a versioned dependency — which is what the roadmap says and what does not exist yet. The practical consequence is that upgrading means merging rather than bumping a version. We would rather you learn that here than after you have built on it.
You keep a working application, in your repository, with no third-party runtime dependencies and a database file you can open with any SQLite client. That is a deliberate design constraint rather than a reassurance: the framework is a dependency you could delete and still ship.