Che cos'è un agente IA?

Un agente IA è un sistema guidato da un LLM che persegue un obiettivo in un ciclo: ragiona, chiama un tool, osserva il risultato e ripete. Una semplice chiamata a un LLM risponde e si ferma; un agente avvolge quella chiamata in un ciclo di controllo con tool (funzioni che può invocare), memoria (stato da un passo all’altro) e abbastanza autonomia per scegliere la propria sequenza di azioni. Il cambio di prospettiva decisivo per chi sviluppa backend è il fatto più banale e meno detto sugli agenti: i “tool” di un agente sono gli endpoint del proprio backend – quando un agente “usa un tool” sta chiamando un’API scritta in casa, il che fa del backend, non del prompt, il luogo in cui la sicurezza vive davvero.

Punti chiave

Come funziona il ciclo di ragionamento (ReAct) di un agente IA

OBIETTIVO: "Rimborsa il mio ultimo ordine e inviami la conferma"

  ┌────────────────────────────────────────────────────────────┐
  │ 1 REASON   modello: "mi serve l'ultimo ordine dell'utente" │
  │ 2 ACT      chiama il tool: find_orders(user, last=1)       │
  │ 3 OBSERVE  risultato: ordine #1187, 42 $, consegnato       │
  │ 4 REASON   "ammissibile – si rimborsa"                     │
  │ 5 ACT      chiama il tool: refund_order(1187)              │◄─ ogni ACT colpisce
  │ 6 OBSERVE  risultato: rimborsato                           │   IL PROPRIO backend
  │ 7 REASON   "ora si invia l'e-mail all'utente"              │
  │ 8 ACT      chiama il tool: send_email(...)                 │
  │ 9 REASON   "fatto" → risposta finale                       │
  └────────────────────────────────────────────────────────────┘

Il modello non esegue mai un tool. Ne RICHIEDE uno (nome + argomenti);
il codice applicativo lo esegue e restituisce il risultato al passo di ragionamento successivo.

I tool di quel ciclo, lato backend – ad ambito ristretto, soggetti ai permessi, eseguiti come l’utente:

// JavaScript — Cloud Code (cloud/main.js)
// An agent's "tool" is a backend function — scoped, permissioned, auditable
Parse.Cloud.define('refundOrder', async (req) => {
  // Runs under the CALLING USER's session — ACLs gate everything.
  // A hijacked agent can't exceed what this user may already do.
  const asUser = { sessionToken: req.user.getSessionToken() };
  const order = await new Parse.Query('Order').get(req.params.orderId, asUser);
  // ACLs apply via the session token: not your order → this throws, agent or not
  if (order.get('amount') > 100) throw 'Refunds over $100 need human approval';
  order.set('status', 'refunded');
  await order.save(null, asUser);
  return { refunded: order.id }; // the tool result the model reasons over next
});
// The backend, not the prompt, is the security boundary.

// Flutter / Dart — Back4app Flutter SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
final result = await ParseCloudFunction('runAgent')
    .execute(parameters: {'goal': 'Refund my last order and email me'});
print(result.result);
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.

// iOS / Swift — Back4app Swift SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
let result: [String: Any] = try await Cloud.run(
    name: "runAgent",
    parameters: ["goal": "Refund my last order and email me"])
print(result)
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.

// Android / Kotlin — Back4app Android SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
val params = mapOf("goal" to "Refund my last order and email me")
val result = ParseCloud.callFunction<Map<String, Any>>("runAgent", params)
println(result)
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.

I quattro componenti essenziali di un agente IA

La scomposizione canonica è modello + pianificazione + memoria + uso dei tool, ma la versione operativa è più semplice: un modello ragiona, i tool agiscono (e sono funzioni del backend), la memoria conserva lo stato – a breve termine nella context window, a lungo termine in un database o in un vector store – e il ciclo di orchestrazione lega il tutto, sul modello del pattern ReAct che intreccia ragionamento e azione.

Agente vs. chatbot vs. chiamata a un LLM vs. workflow

La distinzione che conta di più, e che quasi nessun glossario traccia: un workflow è orchestrazione attraverso percorsi di codice predefiniti; un agente lascia che il modello diriga il proprio percorso. Le indicazioni di Anthropic sono nette sulla conseguenza – la maggior parte dei compiti che sembrano richiedere un agente è servita meglio da un workflow deterministico, e l’agentività si aggiunge solo quando il percorso davvero non si può scrivere in anticipo.

Affidabilità: gli errori si accumulano al ribasso

La sezione onesta che le pagine dei fornitori evitano. Gli agenti sono impressionanti sul singolo passo e fragili sulla catena, perché il successo si moltiplica: se ogni passo riesce con probabilità p, un compito di n passi riesce con probabilità circa pⁿ.

successo per passo   10 passi   20 passi
       95 %            ~60 %      ~36 %
       90 %            ~35 %      ~12 %
       85 %            ~20 %       ~4 %

