Sviluppare con un team di agenti

Appunti di configurazione avanzata del sistema di sviluppo con cui lavoro

Periodo

dal 2025

Ruolo

progettazione e realizzazione

Ambito

strumenti di sviluppo

Tecnologie

Claude Code · Codex · MCP · Python · Git · tmux · SSH

Stato

in uso quotidiano

Questi sono appunti di configurazione avanzata di un sistema di sviluppo costruito attorno a un team di agenti AI. Non un'introduzione agli assistenti di codice e nemmeno un elenco di consigli: la descrizione di un impianto che uso tutti i giorni per scrivere software di produzione, con i pezzi che lo compongono, il modo in cui si tengono insieme e i punti in cui cede.

Lo scopo è doppio. Il primo è mio: un sistema del genere si sedimenta per accumulo — una regola qui, un hook là, una skill scritta di fretta — e dopo sei mesi non si sa più perché una cosa è com'è. Fissare il punto attuale, con l'evidenza accanto a ogni affermazione, è ciò che permette di riprenderlo invece di rifarlo. Il secondo è che quasi tutto quello che c'è qui dentro non è specifico del mio lavoro: il modo di dare a un agente la conoscenza che gli manca, il secondo modello che fa da giudice, i guardrail che si attivano da soli, la configurazione che vive in un repo invece che su una macchina, valgono per chiunque scriva codice con questi strumenti.

Il livello tecnico è quello di chi programma, e non l'ho abbassato. I sistemi su cui lavoro li descrivo per quello che fanno, senza nominarli: sono software aziendale, e i nomi qui non servirebbero a niente.

Come si legge. Otto voci. Sei vengono da una lista scritta a mano di funzionalità che uso davvero — il giudice avversariale, i più agenti insieme, i loop, i dotfiles, la configurazione a strati, i plugin e le skill. Due le ho aggiunte: il metodo in testa, perché è la disciplina che ordina tutte le altre, e MCP in coda. Ogni voce dice cos'è, com'è messa oggi con l'evidenza per riaprirla fra sei mesi, e dove può andare. Dove un numero viene da una misura c'è la data: alcuni sono già invecchiati.

1. Il metodo Karpathy: spec, verificatore, ambiente

Cos'è. La disciplina con cui si conduce il lavoro con l'IA, in tre livelli — è l'impostazione che Andrej Karpathy ha descritto parlando del proprio modo di lavorare, e la uso come griglia per capire dove sono scoperto. Non produce un artefatto proprio: produce il modo in cui si fanno tutti gli altri.

Com'è messo oggi. L'audit del Livello 3 è a sua volta una skill, che restituisce una punch list invece di un giudizio. L'ultimo esito è la fotografia più onesta che ho:

• un guardrail difende la porta principale ma non la finestra (ci torno nella §6);
• il Livello 1 non ha alcun aggancio operativo: manca una regola del tipo «task multi-step ⇒ si esplicitano piano e criteri di verifica prima di partire». Oggi succede per abitudine, e l'abitudine non è un guardrail;
• una skill che vive su una macchina sola.

Il verificatore è la parte che ha reso di più, ed è il Livello 2: un secondo modello, di un altro fornitore, istruito a demolire invece che a confermare. Ha una voce sua, la §2.

La knowledge base, cioè l'LLM-wiki

È l'elemento del Livello 3 su cui ho lavorato di più, e prende due forme — che si distinguono chiedendosi chi legge la risposta.

La prima sta nel repo, e la legge l'agente. CLAUDE.md/AGENTS.md per come si lavora qui, codemap.md per orientarsi, decisions.md per sapere perché una cosa è com'è, i runbook per le procedure che si ripetono. È conoscenza di processo: esiste solo dentro il progetto e con esso finisce.

La seconda è un LLM-wiki vero e proprio, e la legge una persona che aveva una domanda. È un vault di documenti curati che il modello interroga con le citazioni, invece di rispondere a memoria: il modo di dare a un modello un dominio che non conosce — norme, manuali, procedure — e di poterlo riportare alla fonte.

