C’è un punto in cui allungare il prompt smette di funzionare: le istruzioni cominciano a contraddirsi, il modello ne rispetta alcune e ne perde altre, e ogni correzione ne rompe una precedente. Quel punto segna il confine fra una chiamata sola e un flusso: più passi, ciascuno con un compito stretto, strumenti che portano dentro fatti che il modello non ha, e regole deterministiche dove la risposta non può dipendere da un’inferenza.

Quando spezzare un compito invece di allungare il prompt

Ci sono segnali abbastanza affidabili. Se il prompt contiene due verbi principali («classifica e poi riassumi») stai chiedendo due cose, e farne due passi rende il primo verificabile da solo. Se una parte dell’output deve avere una struttura rigida — un JSON con campi obbligatori, un codice preso da una lista chiusa — merita un passo dedicato con output vincolato. Se il ragionamento richiede fatti che cambiano ogni giorno, non è un problema di prompt ma di strumenti.

Spezzare ha però un costo: ogni passo aggiunge latenza, token e un punto di rottura, e gli errori si propagano a valle. La regola pratica è spezzare quando i sotto-compiti sono indipendenti o verificabili, e restare su una chiamata sola quando ogni passo dipende strettamente dal precedente e il compito è breve.

C’è anche un’alternativa allo spezzare a mano: alzare reasoning_effort su un modello di ragionamento e ottenere pianificazione interna senza catena esplicita. È più semplice da gestire ma meno osservabile, perché i passi intermedi non si ispezionano né si riparano: buono per compiti difficili e mal strutturati, meno per processi aziendali che qualcuno deve poter verificare.

Flussi aumentati dai tool: come si mantiene il controllo

Uno strumento è un contratto con il modello, e il modello vede soltanto nome, descrizione e schema dei parametri: uno strumento che non viene mai chiamato ha quasi sempre una descrizione vaga, non un difetto di codice. Nelle istruzioni dell’agente conviene scrivere a che cosa serve ciascuno strumento e che cosa fare quando una chiamata fallisce; se due strumenti si sovrappongono serve una regola di precedenza esplicita, per esempio cercare nei documenti interni prima che sul web.

Quando la scelta non può essere lasciata al caso c’è tool_choice, il controllo più deterministico disponibile: auto lascia decidere al modello, required obbliga a chiamare almeno uno strumento, none lo vieta.

Sul lato sicurezza vale una regola sola, ma pesante: gli output degli strumenti sono input non fidati. Vanno validati prima di agirci sopra, perché il testo che rientra nel contesto è il vettore classico dell’iniezione indiretta di prompt. Manda allo strumento solo i dati necessari, non mettere chiavi o token nei prompt e non registrare segreti nelle tracce.

Nel troubleshooting quattro cause coprono quasi tutto: lo strumento non è collegato all’agente; il modello non lo supporta; i dati non sono indicizzati e il recupero torna vuoto; oppure lo strumento non è disponibile in quella combinazione di modello e regione, e basta che una delle due condizioni manchi. Le tracce di esecuzione dicono se una chiamata è stata prodotta e con quali argomenti: è lì che si guarda, non nel prompt.

Più modelli insieme: router, sottoagenti e regole deterministiche

Orchestrare più modelli ha tre forme, con costi molto diversi.

La più economica è il model router: un deployment unico che sceglie il modello per ogni richiesta secondo un routing mode (Balanced di default, Cost, Quality) e un eventuale model subset. Non scrivi logica di routing e ottieni il failover automatico, ma resti vincolato alla finestra di contesto del modello sottostante più piccolo, e prima di mandarci traffico di produzione va confrontato con la baseline su qualità, costo e latenza.

La seconda è l’orchestrazione multi-agente con la Responses API (preview): il modello radice crea sottoagenti che lavorano in parallelo e ne riconcilia i risultati. Conviene quando il lavoro si divide in flussi indipendenti e limitati, quando contesti separati migliorano la messa a fuoco o quando l’esplorazione parallela riduce il tempo totale. Non conviene quando ogni passo dipende dal precedente, quando gli agenti si contendono la stessa risorsa mutabile o quando serve un grafo di esecuzione fisso e deterministico. I sottoagenti fanno crescere il consumo di token, quindi il parallelismo va limitato: max_concurrent_subagents vale 3 di default. Da ricordare anche che con l’orchestrazione multi-agente attiva non sono supportati reasoning.summary né max_tool_calls.

La terza è la più sottovalutata: LLM più regole deterministiche. Il criterio di divisione è la responsabilità di ogni fatto. Ammissibilità, tariffe, soglie, scadenze e obblighi normativi appartengono al motore di regole, perché devono essere riproducibili, verificabili e modificabili senza toccare un prompt; comprensione del linguaggio, estrazione e redazione appartengono al modello. Per non farli contraddire non si dà mai lo stesso fatto a due autorità: le regole si espongono al modello come strumenti da chiamare, invece di essere riscritte nelle istruzioni, e il loro esito vale come verifica finale sull’output generato. Se il modello dice «hai diritto al rimborso» e la regola dice di no, la regola decide e il modello spiega.

Una nota di attualità: la funzione dichiarativa Workflow di Foundry, con i pattern sequential, group chat e human-in-the-loop, è in preview e ne è annunciato il ritiro il 1° dicembre 2026, con migrazione verso Agent Framework, Logic Apps o A2A. Non è la base su cui costruire un’architettura nuova.

Da ricordare per l’esame

  • Spezza in più passi quando i sotto-compiti sono indipendenti o verificabili; resta su una chiamata sola quando ogni passo dipende dal precedente e il compito è breve.
  • tool_choice accetta auto, required e none: è il modo deterministico per obbligare o vietare l’uso degli strumenti.
  • Gli output degli strumenti sono input non fidati (è lì che passa l’iniezione indiretta), e il supporto di uno strumento richiede sia il modello sia la regione.
  • L’orchestrazione multi-agente serve a flussi paralleli e indipendenti, non a catene ordinate; aumenta i token e ha max_concurrent_subagents a 3 di default.
  • In un sistema ibrido ogni fatto ha una sola autorità: le regole decidono, il modello interpreta e spiega.