Orchestrazione multi-agent: cinque pattern e quando ne vince uno

Un’azienda portoghese scrive riguardo alla fattura FT-2026-0918. L’email dice che l’IVA sembra sbagliata e allega la fattura: imponibile EUR 248,00, IVA addebitata al 21 %, EUR 52,08, totale EUR 300,08.

I fatti necessari per rispondere vivono in tre posti, e solo uno è nell’email:

Mettili insieme e la fattura è sbagliata: si applica il reverse charge, l’IVA avrebbe dovuto essere zero, è dovuta una nota di credito da EUR 52,08. Guarda solo la fattura ed è aritmeticamente perfetta — 248,00 più 52,08 fa 300,08 — e dirai così.

L’email afferma: «siamo un’azienda portoghese». È un’affermazione, non un record, e nessun sistema di fatturazione emette una nota di credito sulla base di un’affermazione. La trappola non è un trucco: è la forma ordinaria del lavoro aziendale, in cui la decisione richiede un fatto che nessuno ha pensato di recuperare.

Tutto quanto sopra gira contro un provider scriptato nello stile di quello del Capitolo 23, con una sola regola:

Una risposta può usare solo un fatto presente nel suo prompt.

Il «modello» chiede ogni strumento che ha, una volta, nell’ordine del catalogo, poi applica una regola fissa al testo che può vedere. Niente è scriptato per singola configurazione, quindi le differenze nella tabella iniziale non sono affermazioni sull’intelligenza del modello: sono information routing, misurato. Un modello reale aggiunge i propri errori sopra; non li rimuove.

I cinque nomi qui sotto sono di Anthropic, da Building effective agents, che è il punto in cui questo vocabolario si è stabilizzato.¹ Nessuna delle cinque idee è nuova, e dire quale casa ha dato nome a cosa — e quale idea è più vecchia — è metà del valore di conoscerle.

/* 1. Prompt chaining: a fixed pipeline. The control flow is yours. */
export async function chain(steps: Step[], first: string) {
  let carry = first, all = first;
  for (const s of steps) {
    const r = await step(s.role, s.system, s.accumulate ? all : carry);   
    carry = r.text;
    all = `${all}\n${r.text}`;
  }
  return carry;
}

/* 2. Routing: one cheap call picks the branch. The fallback is not a model. */
export async function route<T>(input: string, classify: Classifier,
                               routes: Record<string, Branch<T>>, fallback: Branch<T>) {
  let label: string | undefined;
  try { label = await classify(input); } catch { label = undefined; }
  return ((label && routes[label]) || fallback)(input);                    
}

/* 3. Parallelisation. The pattern IS this line. */
export const parallel = <T>(workers: Branch<T>[], input: string) =>
  Promise.all(workers.map((w) => w(input)));                              

/* 4. Orchestrator-workers: an agent behind a tool. Chapter 18's interface, unchanged. */
export function agentTool(o: WorkerSpec): Tool {
  return {
    name: o.name, description: o.description, readOnly: true,
    parameters: { type: "object", properties: { question: { type: "string" } } },
    async run(args: { question: string }) {
      const child = newRun(o.system, args.question);          // its own window
      await runTracked(child, o.tools, o.usage);              // its own limits
      const conclusion = child.output ?? "no result";
      if (!o.carryFindings) return conclusion;                             
      return `${conclusion}\nFINDINGS ${evidence(child)}`;                 
    },
  };
}

/* 5. Evaluator-optimiser: make, judge, remake. Rounds are calls. */
export async function refine(make: Make, judge: Judge, maxRounds: number) {
  let draft = "", feedback: string | undefined;
  for (let r = 1; r <= maxRounds; r++) {
    draft = (await make(feedback)).text;
    const j = await judge(draft);
    if (j.ok) return { draft, rounds: r };
    feedback = j.note;
  }
  return { draft, rounds: maxRounds };
}

È tutto il toolkit: cinque funzioni, nessun framework, e quella parallela è una singola riga — che è il motivo per cui vale la pena scriverla invece di disegnarla. Ora ciascuna a turno, con la sua genealogia, il suo prezzo e il caso in cui sbaglia.