La struttura sono tre layer che non si mescolano mai:

• raw/ — le fonti grezze, immutabili: si legge, non si scrive. Mai.
• wiki/ — le pagine generate, di proprietà dell'agente: sources/ (un riassunto per fonte), entities/, concepts/, analyses/.
• index.md, log.md, hot.md — catalogo, registro append-only delle operazioni, e una cache di contesto rigenerata a fine sessione.

Il vault che tengo oggi ha 130 pagine di fonti e 66 concept, in larga parte schede di mercato paese per paese.

Il patto sta scritto nel suo CLAUDE.md, ed è la riga che regge tutto: l'agente è il manutentore, io sono il curatore. L'agente propone, l'approvazione è umana — non come principio ma come procedura. Il gate del curatore su una pagina densa è una verifica claim-per-claim contro il codice che quella pagina descrive, e la bozza passa solo dopo averla superata: niente numeri inventati, definizioni chiave confermate a voce, banner di bozza rimosso per ultimo.

Due regole lo tengono onesto:

• Non duplica il corpus. I documenti veri vivono nel servizio che li indicizza, e la pagina li referenzia con un identificatore di contenuto (rag:<sha256>) invece di copiarli. Così il vault resta leggero e clonabile ovunque, e non esistono due copie dello stesso documento che divergono in silenzio.
• Il questionario per l'esperto di dominio. Riconosce che ci sono buchi che il modello non colma da solo, e li gira a chi sa. La regola dentro è quella buona: l'esperto rivede, non redige, e il grado di sicurezza che dichiara decide il destino del punto dubbio.

La tecnica è portabile, ed è il motivo per cui sta qui e non in un documento sul lavoro: una skill costruisce un vault con questa struttura a partire da una cartella di documenti (PDF, DOCX, XLSX, MD). Lo scaffold è deterministico e gratuito — è uno script; l'ingest è un passo separato, perché è l'unico che costa token.

Dove può andare. Il Livello 1 è il buco vero, ed è anche il più economico da chiudere: una riga nel CLAUDE.md che imponga piano e criteri di verifica prima di un task multi-step, sul modello del contratto che già funziona nel lavoro autonomo. Finché non c'è, due livelli su tre sono presidiati e il primo va a memoria.

2. L'agente revisore avversariale

Cos'è. Un secondo modello, di un altro fornitore, che rivede il lavoro prima della chiusura — separato da chi l'ha scritto. Non un secondo parere gentile: è istruito a demolire.

Com'è messo oggi. Un plugin sopra la CLI di un modello concorrente, con tre porte d'ingresso che hanno proprietà diverse:

Le ultime due sono marcate disable-model-invocation: true: l'agente non se le può lanciare da sé. È una distinzione che conta — un giudice che l'imputato può convocare a piacere non è un giudice.

Il prompt avversariale è la parte che vale. In sintesi: «il tuo lavoro è distruggere la fiducia nel cambiamento, non validarlo»; una superficie d'attacco dichiarata — permessi e isolamento fra tenant, perdita o corruzione di dati, rollback e idempotenza, race e assunzioni sull'ordine, degrado delle dipendenze, schema drift, buchi di osservabilità; e una calibrazione che evita il rumore, «meglio un rilievo forte che diversi deboli», niente stile e niente naming.

La regola d'ingaggio sta scritta nei CLAUDE.md. Quattro criteri per convocarlo: modifica a un contratto condiviso con altri sistemi, cambio di comportamento non coperto dai test, decisione architetturale, bugfix il cui root cause non è dimostrato da un test che prima fallisce e dopo passa. E l'obbligo che conta davvero: il verdetto si riporta per intero, obiezioni non recepite comprese, prima di proporre il commit.

