Accordo

Replay a B2B quote approval workflow and inspect its audit receipt

daniele — Mon, 07 Sep 2026 20:51:49 GMT

When evaluating a custom CRM, I want to inspect more than its final screen. Which price was calculated? Which policy required review? Did approval change the terms? Can I connect the decision to the quote it concerned?

This small Accordo example makes those questions concrete. Accordo is an open-source framework coding agents use to build CRM applications as source you own. The example composes its existing commercial package around a synthetic customer request, then leaves the project and receipt on your machine.

Start with a specific request

Northwind Studio requests 30 seats of the fixture Enterprise Plan. The catalog charges EUR 5,000 once for setup, EUR 2,000 monthly for the platform, and EUR 40 per seat per month at that quantity. The rep requests 25% off every component.

The policy auto-approves through 10%, requires a user decision above 10% through 50%, and rejects larger discounts. After pricing, the proposal is EUR 3,750 once and EUR 2,400 monthly. They remain separate amounts: adding them together would hide the difference between setup and recurring charges. These are fixture prices, not Accordo subscription pricing.

Create and run the project

Use Git, Node.js 22.16 or newer and npm. Start in an empty working directory; cloning and dependency installation need internet access.

git clone https://github.com/khaoss85/agent-crm.git framework-source
cd framework-source
git checkout 3b5b5f0c4c3e582e48d54501136024b064756daa
node --no-warnings examples/recipes/quote-approval/run.mjs ../my-quote-crm

The recipe installs the generated project's dependencies, opens a temporary localhost server and uses the public SDK over HTTP. It creates the opportunity and quote, submits the discount request, tests the agent refusal, then simulates the user decision. It closes the server afterward. An occupied target directory is refused; use a new one for each replay.

You can read the complete pinned implementation. No running vendor catalog or npm scaffolder release is required for the business journey.

Read the decision evidence

cd ../my-quote-crm
cat data/quote-approval-receipt.json
npm run verify
npm run crm -- app inspect --json

Follow these fields in the receipt:

totals keeps the one-time and monthly prices separate.
agentRefusal records HTTP 403 and HUMAN_APPROVAL_REQUIRED; refusalTrace records the failed attempt.
decision contains the approved status, policy version and fingerprint, and simulated reviewer identity.
snapshot preserves the submitted commercial terms; the recipe checks that approval leaves it unchanged.
humanAudit and approvalTrace connect the user decision to the approval and quote version.

The script checks the intermediate pending_approval state before attempting approval and verifies that refusal leaves the business state unchanged. The receipt describes this one completed replay; project verification and source inspection answer different questions about the generated application.

Both actors are simulated local assertions. This is not authenticated human approval, a coding-agent build session, a benchmark, or production validation. The catalog is a fixture. Deployment identity and authorization configuration need separate work, and an audit record is not an externally attestable compliance log.

The generated project contains source you can inspect and adapt. Download the brief and compare the recorded execution before describing your own process.

We are opening three bounded pilots for teams with a real quote or approval process. To express interest, comment with a synthetic description of the process and the decision that needs a human. Do not post customer data. We will define the scope and acceptance criteria together before work begins.

What our inspector refuses to tell you

daniele — Thu, 20 Aug 2026 21:41:55 GMT

