Non un servizio.
La base per estendere Pwas.

Nella maggior parte delle piattaforme un'estensione vive ai margini: un plugin che si aggancia a un punto previsto, con un proprio modello di permessi, una propria interfaccia e una propria vita. Funziona finché qualcuno ricorda che esiste.

Qui è diverso, e la differenza è strutturale. Un tool costruito su questa base si dichiara come risorsa — quali azioni espone, quali campi accetta, cosa restituisce, cosa fare in caso di errore — ed entra nel Capability Registry insieme a tutto il resto. Da quel momento è una capacità come le altre: una pipeline lo richiama come richiamerebbe un'operazione interna, l'orchestratore lo può includere in un piano compilato, i permessi che valgono per chi lo invoca valgono anche lì.

La conseguenza che conta davvero: quello che costruite non è un'eccezione da mantenere a parte. Non ha un proprio livello di autorizzazione da tenere allineato, non è invisibile all'agente AI, non sfugge alla tracciabilità. È il motivo per cui l'estensibilità qui non produce il debito tecnico che di solito produce.

La base fornisce le parti che sono identiche in ogni tool e che nessuno ha voglia di riscrivere ogni volta: il contratto di comunicazione con la piattaforma, l'autenticazione, la coda asincrona per le elaborazioni che durano più di una richiesta, i webhook per segnalare il completamento, e l'accesso ai modelli linguistici attraverso driver intercambiabili.

Quello che scrivete voi è la logica specifica: come si legge quel formato di documento, come si calcola quella cosa, come si parla con quel sistema che nessun altro ha. In pratica, il vostro codice comincia dove finisce ciò che è comune, che è esattamente dove dovrebbe cominciare.

Il primo tool costruito su questa base è il risolutore documentale: estrazione di campi da PDF e immagini via modello multimodale, generazione di documenti da dati e base di conoscenza, anonimizzazione dei dati personali. È insieme uno strumento utilizzabile e un esempio completo di come si struttura un'estensione seria.

La regola pratica è semplice e vale la pena rispettarla, perché forzarla in un senso o nell'altro si paga.

• Resta in una pipeline dichiarata quando l'operazione si esprime componendo passi: condizioni, cicli, funzioni, chiamate a servizi esterni. È la maggior parte dei casi, ed è la scelta che mantiene tutto leggibile.
• Costruisci un tool dedicato quando serve codice vero: lettura di formati particolari, conversioni, calcoli numerici, elaborazioni lunghe, integrazioni con sistemi che parlano protocolli propri, prompt complessi verso un modello.

La cosa da non fare è piegare una pipeline dichiarata fino a farla diventare un programma scritto male pur di non uscire dalla configurazione. Quando serve codice, isolarlo in un componente con la propria coda e dichiararlo è più pulito, più verificabile e più facile da sostituire.

Un tool costruito su questa base è codice vostro, nel vostro repository, rilasciato con le vostre procedure. Non c'è un marketplace da cui passare né una certificazione da ottenere perché funzioni: si dichiara e viene richiamato.

Nella pratica questo è ciò che permette a un partner o a un'azienda con competenze verticali forti di costruirsi un patrimonio riutilizzabile: il tool che legge il formato di scambio tipico di un settore, quello che parla con un macchinario specifico, quello che calcola una cosa che solo voi calcolate. Lo riusate su ogni progetto di quel settore, e non appartiene a noi.