Il prompt chaining «scompone un compito in una sequenza di passaggi, in cui ogni chiamata LLM elabora l’output della precedente».¹ L’idea precede i modelli linguistici: è una pipeline, con lo scambio tipico della pipeline — chiarezza in cambio di un flusso di controllo fissato prima che arrivino i dati.

Quattro passaggi per il nostro compito: estrarre i campi della fattura, controllare l’aritmetica, decidere che cosa è dovuto, scrivere la risposta. Qui fallisce in due modi diversi, il che insegna più di un singolo fallimento.

--- relay: each step sees only the previous step's output
extract: FIELDS invoice_id=FT-2026-0918 net=248.00 vat_rate_applied=21 vat_amount=52.08 ...
check:   ARITHMETIC ok 248.00+52.08=300.08
decide:  VERDICT=unknown reason=no_invoice_in_context
draft:   "we are looking into invoice FT-2026-0918 and will come back to you."

--- accumulating: each step sees the email and everything produced so far
extract: FIELDS invoice_id=FT-2026-0918 net=248.00 vat_rate_applied=21 ...
check:   ARITHMETIC ok 248.00+52.08=300.08
decide:  VERDICT=invoice_correct reason=net_248.00_plus_21pct_vat_52.08_equals_300.08
draft:   "we have checked FT-2026-0918 and it is correct... Nothing is owed back."

La catena relay è costata $0.001940 e ha perso i campi della fattura tra il secondo e il terzo passaggio, perché al terzo passaggio è stata passata una frase sull’aritmetica e nient’altro. Ha prodotto un messaggio di attesa: inutile, e visibilmente inutile.

La catena accumulativa — la riga nella tabella iniziale — è costata $0.003780, cioè il 95 % in più per quattro chiamate identiche, perché ora ogni passaggio porta con sé tutto ciò che lo precede. Ha prodotto l’output pericoloso. Fluido, con citazione della sua aritmetica, corretto su ogni numero che menziona, e dice al cliente che non è dovuto nulla quando sono dovuti EUR 52,08.

La differenza tra le due è un ternario. Una chain che porta meno produce risposte ovviamente incomplete; una chain che porta tutto produce risposte sicure e sbagliate — e solo il secondo tipo viene inviato.

Nessuna delle due è il vero fallimento. Il vero fallimento è che la pipeline ha deciso, prima di leggere qualunque cosa, che questo compito è composto da quattro passaggi sul contenuto di un’email. In quella struttura non c’è nessun posto per dire «il paese di registrazione non è in questa email; vai a recuperarlo». Il chaining è giusto quando la scomposizione è nota in anticipo e stabile. Qui era un’ipotesi, e l’ipotesi è partita.

Il routing «classifica un input e lo indirizza a un compito successivo specializzato».¹ Il nome è nuovo; il meccanismo è il dispatcher, più vecchio di quasi tutto il resto in questo libro. La novità è che il classificatore può essere un modello — ed è questo che lo fa fallire in modi in cui un switch non ha mai fallito.

const answer = await route(email,
  (q) => classifyWithSmallModel(q),          // cheap model, one call
  { billing: billingAgent, tax: taxAgent, dunning: dunningAgent },
  taxAgent,                                  // deterministic, chosen in advance
);

Due cose su quell’ultimo argomento. Non è gestione degli errori; è il pattern. Un router basato su modello ha una modalità di errore che un dispatcher non ha: può restituire un’etichetta che non esiste, andare in timeout, oppure — il caso costoso — restituire un’etichetta plausibile ma sbagliata senza alcun segnale che sia sbagliata. Tutte e tre devono atterrare da qualche parte, e quel da qualche parte non può essere un’altra chiamata al modello, perché sei già nel ramo in cui le chiamate al modello hanno fallito.