Il cancello automatico è una cosa diversa, e più interessante. Il plugin registra un hook sull'evento di chiusura del turno: quando la sessione prova a dichiararsi finita, l'ultimo turno va al giudice, che risponde ALLOW o BLOCK. Su BLOCK la sessione non si chiude e l'agente torna a lavorare. Si accende per progetto, ed è fail-closed: timeout, errore o formato inatteso valgono block.

È una differenza di categoria rispetto agli hook della §6: quelli fermano un'azione chiedendo conferma; questo impedisce all'agente di dichiararsi finito, che è il modo tipico in cui fallisce un lavoro autonomo.

Cosa ha reso davvero. Una race fra singleton che avrebbe attribuito a una domanda il canale di un'altra; il budget di un compressore più stretto di quanto la decisione scritta assumesse; quattro bloccanti su un filone di OCR, di cui uno ha cambiato il risultato — misuravo su 375 pagine invece di 448, con dentro una regressione. Quest'ultimo è il caso più prezioso, e dice dove spingere: il giudice ha corretto il banco, cioè lo strumento che corregge tutto il resto.

Il limite da non dimenticare. La sandbox del giudice nega il socket Docker, e in quel progetto i test girano solo dentro il container. Cinque decisioni registrate riportano la stessa frase — «non ha potuto eseguire la suite». Lì giudica per sola lettura statica, sempre. Un giudice che non può eseguire niente è comunque utile, ma va saputo.

Dove può andare. Il secondo giro dopo il fix: oggi il ciclo si chiude in un giro — rilievo, correggo, commit — e quindi il codice scritto in risposta a un rilievo è il meno verificato dell'intero commit. Il macchinario per riaprire lo stesso thread c'è già, e il giudice ricorda i propri rilievi; manca la regola.

3. Più agenti insieme: sottoagenti, sessioni, squadre

Cos'è. Più agenti che lavorano insieme e — la parte nuova — che si parlano, anche fra macchine diverse.

Com'è messo oggi. Tre scale che vengono spesso confuse e non sono la stessa cosa:

1. Subagenti in-process. Contesto isolato, tornano solo la conclusione. Il fan-out di sola lettura — esplorazione, ricerca, review — non richiede precauzioni. Se scrivono, vanno isolati in un worktree per chiamata, altrimenti si pestano i piedi.
2. Sessioni intere che si scrivono. Una le elenca, l'altra riceve il messaggio come evento esplicito. Sono processi separati, con la loro storia.
3. Squadre — un lead e dei compagni. I compagni sono sessioni intere: in background scriverebbero tutti nella stessa cartella, quindi vanno isolati o tenuti in sola lettura.

Il canale va detto con precisione, perché è facile sbagliarlo. Le sessioni sulla stessa macchina si parlano attraverso un daemon locale, con un roster su file e socket unix: non serve alcun canale remoto. Me ne sono accertato guardando da dove arrivava un messaggio — un socket locale — e verificando che il log del daemon, che copre da maggio, non contenga una sola occorrenza di «remote».

Il controllo remoto serve a un'altra cosa: estendere la portata fuori dalla macchina, verso il telefono o l'altra postazione. È acceso di default, non lo si abilita — e questo merita di essere scritto perché me ne sono accorto tardi, guardando una pillola nell'angolo dello schermo e non sapendo cosa fosse. L'avviso c'era stato tre volte e l'etichetta estesa si era mostrata cinque, prima di collassare in una sigla. Il canale era aperto da giorni a mia insaputa.

Quindi i mestieri sono cinque, e nessuno sostituisce l'altro: tmux tiene vivo il processo, SSH agisce sulla macchina, git trasporta il lavoro, il daemon locale fa parlare le sessioni della stessa macchina, il controllo remoto porta il canale fuori dalla macchina.

