Un architetto senior raramente perde una gara sull’eleganza dell’architettura: la perde nella riunione in cui non sa dire perché quel taglio del problema costa quello che costa. Questa unità tiene insieme le due metà del mestiere: come si scompone un problema complesso e come si difende la scomposizione davanti a chi la finanzia.

Scegliere un pattern di scomposizione, non moltiplicare gli agenti

Anthropic separa nettamente due famiglie. I workflow sono «systems where LLMs and tools are orchestrated through predefined code paths», gli agenti sono «systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks». La differenza non è estetica: decide dove stanno i punti di controllo e quindi che cosa puoi promettere.

I pattern documentati sono cinque, più l’agente autonomo. Prompt chaining per compiti che «can be easily and cleanly decomposed into fixed subtasks». Routing quando esistono «distinct categories that are better handled separately». Parallelizzazione, per sezionamento o per voto. Orchestrator-workers per «complex tasks where you can’t predict the subtasks needed». Evaluator-optimizer quando i criteri di valutazione sono chiari e l’iterazione porta valore misurabile.

La regola di ingaggio è controintuitiva per chi vende architetture: «Try the task as a single agent call first. If that meets your quality bar, you’re done», e poi «Start with the simplest pattern that solves your problem. Default to sequential». La complessità va aggiunta «only when it demonstrably improves outcomes».

Tagliare sul contesto, non sull’organigramma

L’errore ricorrente è scomporre per tipo di attività, come si farebbe con un team di persone. Il criterio indicato è opposto: raggruppare il lavoro per requisiti di contesto condivisi. Reggono come confini i percorsi di ricerca indipendenti e le verifiche a scatola chiusa, che richiedono poco trasferimento di stato. Si rompono invece le fasi sequenziali dello stesso lavoro, i componenti strettamente accoppiati e tutto ciò che impone sincronizzazioni frequenti.

Due modi di fallire da mettere a verbale in design review: il «telephone game problem», dove l’informazione degrada nei passaggi fra agenti con contesti incompatibili, e la vittoria anticipata del verificatore, che «runs one or two tests, observes them pass, and declares success».

Il prezzo della scomposizione, in numeri portabili al CFO

Ogni divisione costa token, e la cifra va detta prima, non dopo. Le implementazioni multi-agente «typically use 3-10x more tokens than single-agent approaches for equivalent tasks». Il sistema di ricerca multi-agente di Anthropic misura il salto rispetto alla chat: «agents typically use about 4× more tokens than chat interactions» e «multi-agent systems use about 15× more tokens than chats». Da lì discende la condizione economica, ed è la frase da tenere in tasca: «multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance».

È la cerniera fra il dominio tecnico e quello del valore. Non stai scegliendo un pattern: stai dichiarando quanto vale il compito.

Tradurre l’architettura nei pilastri di valore

Ogni pattern va riespresso in una metrica che lo sponsor riconosce come sua.

Efficienza      tempo di ciclo del processo, prima e dopo
Produttività    output per persona, con il proxy dichiarato
Trasformazione  lavoro che prima non si faceva affatto
Costo           spesa per attività completata, attribuita a un workspace
Prestazioni     latenza misurata, non percepita

Nei casi pubblicati la leva più citata è il tempo di ciclo: documentazione passata da oltre dieci settimane a dieci minuti in Novo Nordisk, settanta ore la settimana risparmiate dai team di analytics di IG Group, contenuti per i siti dei concessionari compressi da settimane a consegna in giornata in Cox Automotive. Il tratto comune non è lo strumento, è la disciplina: «measure what matters», perché sono le metriche concrete a trasformare «impressive demos into defensible business cases».

Sulla produttività ingegneristica esistono metriche di contribuzione (pull request unite, codice committato, dato per utente) con un caveat da citare per intero, perché è quello che ti salva quando qualcuno lo userà contro di te: «While pull requests alone are an incomplete measure of developer velocity, we’ve found them to be a close proxy for what engineering teams care about». Sono pensate per affiancare i KPI esistenti, non per sostituirli. Sul costo, la Usage & Cost Admin API restituisce consumo e spesa raggruppabili per modello, workspace e service tier: è la base tecnica di un chargeback, non un cruscotto decorativo.

Le SLA di prestazione: che cosa la piattaforma sostiene davvero

Qui va dichiarato un limite, invece di far passare una nozione generica per documentata. Anthropic non pubblica un framework per le SLA che tu prometti ai tuoi utenti: quel numero lo firmi tu. La documentazione sostiene quattro cose diverse, tutte utili. Come si misura la latenza, con baseline latency e time to first token. L’ordine di lavoro: «It’s always better to first engineer a prompt that works well without model or prompt constraints, and then try latency reduction strategies afterward». I service tier: lo standard serve le richieste «with best-effort availability», mentre il Priority Tier «targets 99.5% uptime» ma non è più acquistabile e non copre Claude Opus 5, Claude Sonnet 5 e Claude Fable 5.1. E infine i criteri di successo misurabili, latenza e prezzo inclusi, da fissare prima di costruire. Una SLA difendibile si compone da questi elementi: non si eredita dalla piattaforma.