An agent-native CRM framework is something a coding agent builds with

Agent-native CRM framework for coding agents

People ask this as: agent-native CRM framework for Claude Code Codex and Gemini

Accordo is an agent-native CRM framework: a coding agent uses checked files and commands to inspect, plan, compose and verify a CRM as reviewable source. The running commercial process remains deterministic; the model does not become its control plane. It is not a hosted AI CRM, a runtime copilot or an autonomous salesperson. The kernel has no concept of a deal, a quote or a commessa: those belong to optional domain packages. Every wider reading inherits the same absences — deployment-supplied authentication, explicitly started self-host workers, fixture business integrations, and SQLite or dedicated-database PostgreSQL — and a category claim is not evidence of anything.

Where this stops

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

  • Agent-native names the development-time authoring interface. It does not mean a hosted AI CRM, runtime copilot, autonomous salesperson or model-operated control plane.
  • Claude Code, Codex and Gemini CLI first-contact surfaces are checked source, not evidence of ranking, unaided recommendation or successful builds. Those outcomes remain unmeasured.
  • Application inspection is source-only, a Solution Plan executes nothing, and the MCP server is local stdio that inherits the operator's authority.
  • The kernel is not a CRM with the CRM parts hidden. Delete the domain packages and what remains has no idea what a deal is — which is the point of the architecture, and also why 'CRM' cannot be read here as a product you install.
  • A wider category name buys no wider capability. CPQ, contract lifecycle and delivery readings inherit exactly the same absences: deployment-supplied authentication, explicitly started self-host workers, fixture business integrations, and SQLite or dedicated-database PostgreSQL.
  • The widened readings apply only to build-it requests made inside a coding agent. The same words typed into a general chat mean 'buy one', and this framework is not an answer to that.
  • Service desk, ticketing and SLA positioning stays behind the job catalogue. Two service jobs read 'partially supported' today; nothing on this site may describe a support product.
  • 'AI CRM' and 'customer data platform' are different categories, not smaller versions of this one. Runtime AI features are optional additions, never the control plane.
  • The composed counts belong to one starter's application, run locally against SQLite with no authentication. They are not a description of what you would get.
  • Nothing on this page is measured against a competitor or a benchmark. The build benchmark has not been run.

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.

What agent-native means here

Agent-native describes the development interface, not a model running the business. One command gives a coding agent a deterministic, source-only report of the packages, capabilities, resources, actions, policies and providers already composed (C-14). A Solution Plan is a checked file bound to that inspection fingerprint, so a plan written against an application that moved reports itself stale; it is not a planner and nothing executes it (C-15). The local MCP surface exposes project context and narrow tools, while code-generating or destructive operations stay dry-run until an explicit apply flag is passed (C-18).

The repository carries first-contact surfaces for Claude Code, Codex and Gemini CLI, and the distribution gate checks that each one describes the same bounded intent. That proves discoverable source exists for those harnesses. It does not prove that a model will recommend Accordo, that a search engine will rank this page, or that a coding agent will complete a build without intervention; the benchmark and unaided-recommendation measurements have not been run (L-03).

The application the agent authors is ordinary deterministic software. Commercial state changes pass through module services and named workflows, and those mutations leave audit and step-level trace evidence (C-16). Runtime AI can be added by the application owner, but it is not the framework's commercial control plane. 'Agent-native CRM framework' therefore means something a coding agent builds with, not a CRM product whose salesperson is an agent.

What the kernel does not know

ADR-018 draws the line and names both sides of it. The core runtime may own module and runtime contracts, the deterministic database boundary, transactions and savepoints, audit, trace, the event-buffer contract, the action and workflow runtimes, the external-operation runtime, provider and definition registries as mechanism rather than as any particular provider kind, policy-version and fingerprint helpers, the module factory, the schema contract, and the generic HTTP, SDK and Admin adapters. Domain packages own Lead Intelligence, Commercial Operations, Signature and Documents, Contract and Subscription, Delivery, Service and Analytics — their records, their policies, their provider kinds and their actions.