La regola di convivenza. Le sessioni lavorano nel checkout condiviso e non in worktree isolati, e non è pigrizia: è supervisione, tengo il repo aperto nell'IDE e seguo dallo stage git. Ne segue che la protezione dalle collisioni è a carico dell'agente — guardare git status prima di iniziare, stageare per path esplicito, mai git add -A.

Il limite di principio, e non è tecnico. Un agente non può approvare un permesso al posto mio. Se una sessione chiede a un'altra di fare ciò che a lei è stato negato, quello è aggiramento della decisione umana, e va rifiutato e portato a me. È scritto nel messaggio di sistema che accompagna ogni messaggio fra sessioni, e nel primo giro autonomo l'agente si è fermato due volte esattamente lì.

Cosa ha reso. Una terza sessione, che non aveva lavorato al task, ha riletto il branch e ha trovato l'errore più grosso: una «suite verde» che nascondeva 624 test spariti su 1385 — il riassunto diceva «760 passed, 1 failed» e ometteva due categorie. Nessuno dei due che avevano lavorato al task l'aveva visto.

Dove può andare. La revisione incrociata da terza sessione come passo fisso, non occasionale. E il ponte fra le due macchine usato mentre il lavoro è in corso, non a cose fatte.

4. Loop e lavoro autonomo: quando c'è un banco che giudica

Cos'è. Far girare un agente a lungo, da solo, su un difetto misurabile — e supervisionare a parole invece che leggendo il codice.

Com'è messo oggi. Due cose diverse sotto lo stesso cappello. Gli strumenti di ripetizione sono il come: un loop a intervallo fisso o auto-ritmato dal modello, agenti schedulati a cron, il risveglio programmato dentro una sessione. Il lavoro autonomo è il cosa, ed è la parte costruita e documentata: un metodo con quattro criteri di ammissione, una procedura, un lancio in un comando con sette controlli preventivi (working tree pulito, contratto committato, macchina raggiungibile, keychain vivo, sessione tmux libera, branch nuovo, andata in fast-forward) e un quaderno di 500 righe con le leve provate e scartate, coi numeri.

Il primo giro, una notte d'agosto: un difetto di pipeline sceso dal 22,2% al 13,9%, tredici commit, un solo file di codice toccato — esattamente il bersaglio, senza sconfinare nei file di un'altra sessione.

Le tre cose che hanno funzionato meglio del previsto:

1. Il contratto scritto prima. Sette campi — bersaglio, misura, set, vietato, quando fermarsi, come riportare, quando è finito — approvati da me prima del lancio. È l'ultimo momento di controllo pieno, e regge tutta la notte.
2. Il giudice indipendente. Un banco che dice meglio-o-peggio senza aprire un file. Senza, la supervisione a parole degenera in fiducia cieca. È il criterio di ammissione che cade più spesso: se non c'è un giudice, il task non è adatto.
3. I guardrail come hook. L'autonomia si è fermata due volte, e ogni volta su un hook che chiedeva conferma umana — non su un errore. Il controllo non è sparito: si è spostato dai singoli comandi ai punti decisi in anticipo.

Le tre che sono andate storte, e valgono di più:

1. Il collo di bottiglia non era l'agente: era il canale per parlargli. Ambiente e contesto hanno superato i collaudi al primo colpo; la serata se n'è andata a far arrivare i report. Un client SSH sul telefono si legge ma è ostile alla scrittura, e l'app ufficiale non entrava per un blackout del server di posta — due giorni di diagnosi per scoprire che il problema non era l'agente.
2. Il giudice dice quanto, non dove. Due volte su tre il guadagno non è venuto da un'idea ma dal guardare quale singolo errore introduceva una variante, e quello si vede aprendo il contenuto, non i numeri. «Esiste un giudice» è necessario ma non sufficiente.
3. Il giudice stesso era rotto, e in modo insidioso: sbagliava la categoria dell'errore, non l'entità — dichiarava «documento perso» dove la pipeline ne aveva letti tre in una riga sola, gonfiando proprio il numero che il contratto vietava di peggiorare. Riparato con la definizione scritta in un commit separato prima dell'implementazione, così la sequenza è dimostrabile da git log e non è una promessa.

