Architettura a tre piani

In breve

Quando documenti, integrazioni e agenti formano un blocco unico, ogni guasto sembra appartenere «all’AI». Il modello proposto qui distingue conoscenza, capacità funzionali e worker: non è uno standard, ma una mappa che indica quale contratto revisionare quando cambia una fonte, fallisce uno strumento o l’incarico è ambiguo.

FONTI ──► [ CONOSCENZA ] ── contesto e criteri ──┐
                                                  ▼
RICHIESTA ───────────────────────────────► [ WORKER ] ──► RISULTATO
                                                  │
                                                  │ invoca
                                                  ▼
                                         [ CAPACITÀ ]
                                           │      │
                                      effetto   prova/esito

Il worker consulta conoscenza con provenienza dichiarata, invoca capacità autorizzate e restituisce risultato e prova. Il protocollo di delega attraversa quindi i piani senza fonderli.

Matrice operativa

Piano	Contiene	Produce	Può cambiare quando	Non deve fare
Conoscenza	fonti, manifesti, sintesi, date, criteri di provenienza	contesto citabile e lacune visibili	una fonte viene aggiornata, riclassificata o smentita	eseguire azioni o trasformare una sintesi in comando implicito
Capacità	adattatori, procedure e strumenti con input ed effetti delimitati	un effetto osservabile e il relativo esito	cambia un’interfaccia, un canale o una condizione d’errore	decidere da sola scopo, priorità o accettabilità del risultato
Worker	ruolo, incarico corrente, capacità ammesse	artefatto, decisione motivata e resoconto	cambia l’obiettivo o viene assegnato un esecutore diverso	diventare archivio permanente o proprietario occulto delle integrazioni

Il test è pratico: ciò che cambia con una fonte appartiene alla conoscenza; una trasformazione ripetibile è una capacità; chi porta un incarico a un esito è un worker. Le zone grigie vanno motivate.

Un caso concreto: correggere il lessico, non il runtime

Una fonte primaria ha cambiato il nome con cui descriveva una superficie, senza modificare protocollo o modalità d’invocazione. La voce pubblica usava ancora il termine precedente come se fosse ufficiale.

La correzione ha aggiornato il piano della conoscenza — terminologia, data di revisione e collegamento canonico — mentre l’adattatore e il ruolo del worker sono rimasti invariati. Se quel nome fosse stato duplicato nella capacità o nelle istruzioni persistenti del worker, una rettifica editoriale avrebbe richiesto modifiche operative prive di necessità.

Il manifest unico delle fonti rende localizzabile la provenienza; la separazione dei piani contiene invece l’effetto della sua revisione.

Dove cercare quando il risultato è sbagliato

La separazione serve soprattutto alla diagnosi:

Sintomo	Primo piano da ispezionare	Domanda discriminante
risposta plausibile ma non citabile	conoscenza	la fonte esiste, è aggiornata e distingue fatti da inferenze?
azione eseguita su un artefatto diverso da quello previsto	capacità	il controllo prova il canale realmente usato o soltanto una sua copia?
output corretto ma fuori perimetro	worker	l’incarico dichiarava esplicitamente artefatti ammessi e divieti?
vista di controllo assente mentre il lavoro continua	capacità di osservazione	la perdita di telemetria è segnalata senza bloccare il worker?

Decisioni architetturali

La conoscenza non esegue. Una fonte può descrivere una procedura senza essere autorizzata a produrre effetti.

Le capacità hanno contratti piccoli. Input, effetto, errore e prova devono essere descrivibili senza conoscere l’intera identità del worker.

Il worker possiede l’esito, non l’infrastruttura. Può scegliere una capacità ammessa, ma non ridefinisce fonti o criteri persistenti. Questi appartengono alla persona come memoria operativa.

L’osservatore resta laterale. La control tower read-only legge eventi, ma non assegna lavoro: un secondo orchestratore nascosto renderebbe di nuovo ambigua la responsabilità.

Limiti

Per un singolo script e una fonte stabile, tre piani possono essere burocrazia. Il modello conviene quando fonti, strumenti e worker evolvono con ritmi diversi o la revisione deve attribuire un errore.

Non basta dare tre nomi alle cartelle. Il criterio finale è sostituibilità: ciascun piano deve poter cambiare senza trascinare automaticamente gli altri due.

Voci correlate

• Protocollo di delega dei worker
• Personas come memoria operativa
• Control tower read-only

Fonti

• NIST AI Risk Management Framework, riferimento per rendere esplicite governance e responsabilità; il modello a tre piani resta una scelta progettuale di questa wiki.
• Anthropic: Building effective agents, riferimento pratico per distinguere workflow composti e agenti; non prescrive questa architettura.
• Matrice, caso e decisioni derivano da esperienze operative private qui ricostruite in forma anonimizzata, senza percorsi, configurazioni o identità degli esecutori.