La seconda cosa è che il prompt del router non è gratis. Per scegliere un modello, un router ha bisogno di un catalogo di modelli tra cui scegliere, e ogni voce del catalogo è input che il router paga prima di aver letto la domanda dell’utente. Alla tariffa di input con cui questo corso calcola i prezzi, un catalogo di circa 3.800 token costa già quanto l’intera esecuzione dell’agent a cinque chiamate nella tabella iniziale. In pratica la chiamata di routing gira su un modello economico, ed è proprio questo il motivo per cui il routing si ripaga; ma vale la pena fare il conto in quella direzione invece di darlo per scontato. Il routing è sbagliato proprio quando il compito instradato costa meno della decisione di routing.

Anthropic divide questo pattern in due: sectioning — «spezzare un compito in sottocompiti indipendenti eseguiti in parallelo» — e voting — «eseguire lo stesso compito più volte per ottenere output diversi».¹ Condividono un diagramma e quasi nient’altro.

Il sectioning è la vittoria economica, ed è la riga da patterns.ts: tre specialisti — fatturazione, fiscalità, policy — ciascuno con la propria finestra e i propri strumenti, sulla stessa email, con una chiamata di sintesi alla fine. Stesso lavoro, ordinato in due modi:

Stesso token per token, 1,8 volte più veloce. Ecco perché il pattern si guadagna un nome proprio: è l’unico dei cinque che migliora qualcosa senza costare nulla. Il punto è che le sezioni devono essere davvero indipendenti — dai alla sezione B un fatto prodotto dalla sezione A e Promise.all le esegue entrambe contro uno stato che non esiste ancora. Il loop for nascondeva quel bug; la riga singola lo espone.

Il voting è un animale diverso che indossa la stessa immagine. Eseguire la stessa domanda k volte e prendere la maggioranza è self-consistency, pubblicata da Wang et al. nel marzo 2022 come strategia di decoding, quasi tre anni prima che qualcuno la chiamasse pattern di orchestrazione. Il suo abstract è preciso sul meccanismo — «prima campiona un insieme diversificato di percorsi di ragionamento invece di prendere solo quello greedy, poi seleziona la risposta più consistente marginalizzando i percorsi di ragionamento campionati» — e sul guadagno: +17,9 punti su GSM8K.²

Ne seguono due cose che l’immagine nasconde. Primo, il voting richiede il sampling del Capitolo 17: a temperatura zero tutti i k campioni sono lo stesso campione, e la maggioranza è una risposta pagata k volte. Secondo, funziona solo dove una maggioranza ha senso — sulla risposta alla fattura qui sopra non c’è nulla da contare, perché cinque bozze sono cinque frasi diverse. Il voting è per compiti con una risposta breve e comparabile, esattamente i benchmark di Wang e quasi nulla di ciò che fa un agent rivolto ai clienti.

Misurato qui su 20 problemi verbali in tre passaggi le cui risposte sono calcolate invece che giudicate, con il modello locale del Capitolo 23 che ragiona passo per passo:

Cinque volte le chiamate, cinque volte i token, esattamente cinque volte il conto, e nemmeno una risposta corretta in più. Il voting è una scommessa, non un miglioramento, e questa run l’ha persa.

Due cautele, prima che qualcuno lo citi come confutazione di Wang. Venti prove non possono distinguere il 45 % dal 60 % — l’intervallo è largo quanto l’affermazione, cioè la disciplina del Capitolo 4 applicata al mio stesso risultato. E i guadagni pubblicati arrivano da modelli di ordini di grandezza più grandi, dove i percorsi di ragionamento diversi su cui il voting marginalizza sono davvero diversi. Ciò che si trasferisce non è il numero: è che il moltiplicatore è esatto e noto in anticipo, mentre il guadagno non lo è.

Nel workflow orchestrator-workers «un LLM centrale scompone dinamicamente i compiti, li delega a worker LLM e sintetizza i loro risultati», e la differenza rispetto al sectioning è che «i sottocompiti non sono predefiniti, ma determinati dall’orchestrator».¹ La genealogia qui non viene affatto dai modelli linguistici: è master-worker, e la versione in cui i worker scrivono risultati in uno spazio condiviso che un controller legge è la blackboard architecture, nata nella ricerca sul riconoscimento vocale negli anni Settanta. La novità nel 2026 è che il controller è un modello e quindi la scomposizione può essere decisa per input — cioè flessibilità e costo in una sola frase.