I numeri di questo filone vanno sempre datati. Il banco è stato riparato un giorno e modificato ancora quello dopo: ogni cifra precedente viene da uno strumento diverso. Il ramo principale, a codice invariato, è passato dal 23,1% al 22,2% solo perché è cambiato il metro.

Dove può andare. Il cancello di chiusura della §2 acceso sulla macchina dove nessuno guarda i turni: il banco dice se il lavoro è migliorato, il cancello impedisce di dichiararsi finito. E serve un quinto criterio di ammissione che copra la lezione 2 — non basta che esista un giudice, serve che il difetto sia localizzabile guardando i casi, non solo contabile.

Il primo giro è un caso singolo. Ha mostrato che il modello regge su un task ben scelto — interno, misurabile, senza contratti condivisi. Non dice niente su task di altra natura, e i quattro criteri servono proprio a non generalizzare troppo presto.

5. Dotfiles: la configurazione vive in un repo

Cos'è. La configurazione degli agenti non vive sulla macchina: vive in un repo, e le due macchine leggono gli stessi file.

Com'è messo oggi. Un repo dotfiles privato. La cartella di configurazione non contiene file veri ma symlink dentro il repo: le regole in prosa, le impostazioni, le skill, gli hook, la statusline, la tabella dei task. Le macchine collegate sono due — quella di scrivania e quella su cui gira il lavoro autonomo.

Le due regole nascono da errori veri.

Git non sincronizza, trasporta: una modifica non pushata non esiste per l'altra macchina, e una macchina che non ha fatto pull sta lavorando su una versione vecchia. Quindi git pull --rebase prima di toccare, e commit e push proposti nella stessa risposta in cui si riporta la modifica.

E soprattutto: si scrive sul path reale nel repo, mai attraverso il symlink. Non è una preferenza di stile — i tre strumenti si comportano in tre modi diversi sullo stesso path: il tool di edit rifiuta di scrivere attraverso un symlink e chiede il target risolto, sed -i lo spezza perché lavora per temp-file più rename, e solo la redirection della shell scrive in place preservandolo. Un path che funziona con uno strumento e non con gli altri è una trappola. Due hook presidiano proprio questo: uno fa il pull, l'altro segnala la deriva.

Una decisione che è stata rovesciata, e vale più della regola stessa. La tabella che associa il codice ai task del gestionale era tenuta fuori dal repo: la regola nei dotfiles, il dato no, perché è dato di lavoro e i dotfiles stanno su un account personale. Poi è entrata, e la premessa si è rivelata mal posta — quel repo non è un ambiente personale, è il canale con cui le due macchine condividono la configurazione. Il costo era concreto: la regola viaggiava col file di contesto, la tabella no, quindi su una delle due macchine arrivava l'obbligo senza il dato per soddisfarlo. Una fonte separata dal suo dato è una fonte che su metà delle macchine non si applica.

Cosa resta fuori di proposito: le credenziali, che stanno nel portachiavi di sistema, e lo stato locale della macchina — sessioni, cache, cronologie.

La memoria dell'agente, invece, è versionata una volta sola: di una decina di cartelle di memoria per progetto, una è un repo git. L'idea era buona — sincronizzare fra macchine e soprattutto rendere visibile a me quello che l'agente ricorda, perché una memoria in git è un commit con un diff invece di un file che cresce di nascosto — ma è rimasta un esperimento su un progetto solo, e va scritto così: le altre non sono versionate né sincronizzate.

Trappole note. Sulla macchina remota il portachiavi bloccato impedisce il push da sessione non interattiva: si pusha dall'altra. E la memoria di là è comunque una copia, quindi diverge.

6. Configurazione a strati: globale, di progetto, di postazione

