Un architetto senior non viene pagato per scegliere, ma per difendere la scelta davanti a chi la finanzia: perché così, quanto costa, che cosa si rompe se sbagliamo. Qui lavoriamo sui due momenti in cui quella conversazione si decide: quando presenti l’architettura e quando negozi che cosa il sistema garantisce.

Semplice per default, complesso solo se dimostrato

«Building effective agents» separa due cose che in riunione vengono confuse. “Workflows are systems where LLMs and tools are orchestrated through predefined code paths”; “Agents are systems where LLMs dynamically direct their own processes and tool usage”. Non è una sfumatura tecnica: è la differenza fra un percorso che puoi disegnare e preventivare e un sistema che decide da sé quanti passi fare.

La linea di Anthropic è esplicita: “we recommend finding the simplest solution possible, and only increasing complexity when needed”. La regola con cui si autorizza un salto di complessità è quella che porti allo sponsor: “you should consider adding complexity only when it demonstrably improves outcomes”. La parola che conta è demonstrably: senza una misura non hai un argomento, hai una preferenza. La stessa pagina mette in chiaro il prezzo: “Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense.”

Da qui esce il formato di una decisione difendibile. Non «ho scelto un’orchestrazione multi-agente», ma «ho scelto questa orchestrazione perché sul nostro traffico chiude questa quota di attività in più, e in cambio paghiamo questa latenza e questo costo».

Il costo si discute per attività completata, non per token

La guida su costo e intelligenza demolisce il confronto che gli stakeholder fanno per istinto, quello sul listino per token: “Price every candidate in cost per completed task on your own traffic”. E aggiunge il dettaglio che salva i preventivi: “Price the tail of your workload, not the median: compare models on the hardest tenth of your tasks, not the typical one.”

La stessa pagina separa le leve che non costano qualità — prompt caching, igiene dei token, il Batch API che “takes 50% off every token of a request, including cached ones” — da quelle che sono davvero uno scambio: scelta del modello, livello di effort, tetti di output, architetture multi-modello. La distinzione serve in riunione, perché la prima categoria si applica senza aprire una discussione sul rischio e la seconda no.

C’è poi un onere della prova da rispettare prima di aggiungere un secondo modello: una configurazione multi-modello “must beat the single model’s whole curve”, non solo il valore di default. E il passaggio in produzione ha una raccomandazione secca: “Run in shadow before cutover”.

Che cosa puoi davvero promettere

L’errore ricorrente è impegnarsi su un livello di servizio che la documentazione non sostiene. Tre parametri sono documentati e vanno riportati per quello che sono.

I rate limit si esprimono in richieste, token di input e token di output al minuto, sono applicati con un token bucket che si ricarica in continuo, e superarli restituisce un 429 con l’header retry-after. La frase da mettere a verbale è: “All limits described here represent maximum allowed usage, not guaranteed minimums.”

I tier di servizio: lo standard è il default e serve le richieste “alongside all other requests with best-effort availability”. Il Priority Tier “targets 99.5% uptime with prioritized computational resources”, ma la stessa pagina si apre con un avviso: “Priority Tier capacity commitments are no longer available for purchase.” Prometterlo oggi su un progetto nuovo è un impegno che non puoi mantenere.

Il ciclo di vita dei modelli è il terzo parametro, quello che gli sponsor sottovalutano: Anthropic fornisce “at least 60 days’ notice before model retirement for publicly released models”, e “Requests to retired models will fail”. Un’architettura che inchioda un identificativo di modello nel codice ha una data di scadenza.

Il limite dichiarato: nella documentazione qui ammessa non esiste un contratto di SLA. Ciò su cui puoi impegnarti sono i parametri operativi qui sopra più il comportamento che il tuo sistema costruisce sopra di essi: retry, degradazione, fallback. Presentarli come uno SLA del fornitore sarebbe scorretto.

Il ciclo di feedback che tiene allineate le attese

Un allineamento senza misura dura una settimana. La guida sugli eval indica il punto di partenza — “Start early and don’t wait for the perfect suite. Source realistic tasks from the failures you see” — con qualche decina di compiti presi da bug reali, e ricorda che un giudice-modello va calibrato: “LLM-as-judge graders should be closely calibrated with human experts”. Le metriche pass@k e pass^k dicono cose diverse, almeno un successo su k tentativi contro tutti i k, e si scelgono in base a quanto costa l’errore.

Sul versante adozione, il cruscotto di Claude Code dichiara da solo il proprio limite: le sue metriche “are deliberately conservative and represent an underestimate”. Portarle in riunione come stima prudente ti rafforza; spacciarle per misura esatta ti espone.

Resta il modo di far crescere le attese nel tempo: “Teams at Anthropic grant agents autonomy in proportion to demonstrated reliability, then expand it deliberately.” È anche la forma migliore di roadmap per uno steering committee: non date, ma soglie di affidabilità superate le quali l’ambito si allarga.