L'ascesa degli AI Agent nel software enterprise

Un anno fa la maggior parte delle aziende trattava i modelli linguistici di grandi dimensioni come sofisticati motori di autocompletamento: utili per redigere email e riassumere documenti, ma lontani dal cuore di qualsiasi workflow business-critical. Quella prospettiva è cambiata radicalmente. L'emergere degli AI agent — sistemi software in grado di pianificare, ragionare, usare strumenti e compiere azioni autonome in più passaggi — sta riscrivendo le regole dell'automazione enterprise.

In Nexora abbiamo trascorso gli ultimi diciotto mesi a costruire e deployare sistemi ad agenti per clienti nei settori logistica, manifatturiero e retail. Questo articolo distilla ciò che abbiamo imparato: cosa sono realmente gli agent, come progettarli per la produzione, dove generano valore concreto e dove ancora presentano limiti.

Cosa si intende per AI Agent?

Un AI agent è un sistema che utilizza un modello linguistico come motore di ragionamento e può richiamare strumenti esterni — API, database, interpreti di codice, browser — per completare task che si articolano in più fasi. A differenza di un chatbot tradizionale che produce una singola risposta, un agent entra in un loop: riceve un obiettivo, ragiona sull'azione successiva, esegue quell'azione, osserva il risultato e itera fino al raggiungimento del goal.

La distinzione fondamentale rispetto alle semplici chiamate LLM è l'agency: è il modello a decidere cosa fare dopo, non lo sviluppatore. Questo apre uno spazio di design completamente diverso — e uno spazio di failure mode altrettanto diverso.

Pattern architetturali degli Agent

Dopo aver costruito una dozzina di sistemi ad agenti in produzione, abbiamo consolidato tre pattern architetturali che coprono la grande maggioranza dei casi d'uso enterprise.

1. ReAct (Reason + Act)

Il pattern ReAct alterna ragionamento e azione all'interno di un singolo context window. Il modello produce un pensiero, seleziona uno strumento, osserva l'output e ragiona di nuovo. È il pattern più semplice e funziona bene per task completabili in meno di dieci passi con strumenti deterministici.

import { ChatOpenAI } from "@langchain/openai";
import { AgentExecutor, createReactAgent } from "langchain/agents";
import { DynamicStructuredTool } from "@langchain/core/tools";
import { z } from "zod";

// Definizione degli strumenti enterprise
const getOrderStatus = new DynamicStructuredTool({
  name: "get_order_status",
  description: "Recupera lo stato in tempo reale di un ordine dall'ERP",
  schema: z.object({ orderId: z.string() }),
  func: async ({ orderId }) => {
    const order = await erpClient.getOrder(orderId);
    return JSON.stringify(order);
  },
});

const updateTicket = new DynamicStructuredTool({
  name: "update_support_ticket",
  description: "Aggiorna un ticket di supporto con una nota e un cambio di stato opzionale",
  schema: z.object({
    ticketId: z.string(),
    note: z.string(),
    newStatus: z.enum(["aperto", "in_attesa", "risolto"]).optional(),
  }),
  func: async ({ ticketId, note, newStatus }) => {
    await crmClient.updateTicket(ticketId, { note, status: newStatus });
    return "Ticket aggiornato con successo";
  },
});

const model = new ChatOpenAI({ model: "gpt-4o", temperature: 0 });
const tools = [getOrderStatus, updateTicket];

const agent = await createReactAgent({ llm: model, tools, prompt });
const executor = new AgentExecutor({ agent, tools, maxIterations: 10 });

const result = await executor.invoke({
  input: "L'ordine ORD-8821 è stato segnalato. Verifica lo stato e aggiorna il ticket TKT-441.",
});

2. Plan-and-Execute

Per task complessi e di lungo respiro, il ReAct fatica perché il modello perde il filo dell'obiettivo generale a metà esecuzione. Il pattern Plan-and-Execute risolve questo problema separando la pianificazione dall'esecuzione. Un LLM di pianificazione (spesso un modello più potente come GPT-4o o Claude Opus) produce prima un elenco strutturato di task; un agente di esecuzione separato elabora ogni passaggio.

interface Piano {
  passi: { id: number; descrizione: string; strumento?: string }[];
}

