Prima di scegliere conviene fissare cosa distingue le due architetture, perché il confine non è la complessità e nemmeno il numero di chiamate al modello.

Chi decide il percorso

La pagina Building effective agents raccoglie entrambe sotto la categoria agentic systems e poi le separa così: «Workflows are systems where LLMs and tools are orchestrated through predefined code paths», mentre «Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks».

Il discriminante è la titolarità del percorso, non la sua lunghezza. Una pipeline che incatena dodici chiamate — estrai, classifica, arricchisci, riassumi, verifica — resta un workflow anche se costa più di un agente: il grafo vive nel tuo codice e sai in anticipo quali nodi verranno attraversati. Un loop tool-use che gira finché il modello smette di chiedere tool è già un agente, anche se in media chiude in tre turni, perché quante iterazioni servano lo decide lui.

Da qui discende il resto dell’ingegneria. Un workflow si testa nodo per nodo, ha un costo a varianza stretta e fallisce in punti che hai già nominato. Un agente ha un costo che dipende dall’input, e i suoi limiti vanno messi a mano — tetto ai turni, tetto alla spesa — perché non esistono per costruzione.

Il criterio operativo

Il test pratico è uno: riesci a disegnare il grafo dei passi prima di vedere l’input? Se sì, scrivilo in codice. La raccomandazione ufficiale dice che «workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale». Il dominio proprio degli agenti è dichiarato con la stessa nettezza: «Agents can be used for open-ended problems where it’s difficult or impossible to predict the required number of steps, and where you can’t hardcode a fixed path».

Vale la pena notare che la stessa pagina invita a considerare l’ipotesi zero, cioè non costruire niente di agentico: per molte applicazioni basta ottimizzare una singola chiamata con retrieval ed esempi in-context, e i sistemi agentici scambiano latenza e costo per qualità del risultato. Le due strade poi non sono alternative secche. La forma più comune in produzione è un workflow deterministico con un nodo agentico dentro: il triage di un ticket è routing e va scritto in codice, la riparazione del bug che ne esce è open-ended e va lasciata a un agente.

Gerarchie manager e supervisor

Quando il lavoro va scomposto ma la scomposizione dipende dall’input, il pattern di riferimento è orchestrator-workers: «In the orchestrator-workers workflow, a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results».

La differenza rispetto alla parallelizzazione è sottile e viene sbagliata spesso, perché le due topologie si assomigliano. Nella parallelizzazione i sottotask li definisci tu e li lanci insieme; nell’orchestrator-workers è il modello centrale a stabilire a runtime quali e quanti sottotask esistono. Il blog di Anthropic sui pattern di coordinamento chiama orchestrator-subagent la variante agentica, in cui un lead agent pianifica e delega compiti circoscritti a specialisti e poi ne sintetizza i risultati.

manager / lead agent
  decide a runtime quanti e quali sottotask servono
  delega a worker o subagenti, un prompt circoscritto ciascuno
  riceve i soli risultati e li sintetizza in un output unico

Subagenti, e i tre modi di sbagliare

Un subagente non è semplicemente un altro agente: è un’unità di isolamento. I benefici dichiarati sono quattro. Contesto isolato, perché le chiamate intermedie restano dentro e al padre torna solo il messaggio finale. Parallelizzazione, perché sottotask indipendenti finiscono nel tempo del più lento invece che nella somma. Istruzioni specializzate, che nel prompt principale sarebbero rumore. Restrizione dei tool: un revisore definito con soli Read, Grep e Glob non ha gli altri in sessione, quindi non serve un permesso a fermarlo.

Gli errori che costano davvero sono tre.

Il primo è partire multi-agente. «In our testing, multi-agent implementations typically use 3-10x more tokens than single-agent approaches for equivalent tasks», e l’extra viene dalla duplicazione del contesto, dai messaggi di coordinamento e dai riassunti a ogni passaggio di consegne. Prima di aggiungere agenti, prova a migliorare il prompt di uno solo.

Il secondo è scomporre per tipo di lavoro. La regola è l’opposto di quella istintiva: «Group work by what context it requires, not by what kind of work it is». Un agente pianificatore più un agente esecutore che lavorano sullo stesso materiale perdono contesto a ogni handoff; due agenti che leggono corpora diversi no.

Il terzo è mettere un agente dove il percorso è noto: paghi non-determinismo e turni in più per una libertà che non ti serve.

La regola di chiusura è la stessa che conviene portare all’esame: «Start with the simplest approach that works, and add complexity only when evidence supports it».