Salta ai contenuti

Protocollo di delega dei worker

Un contratto di delega traduce l’intento in perimetro, risultato, prova e condizioni di arresto controllabili da un revisore indipendente.

«Migliora questa documentazione» trasferisce un’ambiguità. Un contratto utile specifica che cosa conta, dove intervenire e quando fermarsi, così un revisore può stabilire senza conoscere il ragionamento dell’esecutore se l’incarico è stato soddisfatto.

A2A definisce task, delega, artefatti e stati del loro ciclo di vita (Life of a Task). Non prescrive però il perimetro dei file, i criteri di accettazione del progetto o le evidenze richieste da un incarico locale. La distinzione è approfondita in MCP e A2A.

Questo esempio è deliberatamente ordinario: aggiornare una sola voce dopo la revisione di una fonte. Proprio la banalità rende visibili i campi che spesso vengono lasciati impliciti.

OBIETTIVO
Rendere la definizione iniziale coerente con l’evidenza fornita.
PERIMETRO SCRIVIBILE
Una sola voce Markdown indicata nell’incarico.
INPUT AUTORIZZATI
Testo corrente della voce e due estratti di fonte già acquisiti.
VINCOLI
Non modificare altre pagine, configurazioni o storia Git.
Non introdurre dettagli assenti dalle fonti.
RISULTATO ATTESO
Definizione riscritta, un esempio anonimizzato e un collegamento interno.
PROVA DI SUCCESSO
Diff limitato al file assegnato; controllo editoriale e build mirata verdi.
CONDIZIONE DI ARRESTO
Se le due fonti si contraddicono, non scegliere: segnala il conflitto.
RESOCONTO
File modificato, controlli eseguiti, incertezze residue; massimo cinque righe.

Il contratto concede libertà su prosa e ragionamento, ma non sul raggio d’azione. Distingue inoltre il risultato dalla prova: «ho aggiornato la voce» è un’affermazione dell’esecutore; un diff limitato e un controllo verde sono osservazioni ripetibili dal revisore.

Obiettivo e risultato non sono sinonimi. Il primo spiega il cambiamento; il secondo indica l’artefatto che deve esistere.

Il perimetro separa lettura e scrittura. Un worker può consultare molto materiale e modificare un solo artefatto.

La prova osserva la proprietà dichiarata. Se serve un determinato canale, non basta verificarne una copia altrove. Verificare il canale eseguito mostra perché un controllo verde sull’oggetto sbagliato è fuorviante.

La condizione di arresto tutela dall’invenzione. Fonti contraddittorie, input mancanti o effetti irreversibili non autorizzati devono chiudere il task con un gap circoscritto.

In una serie interna di quattro modifiche, il formato «un file, effetto preciso, divieti espliciti, risposta breve» ha prodotto quattro consegne verificabili. Richieste che combinavano più comandi e una sintesi si fermavano invece talvolta al preambolo pur riportando un esito tecnico positivo.

Un esito del processo non prova quindi la presenza del deliverable. Ne derivano due regole:

  1. il contratto dichiara una forma minima attesa del risultato;
  2. il coordinatore verifica l’artefatto reale prima di assegnare il passo dipendente.

Anche la forma attesa deve coincidere con il controllo: cercare FILE=numero quando il contratto chiede FILE numero boccia una risposta corretta.

Parallelismo: dividere per proprietà, non per volume

Sezione intitolata “Parallelismo: dividere per proprietà, non per volume”

Due incarichi possono partire insieme quando non condividono artefatti scrivibili e nessuno consuma l’output provvisorio dell’altro.

Situazione Esecuzione Motivo
due voci indipendenti, una fonte comune in sola lettura parallela i risultati non si sovrascrivono
una voce e il test che ne assume già la forma finale sequenziale il test dipende da una decisione non ancora stabilita
due worker sulla stessa pagina evitare il conflitto è semantico anche se Git riesce a unire le righe
esecuzione e revisione indipendente dello stesso risultato sequenziale il revisore deve ricevere un artefatto stabile

Il coordinatore possiede il punto di integrazione: controlla compatibilità, dipendenze e verifiche. Nell’architettura a tre piani, il worker possiede il proprio risultato, non il sistema complessivo.

Prompt enciclopedico. Confonde regole stabili, task e riferimenti. Le prime appartengono alla persona operativa; nel contratto resta ciò che serve ora.

Fidarsi del resoconto. Orienta la revisione, ma non sostituisce la lettura dell’artefatto o un controllo indipendente.

Parallelizzare ogni attività. Più worker sulla stessa decisione aumentano gli output, non la velocità d’integrazione.

La precisione va proporzionata a rischio e reversibilità. Una ricerca esplorativa può avere un risultato aperto; una modifica automatica richiede artefatti, prova e arresti netti. Il contratto fallisce quando diventa un rituale o prescrive ogni passaggio mentale.

Un buon segnale è questo: il worker può scegliere il metodo, il revisore può controllare l’esito e nessuno dei due deve indovinare che cosa fosse autorizzato.

  • A2A Protocol, fonte primaria per la comunicazione interoperabile tra agenti; non prescrive il contratto locale descritto qui.
  • NIST AI Risk Management Framework, riferimento per ruoli, supervisione e gestione del rischio; non definisce questa granularità operativa.
  • Contratto ed episodi sono distillati da prove private e pubblicati in forma anonimizzata, senza nomi degli esecutori, percorsi o dati di esecuzione.