Serve davvero un agente?

Un agente che sceglie da solo il prossimo passo può essere utile. Ma se i passi sono già noti, quella libertà aggiunge variabilità, costo e superficie di errore. La prima decisione tecnica è scegliere quanta autonomia concedere.

Una matrice prima del framework

La scelta si può rendere esplicita in una matrice. Non è un classificatore universale: serve a costringere il team a dichiarare le condizioni in cui un pattern è ammesso.

Il codice sotto riceve un Task già classificato da logica applicativa affidabile. Non chiede al modello di autovalutare il proprio rischio.

from dataclasses import dataclass
from enum import Enum

class Path(Enum):
    WORKFLOW = "workflow"
    BOUNDED_AGENT = "bounded_agent"
    HUMAN_REVIEW = "human_review"

@dataclass(frozen=True)
class Task:
    steps_known: bool
    writes_external_state: bool
    risk: str  # assigned by trusted application logic

def choose_path(task: Task) -> Path:
    if task.risk not in {"low", "high"}:
        raise ValueError("unknown risk level")
    if task.writes_external_state or task.risk == "high":
        return Path.HUMAN_REVIEW
    if task.steps_known:
        return Path.WORKFLOW
    return Path.BOUNDED_AGENT

assert choose_path(Task(True, False, "low")) is Path.WORKFLOW
assert choose_path(Task(False, False, "low")) is Path.BOUNDED_AGENT
assert choose_path(Task(False, True, "high")) is Path.HUMAN_REVIEW

Esempio eseguibile: la funzione sceglie il percorso, non implementa un agente. La classificazione del rischio, l'autorizzazione e l'esecuzione restano responsabilità separate.

Cosa significa “agente limitato”

Se il percorso è variabile, l'agente non dovrebbe ricevere accesso indiscriminato ai tool. Definirei almeno una allowlist di strumenti, uno schema validato per gli argomenti, limiti di iterazioni e costo, timeout e una condizione di uscita. Per un'azione con effetti esterni aggiungerei un gate applicativo e, dove necessario, approvazione umana.

Il test che farei per primo

Preparerei casi con lo stesso obiettivo ma caratteristiche diverse: passaggi noti, informazione mancante, richiesta di scrittura, rischio alto. Il test non deve soltanto controllare la risposta: deve verificare che ciascun caso venga indirizzato al percorso previsto e che un input sconosciuto fallisca in modo esplicito.

Nel libro sviluppo queste scelte insieme ai pattern di orchestrazione: dal Prompt Chaining al Routing, fino a Planner-Executor ed Evaluator-Optimizer. Il valore del pattern emerge quando sappiamo dire anche quando non usarlo.