Cos'è. Tre strati che si sovrappongono, dal più generale al più locale. Sapere quale strato tocchi è metà del lavoro.

Un esempio concreto: il progetto disattiva l'isolamento in background — perché voglio vedere il lavoro nell'IDE mentre accade — e registra un hook sulle scritture e sui comandi di shell; la postazione contiene solo permessi nati da un guaio locale, link simbolici di un virtualenv e versione dell'interprete.

C'è un quarto strato, ed è in prosa: i CLAUDE.md. Quello globale porta le regole che valgono ovunque — le skill cerimoniose da usare con parsimonia, lo schema dei dati che si disegna prima di scriverlo e lo approvo io, la gestione dei dotfiles qui sopra; quello di progetto rimanda agli standard di codice. È configurazione a tutti gli effetti, solo scritta in italiano invece che in JSON.

Gli hook sono la parte che rende esecutive le regole. Sono script che il sistema esegue prima o dopo un evento e che possono rispondere consenti, chiedi o nega. I miei, oggi: il cancello che blocca un commit privo di identificativo del task, il guardiano che intercetta le invocazioni di skill, i due dei dotfiles, e un hook di progetto che blocca le modifiche alle dipendenze e al Dockerfile senza conferma esplicita.

Il Ref #NN: ogni commit sa a quale task appartiene

Merita una sottosezione perché è l'unica cosa qui dentro che non riguarda la programmazione: riguarda la tracciabilità fra il lavoro fatto e il gestionale aziendale. Ogni commit porta in coda al subject l'identificativo del task a cui appartiene — Ref #NN. Non è una convenzione di stile, è un ponte a due sensi: da qui git log --grep restituisce tutto il lavoro di un task; da là, chi guarda un task risale al codice.

È fatto di tre pezzi, uno per strato: la regola in prosa nel CLAUDE.md globale, che stabilisce che l'identificativo lo risolve chi propone il messaggio e non io; la tabella nei dotfiles, con la colonna «si riconosce da»; il cancello, un hook che blocca i commit privi di identificativo.

Il pezzo non ovvio è cosa succede quando la risoluzione non è certa. Con un solo match l'agente scrive l'identificativo e dichiara da dove l'ha preso: io confermo il commit, non il numero. Con nessun match o più d'uno non tira a indovinare — propone il messaggio senza, dice quali righe ha considerato e chiede. Un riferimento sbagliato è peggio di un riferimento mancante, perché sporca la storia di un altro task e fa restituire alla ricerca cose non vere. E quando un intervento non appartiene a nessun task — configurazione, manutenzione, regole degli agenti — si committa senza, dicendolo: l'omissione dev'essere una scelta dichiarata, non una dimenticanza.

Il punto debole è la tabella. La colonna «si riconosce da» è dedotta dai repo, non dal gestionale. Se un task cambia perimetro di là, qui non se ne accorge nessuno: il meccanismo continua a funzionare e a produrre identificativi sbagliati con sicurezza. È il candidato numero uno per un MCP (§8).

Due lezioni pagate

• Non avere due hook sulla stessa regola. Un hook di progetto duplicava quello globale con criteri diversi, e finiva per bloccare proprio chi la regola l'aveva seguita.
• Un guardrail vale quanto la sua porta più debole. Il ramo shell di un guardiano intercetta git push e git merge, ma non le scritture: sed -i, tee o un redirect aggirano il divieto che il ramo edit applica. La protezione c'è sulla porta principale e non sulla finestra.

Dove può andare. Gli hook non hanno test. Finché non ce l'hanno, il guardrail è una promessa.

7. Plugin e skill: capacità impacchettate, due fatte in casa

Cos'è. Il modo di impacchettare capacità riusabili. Una skill è un pacchetto di istruzioni che si attiva quando serve; un plugin ne raggruppa diverse insieme a comandi, hook e server MCP.

