Chi finanzia una soluzione Claude non compra un modello: compra la riduzione di un costo, di un tempo o di un rischio. Il lavoro dell’architetto in questo punto del dominio è una traduzione, e la traduzione riesce solo quando il problema di partenza è già scritto in una forma che si può misurare.

Partire dal collo di bottiglia, non dalla tecnologia

Anthropic descrive così le organizzazioni che ottengono risultati: «They start with concrete business problems.» Il seguito è più utile della frase stessa. Invece di adottare l’AI per il gusto di adottarla, queste organizzazioni puntano a colli di bottiglia specifici: flussi di analisi che consumano ore di lavoro manuale, arretrati di documentazione che rallentano i lanci, onboarding che durano mesi. La seconda caratteristica è «They measure what matters», e la documentazione spiega perché conta: tracciare metriche concrete di produttività, tempo risparmiato e qualità «turns impressive demos into defensible business cases». La terza è quella che riguarda direttamente chi progetta: «They build for scale from day one. Integration, security, compliance, and trust aren’t afterthoughts.»

Da qui una regola pratica per il primo colloquio: se non riesci a nominare il processo umano che oggi assorbe il costo, non hai ancora un caso d’uso, hai un desiderio.

Il test di ammissione: è davvero un problema da LLM?

La guida al ticket routing è il punto della documentazione che affronta la domanda in modo esplicito, elencando gli indicatori per cui conviene un LLM invece del machine learning tradizionale: pochi dati etichettati disponibili (perché «Claude’s pre-trained model can effectively classify tickets with just a few dozen labeled examples»), categorie destinate a evolvere nel tempo, testo non strutturato, regole fondate su comprensione semantica, necessità di una motivazione leggibile da un umano, casi limite e ticket ambigui, supporto multilingue senza mantenere modelli separati.

Rovesciati, questi indicatori sono anche il criterio per dire di no. Se le classi sono stabili, i dati etichettati abbondanti e la decisione è puramente strutturale, un classificatore tradizionale resta più economico e più facile da difendere. La stessa guida chiede di ricostruire prima il processo esistente, con domande sui criteri di SLA, sulle regole automatiche già in campo e su dove falliscono: «The more you know about how humans handle certain cases, the better you can work with Claude to do the task.»

Scrivere «fatto» prima di scrivere il prompt

Una traduzione riuscita non produce una descrizione, produce un criterio verificabile. Sulla Managed Agents API il meccanismo è letterale: definendo un outcome, «the harness automatically provisions a grader to evaluate the artifact against a rubric», e quel grader «uses a separate context window to avoid being influenced by the main agent’s implementation choices». La guida alla rubrica dà il criterio di scrittura che vale anche fuori da quella API: preferire un criterio come «The CSV contains a price column with numeric values» a un giudizio come «The data looks good», perché «vague criteria produce noisy evaluations».

È la stessa ragione per cui le valutazioni vanno impostate presto: «Early on, evals force product teams to specify what success means for the agent.» Se lo stakeholder non sa dire quale artefatto passerebbe la rubrica, il requisito non è ancora un requisito. Una scaletta minima da portare al primo workshop:

1. processo umano attuale, con il punto in cui costa
2. criterio di accettazione, scritto come rubrica a voci indipendenti
3. soglia numerica per ogni voce, concordata con chi la firma
4. casi limite raccolti dal campo, non inventati

La soluzione più piccola che regge il carico

Il riflesso di partire dall’agente è quasi sempre sbagliato. «Building effective agents» osserva che per molte applicazioni «optimizing single LLM calls with retrieval and in-context examples is usually enough», e che «Agentic systems often trade latency and cost for better task performance»: la complessità va aggiunta solo quando le soluzioni più semplici si dimostrano insufficienti. Portata in riunione, la scala di scelta parte dalla singola chiamata con recupero ed esempi in contesto, passa per un percorso codificato e arriva all’autonomia solo dove il numero di passi non è prevedibile. Ogni gradino va giustificato con una misura, non con un’aspettativa.

Il limite da dichiarare

La documentazione Anthropic non pubblica un modello di ROI né una metodologia di discovery formale. I numeri che la guida al ticket routing propone come traguardi (accuratezza di routing, tasso di re-routing, costo per ticket) sono presentati come riferimenti di settore: «Industry benchmarks often aim for 90–95% accuracy, though this can vary based on the complexity of the support structure.» Sono un punto di partenza per la conversazione, non una misura del tuo sistema e non un impegno contrattuale. Quello che la documentazione sostiene davvero è il metodo: definire criteri «with measurable benchmarks, thresholds, and goals» insieme al team che oggi fa il lavoro, e verificarli con una valutazione prima di dichiarare il caso d’uso risolto.