Sette prodotti, un dominio dichiarativo condiviso.

È la combinazione da cui parte la grande maggioranza dei progetti: si descrive il dominio, il backend lo esegue e le interfacce si generano dalla stessa dichiarazione. È sufficiente per applicazioni gestionali complete — commesse, pratiche, spedizioni, procedimenti — e per portali rivolti a clienti o cittadini.

L'orchestrazione non serve finché non volete che qualcosa agisca sui dati in autonomia. Molti progetti restano qui a lungo, e va benissimo: l'AI ha senso quando il dominio è descritto bene, non prima.

Si aggiunge quando serve che una richiesta in linguaggio naturale diventi un'azione, non una risposta. Il passaggio non è un'integrazione: l'orchestratore legge il registro delle capacità che il backend già produce, quindi conosce ciò che esiste e ciò che è permesso senza che nessuno glielo ridica.

Il percorso che funziona meglio è graduale: prima sola lettura sulle domande operative, che è a rischio zero e fa emergere i limiti della descrizione del dominio; poi azioni a basso impatto con conferma umana; poi il resto.

Non sono componenti del runtime ma strumenti che agiscono prima: raccogliere in modo strutturato la conoscenza sui processi, e trasformare documentazione esistente in un blueprint da rivedere.

Servono nei progetti dove la fase di comprensione del dominio è la parte lunga — tipicamente modernizzazione di sistemi storici e organizzazioni grandi con processi non scritti. In un progetto piccolo e ben compreso non aggiungono granché, ed è giusto saperlo.