Ci chiedono di spostare un’infrastruttura AWS: un Application Load Balancer serve circa 50 virtual host e vogliamo migliorare le prestazioni. Prima, però, dobbiamo chiarire quali misure usare e quali vincoli rispettare.
Se chiediamo subito a un modello un piano completo, rischiamo di ricevere una risposta ordinata che riempie gli eventuali vuoti con ipotesi e rischia di esaurire la finestra di contesto. In questi casi conviene seguire un approccio da project manager e dividere il lavoro in task gestibili dal singolo agent, e poi orchestrare il lavoro tramite un ulteriore agent. Per prima cosa ricostruiamo lo stato attuale, poi definiamo i criteri di confronto e infine prepariamo le fasi della migrazione.
L’esempio illustra un metodo e non descrive un progetto pronto da eseguire. Architettura, configurazioni e dimensionamenti indicati negli esempi sono puramente dimostrativi.
Che vuol dire più veloce?
Possiamo voler ridurre i tempi di risposta, reggere meglio i picchi o semplificare la manutenzione. Sono obiettivi diversi e possono portare a scelte diverse. Prima di confrontare le piattaforme, dobbiamo stabilire che cosa misurare e come rilevare il risultato di partenza.
Il project manager AI parte da un brief chiaro: obiettivo, informazioni confermate, lacune e output attesi. Gli chiediamo di creare tre agent specialistici, assegnarne uno a ciascun task e coordinare il passaggio degli output. Vogliamo inoltre un report dettagliato per ogni task, così possiamo seguire il lavoro dei singoli agent e capire su quali elementi si basano i risultati. Per esempio:
<incarico ruolo="project-manager-migrazione">
<obiettivo>
Organizza la valutazione e la pianificazione della migrazione
di un servizio AWS verso una nuova infrastruttura.
</obiettivo>
<contesto>
Un Application Load Balancer serve circa 50 virtual host.
Vogliamo migliorare le prestazioni, ma non abbiamo scelto
l'architettura di destinazione né definito le misure di successo.
</contesto>
<lavoro>
Crea tre agent specialistici e assegna a ciascuno un task distinto.
Definisci per ogni task obiettivo, perimetro, input, output atteso,
dipendenze e condizioni per considerarlo completato.
<agent id="1" nome="stato-attuale">
Ricostruisci l'inventario dei circa 50 virtual host e dei servizi
da cui dipendono. Per ogni dato indica fonte e data; separa i fatti
confermati dalle ipotesi e segnala le informazioni mancanti.
Output: inventario, dipendenze e verifiche ancora necessarie.
</agent>
<agent id="2" nome="requisiti-e-alternative">
Chiarisci quali misure possono descrivere il miglioramento atteso.
Confronta le opzioni architetturali solo in base ai requisiti
confermati e all'inventario disponibile. Se i criteri di prestazione
non sono stati approvati, elenca le domande da risolvere e non
dichiarare una soluzione più veloce.
Output: criteri, alternative, compromessi e dati mancanti.
</agent>
<agent id="3" nome="piano-migrazione">
Prepara le fasi della migrazione usando lo stato verificato e
l'eventuale direzione approvata. Per ogni fase indica prerequisiti,
dipendenze, verifiche e condizioni per fermarsi o tornare indietro.
Se mancano una scelta o un'approvazione, produci un piano condizionale
e indica dove il lavoro deve attendere.
Output: piano per fasi, controlli e decisioni richieste.
</agent>
Avvia i task quando sono disponibili i rispettivi input. Se una
dipendenza non è soddisfatta, segnala il blocco e non inventare dati.
Coordina i passaggi tra gli agent e raccogli conflitti e lacune.
</lavoro>
<vincoli>
Separa i fatti dalle ipotesi e segnala i dati mancanti.
Non proporre modifiche eseguibili né inventare requisiti.
</vincoli>
<report_per_task>
Chiedi a ogni agent un report dettagliato sul task assegnato,
sia durante il lavoro sia alla consegna. Ogni report deve indicare:
task e agent responsabile; obiettivo e perimetro; input ricevuti;
attività svolte; risultati con fonti; ipotesi e lacune; stato,
dipendenze e blocchi; output consegnato e passaggio successivo.
Se un task non è iniziato o è bloccato, indica il motivo e che cosa
serve per proseguire.
</report_per_task>
<risultato>
Restituisci i tre report dettagliati e una sintesi complessiva.
Evidenzia conflitti tra i risultati, dipendenze ancora aperte
e decisioni che richiedono la nostra approvazione.
</risultato>
</incarico>
Il prompt non sceglie la soluzione ma aiuta il project manager AI a creare gli agent, assegnare i task e rendere visibili le domande ancora aperte. I report ci permettono di controllare non solo il risultato complessivo ma anche il contributo e i blocchi di ogni agent.
Tre task, tre output
Non chiediamo a tutti gli agent la stessa cosa, ma assegniamo a ciascuno un task delimitato e un output utile a chi lavora dopo.
| Task | Che cosa deve chiarire | Output |
|---|---|---|
| Stato attuale | Quali virtual host ci sono, da quali servizi dipendono e quali dati mancano? | Inventario con fonti, responsabili e verifiche aperte |
| Requisiti e alternative | Quali misure definiscono il miglioramento? Quali opzioni meritano un confronto? | Criteri, alternative e compromessi da discutere |
| Piano di migrazione | Quali fasi, verifiche e condizioni di arresto servono? | Piano condizionale con dipendenze e decisioni richieste |
Ogni agent produce un output che il successivo può controllare e usare.
Gli output devono usare riferimenti compatibili. Se l’inventario chiama un servizio in un modo e il piano ne usa un altro, il project manager chiede di riconciliare i dati prima di proseguire: un riepilogo ben scritto può chiarire i risultati, ma non risolve una discrepanza.
Quando gli output non tornano
Immaginiamo che l’agent incaricato di ricostruire lo stato attuale non trovi misure attendibili dei tempi di risposta. Quello che confronta le alternative non può sostenere che una piattaforma sia “più veloce”: può elencare le opzioni, ma deve lasciare aperto il confronto.
Il project manager registra il limite e ci chiede di scegliere una misura e una fonte. Nel frattempo, l’agent che prepara la migrazione può indicare le fasi di lavoro, ma lascia in sospeso la scelta della destinazione e i criteri di accettazione.
È qui che serve l’orchestrazione: il project manager collega gli output, ma non inventa il dato mancante per far sembrare completo il piano. Se le informazioni non bastano, restituisce una domanda precisa e indica quale decisione manca.
Chi prende le decisioni?
Il project manager AI confronta le fonti, individua contraddizioni e segnala task senza prerequisiti, ma non conosce tutte le dipendenze dell’ambiente né si assume la responsabilità del rischio operativo. Per questo verifichiamo le evidenze, approviamo le scelte e autorizziamo le modifiche.
Se gli agent non condividono uno stato o un archivio di lavoro, il project manager deve passare loro le informazioni manualmente: i prompt definiscono i task, ma non creano da soli il sistema che li collega.
Una fase non parte solo perché il task precedente è terminato: prima verifichiamo che l’output contenga le evidenze richieste e che abbiamo preso le decisioni necessarie. Se manca un prerequisito, il project manager ferma il flusso e ci chiede di chiarirlo.
Verificare il risultato
Dopo la migrazione confrontiamo le misure concordate con la situazione iniziale e registriamo interruzioni, anomalie e differenze rispetto al piano. Se il risultato non è quello atteso, chiediamo agli agent di spiegare lo scarto, ma non di piegare l’analisi alla conclusione che vorremmo.
La struttura si può riusare per altri lavori, ma task, fonti e criteri vanno ridefiniti ogni volta. Prima di aggiungere un agent, mi chiederei: che cosa deve ricevere e che cosa deve lasciare al successivo? Se input, output e punto di controllo non sono chiari, un agent in più crea altri passaggi ma non migliora il coordinamento.
Conclusioni
Per ottenere i benefici attesi (task più gestibili, passaggi di consegna verificabili e lacune visibili) dobbiamo definire bene incarichi, input, output e punti di approvazione. Stabiliamo prima quale risultato ci aspettiamo: sarà il termine di paragone per valutare quello ottenuto. La prima struttura multi-agent richiede uno sforzo di impostazione, che possiamo ottimizzare man mano che la usiamo; riutilizzandola nelle occasioni successive, evitiamo di ripetere il costo di implementazione e raccogliamo i benefici del metodo.