async function pianificaEd Esegui(obiettivo: string): Promise<void> {
  // 1. Fase di pianificazione — usa un modello capace per generare un piano strutturato
  const piano: Piano = await pianificatoreLLM.invoke({
    obiettivo,
    strumentiDisponibili: strumenti.map((t) => ({ nome: t.name, descrizione: t.description })),
  });

  console.log(`Piano generato: ${piano.passi.length} passi`);

  // 2. Fase di esecuzione — itera sui passi
  const contestoEsecuzione: Record<number, unknown> = {};

  for (const passo of piano.passi) {
    console.log(`Esecuzione passo ${passo.id}: ${passo.descrizione}`);

    const risultato = await esecutoreLLM.invoke({
      passo,
      risultatiPrecedenti: contestoEsecuzione,
      obiettivo,
    });

    contestoEsecuzione[passo.id] = risultato;
  }
}

3. Orchestrazione Multi-Agent

Il pattern più potente — e più complesso — è l'orchestrazione multi-agente. Agent specializzati gestiscono domini distinti (magazzino, fatturazione, dati clienti) e un agent supervisore li coordina. Questo rispecchia il modo in cui funzionano le organizzazioni umane e permette di ottimizzare ciascun agent in modo indipendente.

// Agent supervisore che instrada i task agli agent specializzati
const supervisoreAgent = new SupervisoreAgent({
  agenti: {
    magazzino: new MagazzinoAgent({ strumenti: [verificaStock, prenotaArticoli] }),
    fatturazione: new FatturazioneAgent({ strumenti: [creaFattura, processaRimborso] }),
    logistica: new LogisticaAgent({ strumenti: [creaSpedizione, tracciaPacco] }),
    clienti: new ClientiAgent({ strumenti: [getProfiloCliente, aggiornaPreferenze] }),
  },
  routingModel: "gpt-4o",
  systemPrompt: `Sei un supervisore delle operazioni enterprise.
    Delega i task all'agent specialista appropriato.
    Combina i risultati in una risposta coerente per l'operatore.`,
});

// Il supervisore decide quali agenti invocare e in quale ordine
const risultato = await supervisoreAgent.run(
  "Gestisci la richiesta di reso per l'ordine ORD-9912: verifica l'idoneità, avvia il rimborso e pianifica il ritiro."
);

Casi d'uso enterprise reali

La teoria è utile, ma è più istruttivo analizzare ciò che abbiamo effettivamente costruito e i risultati misurabili ottenuti.

1. Triage intelligente dei ticket (SaaS B2B)

Un cliente con un team di supporto di 12 persone impiegava il 40% del proprio tempo lavorativo a classificare manualmente, instradare e rispondere ai ticket di primo livello. Abbiamo costruito un agent di triage che: legge ogni ticket in arrivo, interroga la knowledge base e le note di rilascio recenti, classifica urgenza e categoria, redige una risposta per i casi comuni ed escalation quelli complessi con un riepilogo. L'agent gestisce il 73% dei ticket end-to-end. Il tempo medio di prima risposta è passato da 4,2 ore a 11 minuti.

2. Intelligenza degli acquisti automatizzata (manifatturiero)

Un'azienda manifatturiera aveva la necessità di monitorare i tempi di consegna dei fornitori, rilevare anomalie e reindirizzare proattivamente gli ordini. L'agent monitora gli ordini di acquisto, interroga le API dei fornitori, incrocia i dati con gli SLA di consegna e genera alert quando i ritardi previsti superano le soglie. Suggerisce inoltre fornitori alternativi basandosi sui dati storici di performance. Il team acquisti ora esamina le raccomandazioni dell'agent invece dei dati grezzi, risparmiando circa 22 ore settimanali.

3. Rilevamento anomalie e-commerce (retail)

Per un operatore e-commerce che gestisce tre canali marketplace, abbiamo deployato un agent di monitoraggio che monitora continuamente livelli di inventario, parità di prezzo e tassi di evasione ordini. Quando rileva anomalie — un disallineamento di prezzo su Amazon, un errore di sincronizzazione dell'inventario su Shopify, una spedizione in ritardo — l'agent crea e assegna task nel sistema interno, notifica il team competente e, per le azioni pre-approvate, esegue le correzioni direttamente.

Architettura di produzione: cosa conta davvero

Costruire un proof-of-concept di un agent richiede un pomeriggio. Deployarne uno in produzione che sia affidabile, osservabile e manutenibile richiede mesi di iterazione. Ecco cosa abbiamo imparato essere davvero importante.

Affidabilità tramite checkpointing

Gli agent a lungo termine falliranno a metà esecuzione. Timeout di rete, rate limit, errori transitori — tutto questo accade in produzione. Senza checkpointing, un fallimento al passo 7 di un piano da 10 passi significa ricominciare dal passo 1. Usiamo un persistent state store (Redis o PostgreSQL) per eseguire il checkpoint dopo ogni azione.

