Punto di accesso unico per tutti i documenti di questo percorso di studio: 4 studi tecnici, 2 presentazioni, glossario, cronologia, prossimi step. Aggiornata di pari passo agli studi.
Stiamo costruendo un CPQ con interfaccia conversazionale per PMI italiane B2B distribuzione multi-brand.
Modello bi-dimensionale: knowledge consulenziale per brand (Knowledge Tools MCP) + dato strutturato cross-brand (PIM lite + Mexal + Promo).
Pattern centrale: PIM filtra (recall alto) → Knowledge Tools brand validano (precisione alta) → Supervisor sintetizza in 3 stati distinti (compatibile / consigliato / sconsigliato).
Cantiere arcocat — dashboard live →
Stato live del cantiere arcocat: 5 nodi done, 2 pendenti, 3 futuri. Diagramma sistema, timeline, prossimi passi, glossario sigle. Apri questa quando torni dopo una pausa per riprendere il filo in 2 minuti.
Mappa mentale arcocat — overview + 4 zoom →
Visualizzazione interattiva della constellation MCP: 1 Supervisor + N Knowledge Tool brand, onboarding 7 fasi, pipeline Filter-then-Validate runtime, capability negotiation cross-brand (componibile vs atomico), ConfigurationContext multi-turno. Diagrammi Mermaid + sidebar di navigazione fra le 5 mappe.
5 percorsi di lettura specifici per ruolo. Scegli il tuo, parti dal documento indicato. Tempo stimato di lettura include il primo passaggio, non l'approfondimento.
Vuoi capire cosa costruire e come. Inizia dal master architetturale, poi vai al playbook operativo.
Tempo: ~65 min lettura. Output: chiaro su modello bi-dim + 5 livelli + come onboardare un nuovo brand.
Vuoi capire se vale la pena, quanto costa, quanto ci si mette. Salta i dettagli tecnici, vai al pitch dedicato.
Tempo: ~25 min. Output: ROI atteso, payback period, 3 step per partire.
Vuoi capire come posizionarti nel mercato che cambia. Pitch tecnico-commerciale dedicato.
Tempo: ~38 min pitch + approfondimento opzionale. Output: il vostro asset Mexal come MCP + modello commerciale per onboarding clienti.
Vuoi capire come il tuo sapere entra nel sistema senza sparire nei "manuali AI". Pattern Karpathy = wiki editabile da te.
Tempo: ~28 min. Output: capisci come scrivere regole tecniche in MD editabile da UI senza programmare.
Vuoi vedere il modello senza implementare nulla. Stai qui sulla mappa, leggi sezione 5 (concetti fondamentali) e sezione 7 (fonti di triangolazione).
Tempo: ~10-15 min. Output: capisci il pattern senza dover entrare nei dettagli implementativi.
Approfondimento del punto chiave dell'hero. Lo studio risponde a una domanda specifica: "come si introduce l'AI agentica in una PMI manifatturiera/distribuzione italiana, in modo che funzioni davvero e non sia solo hype?"
La risposta sintetica: non si tratta di "fare un chatbot" ma di costruire un CPQ (Configure-Price-Quote) con interfaccia conversazionale. CPQ e' una categoria di software industriale documentata da 30 anni (SAP, Salesforce, Oracle ci hanno costruito sopra interi business). La novita' e' che oggi possiamo costruire un CPQ lite usando LLM come uno dei mattoni, a costi accessibili per una PMI.
Il design e' organizzato in 5 livelli architetturali (Typed Query Layer, Supervisor Filter-then-Validate, Fonti eterogenee, Configuration Context, Infrastruttura) e 4 fonti di knowledge (Mexal MCP, PIM, Knowledge Wiki brand, Configuration Context). Le 4 fonti sono popolate da 3 source originali (gestionale, PDF catalogo brand, esperto interno).
Quattro documenti tecnici, ognuno con il proprio scope. Da leggere in ordine se siete nuovi all'argomento. Da consultare a singolo se gia' avete il quadro.
Master architetturale completo: framing CPQ, modello bi-dimensionale (knowledge verticale + cross-cutting orizzontale), 5 livelli, 4 contratti tipizzati, scelte tooling, 9 punti aperti, dimensionamento VPS. ~40 minuti di lettura.
Leggi lo studio →Volume operativo: timeline strumenti per fase (Mese 1-12), 5 flussi end-to-end con strumenti per ogni step (incluso Flusso 5 cross-brand strutturato), diagramma end-to-end del sistema completo. ~25 minuti.
Leggi lo studio →Pattern Karpathy applicato al livello knowledge editabile: pipeline OCR doppia, wiki autoritativo a 4 categorie (D/G/R/F), single source of truth, 5 pattern di context engineering, eval set, frontmatter eseguibile esteso per Rule Engine. ~28 minuti.
Leggi lo studio →Playbook operativo a 7 fasi per onboardare un nuovo brand al CPQ multi-brand. Per ogni fase: cosa fare, strumenti, deliverable, prompt template per Claude Code, errori comuni. Stima tempi realistica per brand 1, 2, 10. ~25 minuti.
Leggi lo studio →Due presentazioni HTML standalone, navigabili con frecce/spazio, esportabili in PDF (tasto P). Stessa sostanza, audience diversa.
Per concessionari Mexal/Passepartout (es. Dotcom). Tono consulenziale tecnico con punto di rottura forte ("voi diventate solo backend in 24 mesi"). Include codice, snippet YAML, pattern industriali (CPQ, PIM, MCP, Karpathy). 53 slide, 35-40 minuti.
Apri presentazione →Per imprenditori PMI manifatturiere/distribuzione B2B. Tono consulenziale-business. Niente codice, niente jargon. Focus su ROI, payback, asset strategico (esperto interno), rischi del non muoversi. 30 slide, 20-25 minuti.
Apri presentazione →Lo studio non e' nato perfetto. La cronologia di seguito mostra come e' evoluto. Utile per capire perche' certe scelte sono state fatte.
| Versione | Data | Cambiamento principale |
|---|---|---|
| v1.0 | 2026-05-04 (inizio) | Prima stesura: 6 layer, 9 punti aperti, dimensionamento VPS, principi guida |
| v1.1 | 2026-05-04 | Aggiunta sezione "Memoria 3 livelli" |
| v1.2 | 2026-05-04 | Aggiunta sezione "Modello di esecuzione asincrono" + lista anti-pattern |
| v1.3 | 2026-05-04 | Aggiunta sezione "Pattern dati: constellation vs centralizzato" + federazione |
| v2.0 (REWORK) | 2026-05-05 | Riscrittura strutturale dopo che la domanda "lavastoviglie 60 classe A cross-brand" ha fatto emergere lacune del modello mono-asse v1.x. Triangolazione su 3 fonti: review SOTA interna (PIM Akeneo, LangGraph, Anthropic multi-agent paper, Algolia RRF) + articolo Pankaj "Best RAG Architectures" + validazione esterna ChatGPT+Gemini. Introdotti: modello bi-dimensionale, 5 livelli, Filter-then-Validate, 4 contratti tipizzati, framing CPQ, Karpathy esteso con frontmatter eseguibile, hybrid retrieval BM25+RRF, Configuration Context come stato persistito strutturato. |
| v2.1 | 2026-05-05 | Allineamento tooling: aggiunti al master sentence-transformers, pdfplumber, PyMuPDF, Sentry, UptimeRobot (strumenti effettivamente in uso in BlumCat). Callout "Stato dei tooling: oggi vs futuro". Sincronizzazione versioni nei prompt template del playbook. Bump documenti correlati (flussi v1.3, playbook v1.1). |
| v2.2 | 2026-05-05 | Post primo audit periodico. 8° principio "Cost variability" + hard rule MCP ephemeral/lazy-connect nel Layer C + CRAG promosso a punto aperto con trigger esplicito post-2°brand + AI Act risk assessment marcato URGENTE (Mese 2-3) per finestra enforcement EU 2 ago 2026 + nuova sezione "Pattern non adottati e perche'" (Microsoft Agent Framework, DSPy, LangGraph full, FastMCP 3.0, Akeneo Community, Anthropic Managed Agents non verificato). Confabulazioni audit (Sonnet 5, Managed Agents) skippate; bumpato prompt audit a v1.2 con regola "verifica fonte primaria". |
Sezione organizzata in 3 cluster omogenei: cosa costruiamo, come decide, tooling operativo. Ogni cluster ha una natura concettuale distinta.
CPQ (Configure-Price-Quote) con interfaccia conversazionale per PMI italiane B2B distribuzione multi-brand. NON un chatbot prodotto. La distinzione e' decisiva: chatbot risponde a domande, CPQ configura soluzioni vincolate.
Knowledge consulenziale (regole, decision tree, distinte canoniche, schede narrative). Constellation di Knowledge Tools MCP, uno per brand. Il sapere "brand-specific" vive qui.
Dato strutturato (PIM con attributi tipizzati) + business (Mexal: prezzo/disponibilita') + promo. Singleton centralizzati. Quello che e' "comune" tra brand vive qui.
In conflitto vince Knowledge: il "si potrebbe MA sconsiglio perche'..." e' il valore consulenziale.
| Contratto | Forma | Editabile da |
|---|---|---|
| TypedQuery | Codice puro | Sviluppatore |
| CategorySchema | MD-Karpathy (C*.md) | Esperto interno via UI |
| Rule | MD-Karpathy con frontmatter eseguibile (R*.md) | Esperto interno via UI |
| ConfigurationContext | Codice puro (Postgres JSONB) | Sviluppatore |
Compatibile = PIM ok, Knowledge non valuta.
Consigliato = PIM ok + Knowledge approva attivamente.
Sconsigliato = PIM ok MA Knowledge segnala problema (rischio, vincolo, incompatibilita').
File Markdown con frontmatter YAML. Stessa fonte, due letture: l'esperto modifica narrativa + tabelle, la macchina parsa metadati strutturati. R*.md hanno frontmatter eseguibile per Rule Engine deterministico (test embedded).
Dify gestisce: chat UI + Supervisor visuale + observability base + integrazione MCP.
Custom Python resta: PIM (Postgres+JSONB), Rule Engine, Knowledge Tools brand (con hybrid retrieval avanzato), Configuration Context.
Risultato: -30/-40% tempo sviluppo per cliente, lock-in parziale gestibile.
| Termine | Significato breve |
|---|---|
| CPQ | Configure-Price-Quote, software industriale (30 anni di tradizione) |
| PIM | Product Information Management, schema attributi tipizzati per categoria |
| MCP | Model Context Protocol (Anthropic), protocollo standard per esporre tool a LLM |
| MD-Karpathy | Knowledge editabile come file Markdown con frontmatter YAML (pattern di Andrej Karpathy "LLM Wiki") |
| Frontmatter eseguibile | Estensione del frontmatter YAML con condizione/azione/test parsabili da evaluator |
| Supervisor | Agente "capo" che orchestra senza fare lavoro diretto |
| Filter-then-Validate | Sequenza PIM filtra → Knowledge brand valida (NON parallelo) |
| Constellation vs Singleton | Constellation = molti servizi standalone (uno per brand). Singleton = uno solo condiviso. |
| Slot filling | Parsing pre-LLM testo → oggetto strutturato tipizzato |
| Typed Query Layer | Livello 1 dello stack v2.0: deterministico, prima del LLM |
| Configuration Context | Stato persistito JSON tipizzato di una sessione utente |
| Knowledge Tool | MCP server per brand (NON agente autonomo). Espone tool standard + dominio. |
| RRF | Reciprocal Rank Fusion, formula 1/(k+rank) per merge cross-source di score incompatibili |
| Hybrid retrieval | BM25 FTS5 + cosine semantica + RRF, per dominio tecnico misto |
| Tre stati | Compatibile / Consigliato / Sconsigliato nella risposta del Supervisor |
| Karpathy pattern | Wiki narrativo curato umanamente come MD, letto da umani + parsato da macchina |
| Migration path | 5-step sequenza per portare BlumCat reale dentro lo stack v2.0 (10-13 settimane) |
| arcocat | Nome di lavoro della piattaforma multi-catalog (BlumCat + futuri Bosch/Whirlpool/...) |
| BlumCat | Bot tecnico per catalogo Blum, in produzione dal 2026-04-29 su LAN aziendale Arco |
Lo studio v2.0 e' triangolato su 4 fonti indipendenti. Ogni scelta architetturale e' stata validata contro almeno 2 di queste:
SAP CPQ, Salesforce, Oracle, ServiceNow CPQ, DealHub, Servicepath, Alguna. Categoria di software che modella spazio configurazioni vincolate. Il framing CPQ del nostro design viene da qui.
"How we built our multi-agent research system". Pattern orchestrator-worker (lead Opus + sub-agents Sonnet). +90.2% performance vs single-agent. Pattern Supervisor v2.0 deriva da qui.
Akeneo PIM. Modello dati Family + Category + Attribute tipizzato + brand-as-attribute. Il PIM lite del v2.0 replica questo schema in Postgres+JSONB con MD-Karpathy.
Review architetturale comparativa fatta da ChatGPT + Gemini su prompt strutturato. Convergenza forte (8 punti) su: Configuration Context, Filter-then-Validate, Typed Query Layer, Rule Engine deterministico, framing CPQ. Tutti integrati nel design.