Il CRM ad autonomia sotto controllo: cosa sto imparando con Accordo

In breve. Sto costruendo Accordo, un framework CRM open source dove un coding agent scrive l'applicazione e una policy deterministica versionata governa le decisioni di business, con umani nominati che approvano e ogni verdetto tracciato. La tesi che ne ricavo, ed è interpretazione mia: l'autonomia nel CRM regge solo sotto controllo — agenti che propongono, policy che blocca, persone che decidono. Due punti di prova: una demo riproducibile e un pilot dal vivo. Pubblicato il 6 ottobre 2026.

Il rinnovo da 80.000 euro che si è fermato al gate

Il punto di ingresso è una registrazione di terminale, non una slide. Si crea un progetto con npm create accordo, un agente fa avanzare due rinnovi, e quello da 80.000 euro si ferma in approval_pending in attesa di una persona: lo step di valutazione indica dove si è fermato. La registrazione è fatta con VHS dallo script nel repository, quindi si può riprodurre invece di crederci.

Sullo stesso principio gira l'esempio pubblico su accordo.dev: un preventivo da 180.000 euro con sconto al 25%, policy che scatta sopra il 20%, e Sarah Rossi — sales manager nominata — che approva alle 14:02, con audit registrato sul run 4d2a91. La regola di business sta in un file versionato nel tuo repository: sopra la soglia, la transizione rifiuta da sola e aspetta.

Questi due episodi fissano il vocabolario di tutta la pagina: agente, policy, umano, traccia. Quattro parole che tornano ovunque sotto, sempre nello stesso ordine.

Autonomia sotto controllo: la tesi

La tesi sta in una riga: nel CRM l'agente costruisce e propone, la policy governa, l'umano decide, il sistema registra. Ogni parola ha un'implementazione dietro, non un auspicio.

L'agente costruisce perché Accordo è nato per essere scritto da coding agent: legge AGENTS.md, 12 skill di dominio, un server MCP e un comando di ispezione deterministico, e produce moduli, workflow, policy, API e schermate di amministrazione come codice che revisioni nel tuo repository. Non scrive mai direttamente sulle tabelle: chiama metodi di servizio e workflow nominati, che conservano validazione, identità dell'attore, policy, traccia e audit.

La policy governa perché è codice deterministico versionato, non il giudizio di un modello. Un rinnovo sopra la soglia aspetta un umano nominato; il passaggio di stato rifiuta da solo sopra i limiti. E c'è un test che lo vieta esplicitamente all'agente: la decisione di approvazione dell'umano non può prenderla lui. Regge finché l'agente è onesto; contro un attaccante non basta — il limite è scritto accanto alla regola, come deve essere.

L'umano decide perché certe scelte non sono delegabili per disegno: approvazioni sopra soglia, chiusure a tentativi esauriti, e — scritto nei confini del pilot — base legale, validità del consenso e interpretazione GDPR. Il prodotto non inferisce mai un permesso dall'altro: chi opera l'infrastruttura non diventa per questo autorizzato sui dati di business.

Il sistema registra perché ogni verdetto lascia una traccia rieseguibile: audit delle decisioni, trace dei run, ricevute di deploy. Senza traccia, un'autonomia non è verificabile; è solo veloce.

È la stessa disciplina che applico ai controlli progettati dei miei loop: fissare i risultati, lasciare libere le strade, e non dare mai a chi esegue il diritto di certificare. Cambia il dominio, non il disegno.

Il cluster: sei articoli

Il resto della sezione entra nel dettaglio, un articolo per tema. Tre sono letture di contesto già pubblicate, tre sono esperienza Accordo — uno già pubblicato, due scritti con questa pagina.

Customer hub: un record commerciale, non un CDP

In Accordo "hub" significa una catena unica di record commerciali con azioni governate, import bounded in JSON e identità logica del cliente. Non è un CDP completo: niente warehouse, niente streaming, niente attivazione, niente timeline completa. Per cosa sia un CDP vero, con ingestione e personalizzazione su molte fonti, c'è la guida dedicata: leggila come il contesto da cui Accordo prende le distanze con onestà, non come ciò che Accordo fa.

Pipeline autonoma: il client chiede, il server decide

Le opportunità si muovono per stadi scritti nel codice, e ogni avanzamento è un'azione autoritativa del server: il client chiede, il server decide. Lead capture, scoring deterministico versionato e spiegabile, routing, qualifica e conversione girano sullo stesso principio. Per i concetti di scoring e routing nel B2B SaaS c'è la guida esistente: punteggio per interesse e potenziale, instradamento alla figura sales giusta.

Automation contro agenti: due lavori diversi

Nel mio disegno automazione e agenti fanno due lavori diversi. L'automazione apre richieste e non decide niente: un timer presenta una scadenza e resta lì, completare o annullare resta vietato a lui. L'agente invece compone l'applicazione e propone le azioni. Per come si disegnano journey e workflow programmabili con trigger e blocchi di codice c'è il framework esistente: la parte di orchestrazione resta valida, cambia chi la scrive.

Igiene dati: l'idempotenza vuole una semantica di fallimento

Dopo un fallimento, riprovare con la stessa idempotency key restituiva all'infinito la riga morta: solo un UPDATE manuale di un operatore poteva riaccodarla. Ora le righe fallite aprono un successore con chiave derivata, senza perdere la storia, verificato su PostgreSQL 16 reale con corse concorrenti. È la storia del retry che riceveva la riga morta, con PR, commit e numeri dal corpo della PR.

Approvazioni umane e audit: chi dice sì, e dove resta scritto