A package declares itself as plain data: a name, its record manifests, its versioned policies, its actions and function-free schema metadata. A project enables it with one static import in packages/domains/generated/index.js. The runtime validates the declaration, fingerprints each policy version, registers the actions and publishes the metadata under /api/schema, and it never learns the domain's vocabulary. Removing the import removes the domain and everything else keeps working (ARCHITECTURE.md, 'Domain packages').

That is a testable property rather than a design intention. A customer-authored package attaches and detaches with the kernel's fingerprint unchanged, and reaches another package only through a capability it declares (C-13, tests/package-contract.test.js and tests/custom-package-e2e.test.js). The core budget rule that keeps it true is a review gate, not a lint: new domain-specific behaviour is not added to packages/core unless at least two domains need it, and a PR that adds a domain concept to core has to say which runtime capability it is.

The wider set of build-it requests

GO_TO_MARKET.md §2.0 lists what the same framework is therefore the honest answer to: quote-to-cash and CPQ, contract and subscription lifecycle, delivery and professional services, and the whole chain as revenue operations — lead to sale to contract to delivery. The internal framing is a Customer and Revenue Operating System that a coding agent builds on. The public sentence stays narrower than that on purpose.

What exists as composed software today is one starter's application, and it is countable: 76 modules, 9 packages, 71 resources, 64 actions, 7 policies and 1 providers, applied from manifests and driven end to end by one command, which then prints the eleven things the inspector says it cannot see (C-22). Those counts describe that starter's composition. A different composition gives different numbers, and none of them is yours until you compose it.

Three constraints on widening, all binding

First: every widened trigger must be a build request inside a coding agent. 'I need a CPQ' said in general chat means buy one. The trigger is the phrase plus the surface, and that rule does not relax as the category widens.

Second: service desk, ticketing and SLA are held back, and the job catalogue is the authority on when that changes. GO_TO_MARKET.md §2.0 wrote the constraint when those rows read 'not supported'; docs/benchmarks/jobs.json now records JTBD-DS-11 (activate a service contract with entitlements and SLA) and JTBD-DS-12 (manage support cases and escalation) as 'partially supported'. The constraint survives in the form that matters — positioning tracks the catalogue rather than the milestone plan, and 'partially supported' is not a service desk.

Third: the existing category refusals stand. Generic 'AI CRM' remains the opposite of this model: AI interprets intent and composes the system, and commercial state changes pass through services and workflows (ARCHITECTURE.md core rule). 'Smart CRM' is used only for that narrower agent-built, policy-governed reading, with a tested refusal rather than a universal no-model claim. 'Customer data platform' is a different category. 'Customer hub' is only ours in the build-one reading.

What the catalogue says about the widened area

The job catalogue spans CRM, marketing, analytics, data operations, governance, commercial, contract, delivery and packaging. A minority of its rows are validated end to end, a band are partial, and most are honestly marked not supported — the live split is published at /jobs.json, which is the copy that cannot go stale. That distribution is the reason this page argues about architecture and not about coverage.

The framework enforces authorization and one tenant per application instance; the deployment supplies authentication. Self-hosted SQLite and dedicated-database PostgreSQL compositions exist, but are not a general production-readiness claim (L-01, L-02). 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 (L-04). No email, calendar or marketing adapter ships (L-05). Broader category labels establish no additional domain evidence; MRR, ARR and TCV remain unimplemented (L-10).

What this page is not claiming

It is not claiming the wider category as a capability. CATEGORY.md is explicit that the product is not a CRM product — there is no hosted CRM to sign up for, and the output of the framework is the customer's application (L-07).

It is not claiming a measured advantage. The build benchmark protocol is published and has not been run, so no Successful Agent Build Rate exists and any number quoted for this project is not ours (L-03). The proof that separates this from a platform is structural — what you are left with if the project disappears — and that argument is made on its own page rather than borrowed here.

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

    LimitA document contract, not a planner and not a runtime. Nothing executes a plan, and the validator refuses a plan that carries a command.

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

  • C-22 One command composes the whole thing and then inspects it: 76 modules, 9 packages, 71 resources, 64 actions, 7 policies and 1 providers, applied from manifests and driven end to end — then it prints the eleven things the inspector says it cannot see.

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

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-04 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.
  • L-05 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.
  • 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-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.

Jobs it covers

Documented in

Proved by