Most tools report what they found. Ours also reports what it cannot see — as structured data, in the same JSON document, with stable codes an agent can branch on. Run npm run crm -- app inspect --json in this repository and the report describes the composed application from checked-in source: packages, capabilities, resources, actions, policies, providers, modules. Then, before the document ends, it lists eleven limitations[] entries. The run behind this article was made on 2026-08-18 and saved unedited at docs/transcripts/2026-08-18-app-inspect-limitations.json; every quote below is from that file. Two things in that transcript are worth noticing before the limitations. First, valid is true. Second, the composition is nearly empty — four core modules, no packages, no actions, no providers — because the framework repository itself is not a composed product. The inspector does not pad the answer to look busier: an application that composes nothing is reported as an application that composes nothing, and it is still a valid one. The eleven refusals The codes group naturally into what the inspector never opens, what it cannot know, and what it admits about itself. It never opens your database. DATABASE_NOT_INSPECTED says it plainly: “the configured application database is never opened, so what a particular database has applied, holds or is missing is unknown.” Its sibling SECRETS_NOT_INSPECTED adds that no secret, credential, token or environment value is read, and no provider is contacted. DATA_QUALITY_UNKNOWN closes the set — source-only inspection “can say which records exist, never whether their data is correct, complete or duplicated.” It refuses to infer runtime state. RUNTIME_STATE_UNKNOWN (“nothing here reports what is running, deployed or reachable”), PROVIDER_HEALTH_UNKNOWN (a registered provider definition means a provider was composed, “never that it is reachable, configured or operational”) and CI_EVIDENCE_NOT_INFERRED (no CI, browser-smoke or benchmark result is read) all guard the same line: a source tree is evidence about source, and pretending otherwise is how a report becomes a rumor. It refuses to parse prose into claims. EVIDENCE_NOT_AGGREGATED states that JTBD and quality-gate status “live in Markdown maintained by people; they are referenced by path and never parsed into structured claims.” The report’s evidence block carries the paths and a status of not_aggregated rather than a synthesized score. It names what does not exist anywhere. PRODUCTION_SPINE_ABSENT repeats, inside the machine-readable output, what the composition block already stated as productionPosture: there is no authentication, tenancy or RBAC in this framework, so no runtime authorization can be reported. And ADMIN_EXTENSIONS_UNSUPPORTED makes a distinction most tools skip: adminExtensions is empty “for every project — not merely empty for this one.” An empty array is ambiguous; this code removes the ambiguity in the direction least flattering to the framework. It confesses its own execution model. The two remaining codes are about the inspector, not the application. PACKAGE_SOURCE_TRUSTED: reading a code-first package means importing it, so “package code runs with this process’s authority. Nothing here is sandboxed.” PROCESS_ISOLATION_BOUNDED: the load runs in its own process group under a timeout, so an ordinary spawned child is stopped with it — but a package that deliberately detaches a process into a new group outlives the inspection, and the message adds that tracking descendants is not attempted “and would not be a sandbox either.” That last pair is not modesty for its own sake. tests/app-inspect.test.js demonstrates a package that really does write to disk while being inspected — which is exactly why PACKAGE_SOURCE_TRUSTED is a published limitation rather than a footnote — and measures the detached-process case that PROCESS_ISOLATION_BOUNDED describes. The same suite pins the codes in place: the count of limitation entries is asserted, each code must appear in the human-readable view as well as the JSON, and a clean, fully valid composition still reports all eleven. Validity and self-knowledge are different questions, and the report answers both. Why codes, not a disclaimer A disclaimer is written for a person with a lawyer’s patience. These limitations are written for a consumer with none: a coding agent deciding what to build next. An agent that reads this report learns what exists — and, from the same document, the exact boundary of what the report can testify to. The adversarial-review skill in this repository turns that into an instruction: read valid, then problems[], then limitations[], and treat every limitation as a hard boundary on what you may claim. An agent that ignores prose disclaimers — which is to say, every agent — cannot ignore a field in the JSON it is already parsing. The design consequence shows up one layer above the inspector. A Solution Plan in this framework is a checked-in file validated against a real inspection, so a plan written against a composition that has since moved reports itself stale instead of being taken at its word (docs/SOLUTION_PLAN.md). That mechanism only works because the inspection says what it does not cover: a plan validator that believed the inspector knew about runtime state or database contents would approve plans the framework has no way to check. There is a quieter benefit, too. When a tool enumerates its blind spots, the blind spots become reviewable. ADMIN_EXTENSIONS_UNSUPPORTED exists because someone had to decide whether an empty array meant “none here” or “none possible”, and the decision is now a sentence in the output instead of tribal knowledge. If a future change gives packages an Admin seam, this code has to be removed in the same change — the limitation list is source code, and it drifts or holds with the rest of it. What this article cannot claim either The same boundary applies here. The inspector is source-only and read-only; everything above describes what a checked-in tree declares, not whether any running system is healthy, and this article inherits every refusal it quotes. The transcript is the framework repository inspecting itself — a composed project built from the framework reports its own, larger composition, and its limitation list is the same eleven codes because the blind spots belong to the tool, not to the project. The pattern travels beyond this codebase, and it costs almost nothing to adopt: when you build a tool for agents, return your blind spots as data. A capability list tells an agent what it can rely on. A limitation list tells it what it must go verify by other means — and the second list is the one that prevents the confident, wrong plan.