Com'è messo oggi. Dieci plugin abilitati: il giudice avversariale della §2, quello con le skill di processo (brainstorming, piani, TDD, debug sistematico), la review del diff fino alla variante multi-agente in cloud, due per interfacce e presentazioni, l'automazione del browser, il creatore di skill, uno che toglie i tic di scrittura dell'AI, e due scritti in casa.

I due fatti in casa meritano una riga a parte, perché arrivano da un marketplace che è semplicemente una directory locale dentro il repo di un applicativo: automatizzano il caricamento di una pratica su un portale esterno a partire dai CSV esportati dal gestionale, e la verifica che i dati caricati coincidano con quelli di partenza. È il punto in cui questa roba smette di essere infrastruttura di sviluppo e diventa lavoro d'azienda.

Dodici skill globali, nei dotfiles, che vanno dalla costruzione di un vault (§1) al modellare un dominio, dal grigliare un'idea per stressarla al ricostruire un ambiente Docker. E skill di progetto che vivono nel repo a cui appartengono, perché sono conoscenza di quel progetto e non della macchina: la più utile gestisce il cambiamento di un contratto condiviso fra due sistemi.

La regola scritta. Le skill di processo producono cerimonia — design doc, piani, gate di approvazione — e vanno invocate solo quando l'investimento si ripaga: non per interfacce in sola lettura, bugfix circoscritti, estensioni lineari o task già delimitati. Default leggero per tutto il resto. È una regola che prevale sulle istruzioni interne delle skill stesse, che tendono a proclamarsi sempre necessarie.

Dove può andare. Esiste uno strumento che misura quanto bene una skill si attiva quando dovrebbe: nessuna delle dodici è mai stata misurata.

8. MCP: le porte verso i sistemi esterni

Cos'è. Il protocollo con cui un agente parla a un sistema che esiste già fuori di lui. È la categoria che si confonde con le skill, e la distinzione è secca: una skill dice all'agente come si fa una cosa; un MCP gli dà la possibilità di raggiungere qualcosa. Istruzioni contro braccia.

Com'è messo oggi. La cosa che vale la pena sapere è che arrivano per quattro vie diverse, e una sola passa dalla mia configurazione: dichiarati a mano nel file di configurazione locale; portati dentro da un plugin; connettori autenticati sull'account, che non stanno affatto su questa macchina; e l'estensione del browser, con i permessi concessi per sito.

Il solo che ho installato davvero è quello verso un servizio di sintesi documentale, sopra la sua CLI. Non è un caso: è il metro con cui misuro una knowledge base servita da retrieval — lui le fonti le legge tutte, senza dover recuperare niente — e con l'MCP posso interrogarlo dall'agente invece che a mano, cioè confrontare i due sistemi sulla stessa domanda senza fare da tramite io.

Due avvertenze operative. I server autenticati in modo interattivo possono non esserci in esecuzioni headless o da cron: un flusso che li presuppone funziona a mano e fallisce di notte. E un MCP è per definizione una porta verso l'esterno, quindi vale la domanda che vale per ogni porta del genere — cosa esce di qui.

Dove può andare. Il candidato ovvio è il gestionale dei task: oggi la tabella che alimenta il Ref #NN è un file che mantengo a mano, ed è esattamente il genere di cosa che un MCP toglie di mezzo.

Cosa manca a questa bozza

• I costi. Nessuna delle otto voci dice quanto consuma. Per un promemoria personale può bastare; per una decisione presa da altri no.
• Il confronto sistematico fra gli strumenti che uso e le alternative. Dove scrivo che una cosa funziona meglio di un'altra, quasi sempre è un'impressione d'uso e non una misura, e ho provato a dirlo ogni volta.
• Una scaletta per chi comincia. Otto voci sono troppe in una volta, e quello che a me serve come promemoria non è quello che serve a chi parte. Se dovessi indicare da dove cominciare: la §1 e la §6 — il metodo e i guardrail — perché sono le uniche che restano vere anche cambiando strumento.