Una demo che azzecca un passo impressionante non è un sistema che ne azzecca venti.
Nel mondo reale un agente multi-passo e cross-sistema riesce spesso nel 20–40 % dei casi.

Questo calcolo detta il playbook di produzione: tenere le catene corte, verificare i risultati tra un passo e l’altro invece di fidarsi, mettere le azioni irreversibili (inviare, eliminare, addebitare, pubblicare) dietro un’approvazione umana e limitare il ciclo con tetti di passi e di costo, così che un agente confuso fallisca a poco prezzo invece che a prezzo d’oro. L’affidabilità non è una proprietà del modello di cui attendere il miglioramento; è un’architettura che si impone.

La superficie di attacco

Un agente che può agire può essere ingannato per farlo agire, e questo lo rende una superficie di attacco davvero nuova. La prompt injection trasforma le istruzioni presenti nell’input del modello in azioni reali – e la variante pericolosa è quella indiretta: una pagina web, un’e-mail o un ticket di supporto avvelenati che l’agente legge possono portare istruzioni che poi esegue con le credenziali di casa. L’agente confuso (confused deputy) è la forma che prende il danno: un agente dotato di permessi ampi, manipolato perché ne abusi a vantaggio di chi attacca. Le contromisure sono vecchia disciplina di sicurezza puntata su un attore nuovo – credenziali a privilegio minimo, limitate all’utente (all’agente non va mai dato più di quanto l’utente del compito abbia già), tool negati per impostazione predefinita e ad ambito stretto, sandboxing e barriere umane su tutto ciò che è irreversibile. L’inquadramento più importante di tutti: è il backend, non il prompt, a costituire il confine di sicurezza. Un prompt si può iniettare; una verifica dei permessi lato server non si fa convincere a smettere di applicarsi.

Progettare tool che un agente non possa usare male

Poiché i tool sono il backend, progettarli è sicurezza del backend con il volume alzato. Ogni tool va reso idempotente dove possibile (un rimborso ritentato non deve rimborsare due volte), ad ambito stretto (un’azione chiara, non accesso grezzo al database), soggetto ai permessi (gira sotto l’identità dell’utente e le sue ACL si applicano) e chiaro nello schema – le descrizioni che il modello legge per decidere se e come chiamare un tool meritano la stessa cura dei prompt, perché una descrizione vaga è un bug che il modello troverà. Vanno esposte azioni, non tabelle: refund_order(id) con i propri controlli, mai run_sql(query).

Casi d’uso tipici

• Operazioni verso i clienti – un agente che risolve una richiesta di supporto dall’inizio alla fine tramite tool soggetti ai permessi, con barriera umana su rimborsi e cancellazioni.
• Assistenti di codice – leggere un repository, lanciare tool, iterare verso una modifica sottoposta a revisione.
• Ricerca e sintesi – retrieval e riassunto in più passi, quando il percorso non è noto in anticipo.
• Flussi di dati con discernimento – passi che richiedono ragionamento tra l’uno e l’altro, non solo una pipeline fissa.
• Pianificazione e coordinamento – obiettivi che attraversano più sistemi, ciascuno raggiunto con un tool ad ambito ristretto.

Conviene costruire un agente? Matrice decisionale

Limiti e trade-off

• L’autonomia scambia affidabilità con capacità. La libertà che permette a un agente di affrontare obiettivi aperti è la stessa che fa accumulare gli errori – va delimitata deliberatamente.
• I cicli costano soldi e tempo. Ogni iterazione sono altre chiamate al modello; gli agenti sono per costruzione più lenti e più costosi di una chiamata singola – entrambe le cose vanno limitate e monitorate.
• Il non determinismo resiste ai test. Un workflow si collauda con test unitari; un agente si valuta statisticamente, su molte esecuzioni, perché lo stesso input può prendere percorsi diversi.
• Il raggio d’impatto sono le credenziali. Un agente è sicuro quanto il permesso più stretto concesso ai suoi tool; un accesso troppo ampio è l’incidente che attende il suo momento.
• Impressionante ≠ affidabile. Una demo convincente è una catena fortunata; la produzione è il lavoro noioso di guardrail, barriere e percorsi corti.

Gli agenti IA su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. La tesi “i tool sono funzioni del backend” è tutta l’integrazione: i tool di un agente sono funzioni Cloud Code e, poiché girano sotto la sessione dell’utente chiamante, le ACL e i permessi di classe della piattaforma filtrano ogni lettura e ogni scrittura che l’agente tenta – come mostrano le schede di codice, un agente dirottato o vittima di prompt injection non può superare i permessi dell’utente stesso, perché il raggio d’impatto dell’agente confuso è limitato dal controllo degli accessi e non dalla buona condotta del modello. Il resto segue: esporre azioni ad ambito ristretto (refundOrder), non dati grezzi; tenere la chiave del modello lato server; standardizzare la superficie dei tool con MCP quando più agenti la condividono; e lasciare che il backend dica no. L’agente propone; il backend dispone – ed è esattamente dove deve vivere la sicurezza di un sistema autonomo.