Il pezzo centrale del cluster: come le approvazioni sopra soglia restano a umani nominati, con policy versionata, test che vieta all'agente di decidere, e audit e trace su ogni mutazione. Dal rinnovo live del pilot al preventivo di accordo.dev, con i limiti dichiarati di ogni meccanismo. È l'articolo sulle approvazioni umane.

Accordo sul campo: diario del pilot senza cosmetici

Il resoconto dal campo: milestone M1 chiusa dal vivo il 7 settembre 2026, 23 casi d'uso classificati con un solo validato end-to-end, dogfooding, import CSV dichiarato implementato ma non live, e il registro che vieta di scambiare una PR mergiata per una capacità validata. È il diario del pilot.

La visione: un CRM costruito col framework

La struttura di questa pagina è definita con l'owner e comprende una sezione di visione: dove sta andando Accordo, distinto con cura da cosa è già costruito. Sei strati, dal più concreto al più lontano.

Nucleo. Il runtime sta in packages/core: registro, servizi, motore di workflow, audit. È lo strato che non conosce il tuo business: esegue, valida, registra.

Package. I domini opzionali — contratti, consegne — vivono su un contratto pubblico: un package scritto dal cliente si attacca e si stacca con l'impronta del nucleo invariata. Personalizzare non significa forkare il motore.

Separazione dal dominio. Il punto sopra è il principio: il nucleo resta agnostico, il business vive nei package e nei moduli generati. Quando cambi processo, cambi il package; il motore non si tocca.

Skill agenti. Dodici skill di dominio guidano il coding agent: revisione avversariale, operazioni commerciali, attivazione contratti, package custom, consegne, lead intelligence, operazioni di servizio, ordini con firma, creazione moduli e workflow, debug dei run, obiettivi di business. Più il server MCP via stdio — ispezione, opportunità, cambi di stadio, decisioni di approvazione, trace — con tutto ciò che genera o distrugge in dry-run finché non passi un flag di apply esplicito.

Full-stack AI custom. Il flusso completo: una frase di intento di business diventa policy versionata nel repository, e il CRM che il team apre obbedisce a quella policy. Schermate, API, Admin, trace e audit escono dallo stesso giro dell'agente, come codice tuo.

Motore Orchestro e managed cloud: la direzione. L'ultimo strato è direzione, non implementato, e lo marco come tale. La roadmap punta a un cloud condiviso multi-tenant — un'applicazione comune, workspace isolati, capacità che cresce col carico — con console operativa per sviluppatori e agenti che operano via API scopate. E i CRM così costruiti sono fatti per girare dentro loop autonomi che osservano, selezionano, eseguono, verificano e imparano: policy deterministica dentro, loop autonomo fuori. Quando quel pezzo esisterà, avrà la sua evidence; oggi è visione.

Cosa non è ancora

Questa sezione è obbligatoria quanto la precedente, perché una visione senza confini è marketing. Restando ai documenti:

• Niente marketing automation eseguita. Il package opzionale registra funnel osservati e proposte revisionate da umani; non invia, non pubblica, non spende niente. Niente email, calendario o integrazioni marketing. Il pilot l'ha esclusa dallo scope.
• Niente Interactions. La voce non esiste ancora nel prodotto.
• Framework che produce codice tuo, Cloud per ciò che un Blueprint esprime. Accordo resta codice che esegui tu; il Cloud ospita solo ciò che un Blueprint dichiara, con registrazione gratuita del workspace aperta a fine settembre e Dedicated Cell a pagamento per codice applicativo custom. La postura gestita completa resta vincolata ai gate della roadmap.
• Niente autenticazione fornita. Il framework non autentica nessuno: il deploy deve fornire l'adattatore, e la modalità produzione rifiuta di partire senza. In sviluppo locale un header attore vale come dichiarazione, non come identità.
• Niente prontezza generale. Nessuna pretesa di production-readiness, e il tasso di build agentica di successo non è misurato: qualsiasi percentuale attribuita al progetto è inventata.
• Interfaccia CRM con baseline deployata ma non percorsa dal vivo. Il web CRM ha login di prodotto e onboarding dal vivo, ma il giro completo sulla nuova UX non è ancora stato ripercorso da un umano: è baseline, non esperienza convalidata.
• Un caso validato su ventitré. La classificazione M2 è onesta e meccanicamente verificata: un solo caso validato end-to-end contro nove parziali, sette non applicabili e sei differiti. Validato significa eseguito dal vivo, non scritto nella roadmap.

Domande frequenti

Accordo sostituisce il mio CRM?

No, e non è quello che promette. È un framework per costruire il sistema commerciale su misura quando il processo è il prodotto: il risultato è codice tuo, revisionabile, nel tuo repository. Il Cloud ospita solo ciò che un Blueprint esprime, con registrazione gratuita aperta: se ti serve un CRM ospitato chiavi in mano da usare domani, oggi non è quello.

L'agente può approvare un rinnovo da solo?

No. La policy deterministica ferma sopra soglia tutto ciò che richiede un umano nominato, e il divieto all'agente è un test che fallisce, non un'istruzione. L'agente propone attraverso workflow nominati; la decisione resta alla persona.

Cosa distingue la customer foundation da un CDP?

Il perimetro: import JSON bounded con ricevute per riga, idempotenza, matching deterministico e identità logica, con collegamenti canonici decisi da umani. Niente streaming, niente segmentazione di audience, niente attivazione, niente timeline completa. Accanto a un CDP esterno ci sta come strato di processo deterministico, non come sostituto.

Quando sarà pronto per un uso esterno?

Quando la sequenza lo dirà con evidence eseguibile: pilot Arvo, hardening dei casi d'uso, baseline UI di prodotto, fondazione condivisa con isolamento misurato, due run Zeno alla cieca, e solo dopo il pilot esterno. Ogni gate ha criteri scritti; nessuno si supera per dichiarazione.