È costato 12 chiamate al modello contro le 5 del singolo agent, e ha raggiunto lo stesso verdetto. Poi ha fatto qualcosa che vale la pena guardare da vicino:

orchestrator final: VERDICT=credit_note_due amount=52.08 source=worker_unverified
                  | PO_MISMATCH=yes source=worker_unverified
single agent:       VERDICT=credit_note_due amount=52.08 reason=reverse_charge_should_have_applied
                  | PO_MISMATCH=yes invoice_says=PO-4417 order_says=PO-4471

Entrambi hanno ragione. Solo uno sa perché. Il worker fiscale aveva la fattura, l’ordine e la tabella fiscale nella propria finestra, è arrivato alla conclusione, e ha anche notato — nessuno glielo aveva chiesto — che il numero d’ordine di acquisto sulla fattura non corrisponde a quello dell’ordine. Poi ha restituito un riassunto. L’orchestrator può ripetere entrambe le affermazioni e verificarne nessuna, perché l’evidenza è rimasta in una finestra che non ha mai visto. Questa è la domanda finale del Capitolo 24, con la risposta: il genitore può guardare qualunque cosa il child abbia scelto di scrivere.

La correzione è un flag, e ha un prezzo:

Dodici per cento in più di token di input, 8,3 % in più di denaro, e la frase source=worker_unverified sparisce dalla risposta. Questo è lo scambio in ogni sistema multi-agent e non viene quasi mai dichiarato: la finestra pulita del child vale la pena, la capacità del genitore di auditarla vale il prezzo, e non puoi avere entrambe gratis.

Allora quando è sbagliato orchestrator-workers? Qui, su questo compito. Ha comprato una risposta corretta che anche un agent con gli stessi quattro strumenti ha raggiunto, per 1,66 volte il costo e 2,3 volte il wall clock, e ha reso quella risposta più difficile da difendere. La stessa guida di Anthropic lo dice prima che inizino i pattern: trovare «la soluzione più semplice possibile, aumentando la complessità solo quando serve», perché «i sistemi agentic spesso scambiano latenza e costo con migliori prestazioni del compito».¹ Le tabelle sopra sono quella frase con dei numeri sotto.

Una chiamata genera, un’altra valuta, e il loop si ripete finché la valutazione passa.¹ Gli antenati pubblicati sono Self-Refine — lo stesso modello come «generator, refiner, and feedback provider», con circa 20 punti di miglioramento assoluto medio su sette compiti³ — e Reflexion, che memorizza la critica in un buffer episodico tra i tentativi e riporta 91 % pass@1 su HumanEval dove la baseline raggiungeva l’80 %.⁴

Il modello di costo è il più semplice dei cinque: due chiamate per round, e il numero di round non è tuo. Tre round di refinement su un compito che richiedeva una chiamata sono sei chiamate, quindi il floor del pattern è 6× e il ceiling è qualunque cap tu imposti — il che rende l’uscita per budget del Capitolo 23 obbligatoria, non ordinata per eleganza.

Il ceiling è più sottile, ed è misurabile. Sugli stessi 20 problemi il modello locale ha risposto correttamente a 9. Poi gli è stata mostrata ciascuna di quelle risposte e gli è stato chiesto se fosse giusta — senza dirgli che la risposta era sua, il che rimuove il confondente della lusinga e lascia quello della capacità:

È un giudice migliore di quanto implichi il titolo della sezione, e dirlo è il punto del misurare invece di affermare: non ha bloccato nulla di corretto e ha colto 8 errori su 11. Come filtro, vale le sue chiamate.

Come regola di arresto, che è l’uso effettivo di un loop evaluator-optimiser, quelle tre approvazioni sono tutta la storia: chiudono il loop con una risposta sbagliata in mano, e nessun numero di round extra le raggiungerà mai. Un loop di refinement non può diventare più corretto del suo giudice. Comprare più round compra tentativi sugli errori che il giudice può vedere, a prezzo pieno, e nulla contro quelli che non può vedere.