class AgentConCheckpoint {
  private stateStore: AgentStateStore;

  async esegui(sessionId: string, obiettivo: string): Promise<void> {
    // Riprende dal checkpoint se esiste
    let stato = await this.stateStore.carica(sessionId) ?? {
      sessionId,
      obiettivo,
      passiCompletati: [],
      pianCorrente: null,
      status: "in_attesa",
    };

    while (stato.status !== "completato") {
      try {
        const azioneSuccessiva = await this.ragionaProssimaAzione(stato);
        const risultato = await this.eseguiAzione(azioneSuccessiva);

        stato.passiCompletati.push({ azione: azioneSuccessiva, risultato });
        stato.status = this.valutaCompletamento(stato) ? "completato" : "in_esecuzione";

        // Checkpoint dopo ogni azione riuscita
        await this.stateStore.salva(sessionId, stato);
      } catch (errore) {
        stato.status = "errore";
        await this.stateStore.salva(sessionId, stato);
        throw errore;
      }
    }
  }
}

Observability: tracciare ogni ragionamento

Fare debug di un loop di ragionamento non deterministico senza trace è praticamente impossibile. Ogni agent che costruiamo emette trace strutturate per ogni ciclo pensiero-azione-osservazione, con metriche di latenza per chiamata agli strumenti, utilizzo di token, conteggio delle invocazioni del modello e risultato finale. Usiamo LangSmith per gli agent basati su LangChain e un'integrazione OpenTelemetry personalizzata per i sistemi su misura.

Human-in-the-Loop: gate di approvazione umana

Non ogni azione deve essere autonoma. Implementiamo gate di approvazione per azioni ad alto impatto: elaborazione di rimborsi sopra una soglia, modifica di dati clienti, esecuzione di scritture su database in sistemi di produzione. L'agent si mette in pausa, notifica un operatore umano via Slack o email e attende l'approvazione esplicita prima di procedere.

Guardrail e hardening dei prompt

Gli agent enterprise hanno accesso a sistemi reali con dati reali. Il prompt injection — dove contenuti malevoli in una sorgente dati esterna dirottano le istruzioni dell'agent — è una minaccia concreta. Applichiamo sanitizzazione dell'input su tutti i contenuti provenienti dall'esterno prima che entrino nel context window, manteniamo layer separati per system prompt e user prompt e usiamo output parser con schemi strict per prevenire chiamate di strumenti impreviste.

I failure mode più comuni da anticipare

• Allucinazione degli strumenti: l'agent inventa argomenti degli strumenti che non rispettano lo schema. Soluzione: validazione strict JSON schema su ogni chiamata.
• Saturazione del context window: gli agent a lungo termine accumulano osservazioni fino all'overflow del contesto. Soluzione: implementare rolling summarisation delle osservazioni più vecchie.
• Loop infiniti: l'agent ripete la stessa azione fallimentare. Soluzione: tracciare la cronologia delle azioni e aggiungere logica di loop-detection con un hard limit sui passi.
• Eccessiva fiducia: l'agent dichiara il successo basandosi su informazioni parziali. Soluzione: richiedere passi di verifica espliciti prima di marcare un task come completato.
• Latenza: le chiamate LLM sequenziali si sommano. Soluzione: parallelizzare i sotto-task indipendenti usando un'architettura multi-agent dove possibile.

Lo stack tecnologico che usiamo

Quando NON usare gli agent

Gli AI agent sono potenti ma costosi e non deterministici. Sono lo strumento sbagliato quando: il task ha un insieme fisso e noto di passi (meglio un workflow deterministico); la latenza è critica e serve una risposta sotto i 100ms; il costo per invocazione è proibitivo per il volume; oppure il failure mode è catastrofico e la reversibilità è limitata. Per questi scenari, l'automazione tradizionale — motori di regole, sistemi BPM, integrazioni scriptate — rimane superiore.

Conclusioni

Gli AI agent rappresentano un cambiamento reale in ciò che è realizzabile con il software. Quando progettati con la giusta architettura, checkpointing, observability e supervisione umana, possono gestire task che prima richiedevano personale dedicato, comprimere processi multi-giorno in minuti e portare in superficie intelligence che nessun team umano potrebbe mantenere alla scala richiesta. La chiave è sapere dove inserirli: ad aumentare il giudizio umano, non a sostituire una disciplina ingegneristica rigorosa.