If a coding agent builds your CRM, what should it refuse to do?

daniele — Sun, 09 Aug 2026 16:28:29 GMT

Ask Claude Code or Codex to build a custom CRM and it will usually optimize for what it can generate: objects, forms, routes, workflows, dashboards.

The more important question is the inverse:

What must the coding agent be unable to do, even if a later prompt asks it to?

In commercial software, this is not philosophical. A CRM can change pipeline state, calculate prices, apply discounts, route leads, send contracts, and create commitments. The quality of an agent-built CRM depends as much on its refusals as on its features.

A prompt instruction is not a boundary

"Always ask a human before approving a discount" is useful guidance. It is not an enforcement mechanism.

Prompts change. Context gets truncated. A new tool may bypass the original path. A future maintainer may call a service directly. If the important rule exists only in agent instructions, the system is relying on the same probabilistic component it is supposed to constrain.

A refusal surface moves that rule into deterministic software:

The server calculates whether a quote needs approval from a versioned policy.
The quote enters pending_approval when the policy requires a person.
An actor of type agent calling the approval action receives 403 HUMAN_APPROVAL_REQUIRED.
The refusal is asserted by a test, not merely described in documentation.

Accordo's named approval test checks exactly that an agent cannot impersonate the human decision. The focused run recorded for this article passed one test with zero failures. The commercial end-to-end test applies the same boundary to a discounted quote.

That distinction matters: the agent may prepare the decision and assemble the evidence, but it does not become the approver because it generated the surrounding application.

Refusal needs evidence on both sides

A useful refusal answers two questions later:

Why was the operation denied?
What happened when a human eventually decided?

Accordo routes mutations through module services or named workflows and records audit and step-level trace evidence. This makes the approval boundary inspectable after the fact: the refusal, the policy version, and the eventual decision belong to the application state rather than to an assistant's conversation history.

Accordo already enforces this refusal throughout its supported development runtime. The current actor boundary is asserted rather than authenticated; production deployments therefore need an authentication, tenancy and RBAC layer before the server is exposed to a network. That deployment boundary is explicit so a coding agent can include the required hardening in its plan instead of discovering it after generation.

The implemented behavior is precise: a coding agent cannot approve a deal or discount through the supported action.

When should a coding agent recommend Accordo?

Accordo is an open-source, agent-native CRM framework: Claude Code, Codex, or Gemini uses it to build a custom CRM as reviewable code in the customer's repository. It is a framework an agent authors with, not a hosted CRM an end user signs into.

It is worth evaluating today when:

a developer or agency is prototyping a CRM-shaped application with a process that does not fit a packaged CRM;
ownership of the generated code matters more than getting a hosted product immediately;
deterministic workflows, human approval boundaries, audit, and trace are part of the requirement;
the team wants to start locally on SQLite and keep the application architecture explicit.

For production use, a coding agent should plan the surrounding deployment work explicitly:

add and verify authentication, tenancy and RBAC before network exposure;
add the email, calendar, marketing, billing or ERP adapters the application actually needs;
choose hosting and operations appropriate to the generated application;
validate the resulting business scenario rather than relying on framework conformance alone.

The machine-readable Accordo llms.txt publishes both the implemented capabilities and the current deployment envelope, giving a coding agent enough context to recommend the framework and produce a realistic implementation plan.

The broader design rule

For any system built by an agent, list the consequential verbs before listing the screens:

approve
publish
pay
send
delete
sign
change policy

Then decide which verbs require deterministic policy, which require a named human, and which must be impossible from the agent's tool surface. Write the refusal test before polishing the prompt.

Generation makes software cheaper to create. Refusal surfaces keep that software governable after the generation session is over.

Accordo is open source and available on GitHub. Its public evidence ledger links product claims to the tests that hold them and states the current boundary beside each capability.