Quindi la regola: un evaluator si guadagna le sue chiamate solo quando ha qualcosa che il generator non ha. Un compilatore, una suite di test, un validatore di schema, un modello diverso, un umano. I risultati di Self-Refine sono misurati contro preferenze umane e metriche di compito, mai contro l’opinione del modello su se stesso. Se l’unico vantaggio del tuo evaluator è un prompt diverso, stai pagando il doppio per un accordo. Il Capitolo 29 costruisce la versione con un vero vantaggio: un golden set con le risposte scritte in anticipo.

I cinque sopra sono forme per il tuo codice. Sotto di loro c’è una seconda famiglia che spesso viene elencata accanto a essi e non dovrebbe esserlo: ReAct, Reflexion, plan-and-execute e tree of thoughts sono reasoning loop, e il loro costo è in richieste.

Il Capitolo 12 parlava del reasoning dentro il modello, che paghi in token di output su una chiamata. Questo è l’altro tipo. La differenza conta quando arriva il conto: una chain of thought più lunga rende una chiamata più costosa, e un reasoning loop trasforma un compito in molte chiamate, ciascuna delle quali reinvia tutto ciò che la precede — il quadratico misurato dal Capitolo 23 nella sua tabella runaway.

Il paper su tree of thoughts pubblica la propria tabella dei costi, cosa più rara di quanto dovrebbe essere. Su Game of 24 con GPT-4: input/output prompting best-of-100 risolve il 33 % a $0.13 per caso, chain of thought best-of-100 risolve il 49 % a $0.47, e tree of thoughts risolve il 74 % a $0.74, con gli autori che notano che «potrebbe richiedere 5-100 volte più token generati rispetto a CoT».⁷

Quasi sei volte il prezzo del metodo economico per poco più del doppio del tasso di successo. Che sia un affare dipende da quanto ti costa un caso fallito — la domanda da fare prima di adottare uno qualunque di questi quattro.

Questo corso non li reimplementa. Tutti e quattro hanno implementazioni di riferimento dei loro stessi autori, in Python, e il loro valore sta nell’essere la fonte invece di una traduzione: ysymyth/ReAct, noahshinn/reflexion, princeton-nlp/tree-of-thought-llm e AGI-Edgerunners/Plan-and-Solve-Prompting. Leggi i prompt in quei repository; i prompt sono i paper.

Ora il vero multi-agent, dove vive gran parte della confusione. Ci sono due modi in cui un agent può coinvolgerne un altro, non sono varianti, e la differenza è chi comanda dopo.

Agent come strumento. Il genitore lo chiama, riceve una risposta e continua. È l’interfaccia strumento del Capitolo 18 con un intero agent dietro, e il genitore non perde mai il controllo. È quello che fa l’orchestrator sopra.

Handoff. Il genitore trasferisce la conversazione e non la riottiene. La guida di OpenAI è la formulazione pubblicata più chiara: gli handoff sono «un trasferimento unidirezionale che consente a un agent di delegare a un altro agent... Se un agent chiama una funzione di handoff, iniziamo immediatamente l’esecuzione sul nuovo agent a cui è stato fatto handoff, trasferendo anche lo stato più recente della conversazione».⁸

Un avviso di vocabolario, perché questo fa inciampare continuamente: «handoff» è la parola di un SDK, non uno standard. È terminologia dell’OpenAI Agents SDK e di quella guida, che chiama anche le due configurazioni «manager» e «decentralized» e nota che nel pattern manager «gli archi rappresentano tool calls mentre nel pattern decentralized gli archi rappresentano handoffs».⁸ In questo spazio esiste uno standard aperto — A2A, alla versione 1.0.0, sotto copyright della Linux Foundation, con una cronologia delle release versionata e una lista documentata di breaking changes, il cui principio dichiarato è opaque execution: gli agents «collaborano in base a capacità dichiarate e informazioni scambiate, senza dover condividere i propri pensieri interni, piani o implementazioni degli strumenti».⁹ Non è un handoff, e il confronto appartiene al Capitolo 26. Qui conta che una delle due parole sia l’API di una libreria e l’altra una specifica con governance.

La distinzione è una struttura dati, non un diagramma:

export type EdgeKind = "tool" | "handoff";
export interface AgentEdge { from: string; to: string; kind: EdgeKind }
export interface AgentGraph { root: string; agents: Record<string, AgentSpec>; edges: AgentEdge[] }

/** One agent may not be both a tool of X and a handoff target of X. */
export function conflicts(g: AgentGraph): AgentEdge[] {
  const seen = new Map<string, EdgeKind>();
  const bad: AgentEdge[] = [];
  for (const e of g.edges) {
    const key = `${e.from}->${e.to}`;
    const other = seen.get(key);
    if (other && other !== e.kind) bad.push(e);                            
    else seen.set(key, e.kind);
  }
  return bad;
}

/** Every agent reachable from the root, and at what depth. */
export function reachable(g: AgentGraph): Map<string, number> {
  const depth = new Map([[g.root, 0]]);
  const queue = [g.root];
  while (queue.length) {
    const id = queue.shift()!;
    for (const e of g.edges.filter((x) => x.from === id)) {
      if (depth.has(e.to)) continue;
      depth.set(e.to, depth.get(id)! + 1);
      queue.push(e.to);
    }
  }
  return depth;
}

Venti righe, due bug che altrimenti troveresti in produzione. reachable trova l’agent che nessuno può raggiungere — configurato, pagato, mai chiamato. conflicts rifiuta l’arco che è entrambi i tipi insieme, cosa che suona pedante finché non la leggi ad alta voce: il genitore mantiene il controllo e lo cede allo stesso tempo. Eseguilo su un sistema a cinque agent con un orfano e un arco doppio:

reachable: lead@0 billing@1 tax@1 dunning@1
orphans:   ghost
conflicts: lead->tax

Ora la misurazione per cui esiste questa sezione, e l’unica del capitolo presa contro un modello reale invece che scriptato.

Un cliente dichiara un vincolo nel primo messaggio — il nostro account è registrato in Portogallo, non in Spagna; tutto ciò che riguarda le tasse deve usare il Portogallo — parla d’altro, poi fa una domanda a cui deve rispondere billing. Il caso viene trasferito. Ventiquattro prove, un paese e un’azienda diversi ogni volta, quattro payload di trasferimento, e poi all’agent ricevente viene fatta una sola domanda: in quale paese è registrato l’account di questo cliente?

La terza riga è un controllo e si comporta come tale: il fatto non c’è, quindi non può essere ricordato. Le altre tre sono il risultato.

La trascrizione completa è di 173 token e funziona l’83 % delle volte, con quattro fallimenti che sono il tema del Capitolo 24 più che di questo. Il record tipizzato è 69 token — sette più del riassunto — e funziona ogni volta, perché il vincolo sta in un campo nominato invece che in una frase.

E il riassunto è la riga da fissare. Ha fallito 24 volte su 24, e il motivo non è che il lettore se lo sia perso. Il vincolo compariva soltanto in 1 dei 24 riassunti. L’agent ricevente non è stato distratto; gli è stato passato un testo che non conteneva la risposta. Un riassunto è una compattazione che non hai scritto, prodotta da un modello di cui non puoi vedere la finestra, ottimizzata per sembrare un riassunto — e «il cliente dice che i nostri record hanno il paese sbagliato» è esattamente il tipo di clausola che un summariser elimina come rumore procedurale.

Un limite onesto su quel numero: il summariser è un modello da mezzo miliardo di parametri e uno più grande ne conserverebbe di più. Ciò che non migliora con la dimensione è la forma del rischio — l’agent mittente decide, per handoff, per formulazione, in modo non osservabile, quali fatti sopravvivono. Il record tipizzato non dipende affatto da quel giudizio, ed è per questo che vince per costruzione invece che per intelligenza. Qualunque cosa debba sopravvivere a un trasferimento dovrebbe essere un campo, non una frase.

Lo stesso ragionamento vale nella direzione opposta, per la topologia agent-as-tool, e la tabella precedente ne ha già dato il prezzo: ciò che torna da un worker è anch’esso un riassunto, e pagare l’8,3 % in più per ricevere anche l’evidenza è la stessa correzione vista dal lato del genitore.

Tre fatti conclusivi, tutti dalle tabelle sopra.

Un sistema multi-agent moltiplica le chiamate, e le chiamate sono quadratiche nel contesto. L’orchestrator ha fatto 12 chiamate al modello dove un agent ne ha fatte 5, e ciascuna porta la propria trascrizione crescente — 3.628 token di input contro 2.697, un divario che cresce con la lunghezza del compito.

Ogni confine è un canale con perdita. Due agents significano un riassunto. Quattro agents in una catena significano tre, composti, ciascuno scritto da un modello che ottimizza per qualcosa di diverso dalla tua decisione.

Il singolo agent ha trovato qualcosa che nessuno aveva chiesto. La discordanza del numero d’ordine di acquisto è emersa perché una finestra conteneva insieme la fattura e l’ordine. Dividere il lavoro tra specialisti divide anche la capacità di notare che due fatti non concordano.

Niente di tutto questo è un argomento contro i framework multi-agent pubblicati, che vale la pena leggere come fonti primarie invece che tramite tutorial.¹⁰ È un argomento per far guadagnare al secondo agent il suo posto.

Quindi, un test invece di una preferenza. Aggiungi un secondo agent quando almeno una di queste cose è vera: il sub-task ha bisogno di una finestra pulita che il genitore non deve ereditare (Capitolo 24); i sub-task sono davvero indipendenti e il wall clock conta, cioè l’1,8× sopra; il sub-task richiede permessi diversi o un modello diverso, cosa che il Capitolo 30 trasforma in un argomento di sicurezza; oppure il sub-task è di proprietà di qualcun altro, che è il punto in cui un vero protocollo inizia a contare. Se la risposta è «così ogni agent ha un prompt più chiaro», dai all’unico agent un prompt più chiaro. È gratis.

Ora sai nominare i cinque pattern, prezzarli uno contro l’altro su un compito, distinguere un orchestrator da un sectioner e una chiamata strumento da un handoff, e difendere un singolo agent con una tabella invece che con una preferenza.

Ogni configurazione qui condivideva una comodità che non sopravviverà al contatto con qualcosa di reale: tutti gli strumenti appartenevano a noi. Fattura, ordine, tabella fiscale, i worker dietro l’orchestrator — stesso repository, stesso deploy, stessi tipi, stesse persone.

Ora mettine uno dall’altra parte di un confine aziendale. La tabella fiscale appartiene a un fornitore contabile, il record dell’ordine a un sistema di magazzino, e nessuno dei due ha letto la tua interfaccia Tool. Ti serve un modo perché un modello che non hai scritto scopra, descriva e chiami una capability gestita da qualcun altro — con autenticazione (che è la metà del Capitolo 27), versioning, e la garanzia che un server non possa leggere il resto della tua conversazione. È un problema di protocollo, ha una specifica con uno schema normativo, e quasi tutto ciò che è indicizzato su di esso descrive una revisione che non esiste più.

Il Capitolo 26 legge quella specifica invece di riassumerla, e comincia digitando JSON-RPC in un terminale a mano.

Ogni costo e conteggio di token qui sopra viene dal provider scriptato descritto nella seconda sezione, su Node 22 attraverso un’interfaccia loopback, contando con l’encoding o200k_base e prezzato alle tariffe lette dal Capitolo 16 il 6 settembre 2026 — $2.00 per milione di token di input e $12.00 per milione di output. Le cifre di wall-clock vengono dalle stesse run con latenza del provider impostata a 400 ms per chiamata e strumenti a 50 ms, quindi misurano la configurazione invece del provider. Le due misurazioni su modello reale — la tabella handoff e la tabella voting-and-judging — hanno usato Qwen/Qwen2.5-0.5B-Instruct in float32 sulla CPU dietro un endpoint della stessa forma, greedy tranne dove è indicata una temperatura, con intervalli calcolati con il metodo di Wilson del Capitolo 4. Nessuna richiesta in questo capitolo è andata a un endpoint a pagamento, e nessun numero è stato stimato.