Miglior software ERP agentico: cosa cercare

Perché non c'è classifica qui

Immagina la lista ristretta. Quattro fornitori, quattro proposte e la parola agentic su ogni copertina. Uno è una suite consolidata con un assistente aggiunto l'anno scorso. Uno è un prodotto più recente costruito attorno al proprio agente. Uno è una piattaforma che consente a qualsiasi agente di connettersi tramite un protocollo aperto. Uno è uno strumento di workflow con un modello linguistico al centro. Tutti e quattro si presentano bene. Due di essi si aspetteranno ancora una persona davanti allo schermo per qualsiasi cosa che attraversi un confine di modulo, e non scoprirai quali due dalle proposte.

Una lista classificata non può aiutarti in questo, per un motivo che non ha nulla a che fare con la qualità dei prodotti. L'agente è una proprietà dell'architettura, e se un'architettura è giusta per te dipende dai moduli che utilizzi, dall'agente che il tuo team usa già, quali sono le tue soglie di approvazione e quanto hai bisogno di vedere nel log. Questi sono i tuoi fatti, non quelli di un revisore. Ciò che viaggia tra le aziende è l'insieme dei test, quindi questa pagina ti fornisce i test e ti chiede di fare la classificazione.

Test 1: protocollo aperto, il tuo agente dall'esterno

Il primo test è se un agente che il fornitore non ha costruito può operare il sistema. Lo standard aperto per questo è il Model Context Protocol, che i client agent mainstream utilizzano: Claude aggiunge un server MCP remoto come connettore personalizzato con accesso OAuth; ChatGPT fa lo stesso in modalità sviluppatore con supporto completo per lettura e scrittura; gli agenti di codifica e gli agenti interni costruiti sugli SDK del fornitore si connettono allo stesso modo. Un prodotto che parla MCP può essere operato da chiunque di loro. Un prodotto che funziona solo con il proprio assistente non può essere operato da nessun altro, e quella decisione è stata presa per te.

La prova da richiedere è la risposta del server a una richiesta tools/list, che secondo il protocollo è l'elenco leggibile dalla macchina di tutto ciò che l'agente può fare. Dovrebbe apparire in questo modo, ripetuto per ogni azione nel sistema.

{
  "tools": [
    {
      "name": "contacts.search",
      "description": "Find contacts by name, email or company.",
      "inputSchema": { "type": "object", "properties": { "query": { "type": "string" } }, "required": ["query"] }
    },
    {
      "name": "invoices.create",
      "description": "Create a draft invoice from billable lines. Fails if the caller cannot raise invoices.",
      "inputSchema": { "type": "object", "properties": { "customer_id": { "type": "string" }, "lines": { "type": "array" } }, "required": ["customer_id", "lines"] }
    },
    {
      "name": "purchase_orders.approve",
      "description": "Approve a purchase order within the caller's approval limit.",
      "inputSchema": { "type": "object", "properties": { "purchase_order_id": { "type": "string" } }, "required": ["purchase_order_id"] }
    }
  ]
}

Una risposta illustrativa degli strumenti/elenco nella forma definita dalla specifica MCP. I nomi e la copertura varieranno a seconda del prodotto; ciò che conta è che l'elenco esista, sia tipizzato e sia sufficientemente lungo da coprire i moduli che utilizzi.

Tre cose da controllare nella lista. È lunga, perché un ERP ha centinaia di azioni e una lista di venti significa che l'assistente raggiunge venti funzionalità. È tipizzata, con uno schema JSON per ogni input, perché è ciò che consente al server di convalidare le chiamate piuttosto che interpretare la prosa. E cambia quando un utente più ristretto accede, che è il ponte verso il secondo test.

Test 2: permessi per utente su ogni chiamata

An agent that can do more than the person it represents is a liability, not a feature. The second test is whether permissions are enforced per user and per call, not per product or per session. The protocol allows a server to vary the tool list by the authorisation presented and requires servers to implement proper access controls, but it cannot enforce either on the vendor's behalf. The good implementations filter the list before the agent sees it and then check again when each tool runs, because a filtered list is a courtesy and an execution-time check is a control.

La prova è un rifiuto in tempo reale. Accedi come utente che non può approvare ordini di acquisto, chiedi al loro agente di approvarne uno e osserva cosa succede. La risposta corretta è un rifiuto chiaro al momento della chiamata, registrato, con il resto della richiesta che continua a completarsi. Le risposte sbagliate sono un'approvazione che passa, un errore che rivela cosa avrebbe fatto lo strumento, o una sessione che fallisce perché il controllo era solo sullo schermo.

Test 3: trasparenza del budget e dei costi

Un agente che ragiona sui modelli del fornitore consuma qualcosa ogni volta che viene eseguito, e il terzo test è se puoi limitare quella spesa e vedere dove è andata. Il meccanismo specifico conta meno delle due proprietà: un limite impostato per integrazione o per chiave che l'agente non può superare, e un registro per azione di quanto è costato ogni esecuzione. Un prodotto che può solo dirti il totale mensile dopo il fatto non ha costruito il misuratore, e lo scoprirai quando un ciclo incontrollato o un nuovo utente entusiasta colpisce la bolletta.

C'è una seconda domanda sui costi che le pagine di ranking saltano completamente. Se il prodotto ti consente di portare il tuo agente, allora quando quell'agente fa il ragionamento il fornitore potrebbe non eseguire affatto AI per tuo conto e non addebitarti nulla per questo. Per un team che già paga per Claude o ChatGPT, questo trasforma il costo dell'agente in una voce che controlli piuttosto che in una voce impostata dal fornitore. Chiedi a ciascun fornitore quanto addebitano quando il tuo agente fa il ragionamento e annota la risposta.

Test 4: audit che si legge come il registro di una persona

Quando un agente svolge il lavoro, il registro diventa il modo principale in cui un manager lo esamina, quindi il quarto test è se la traccia di audit registra le azioni dell'agente in modo completo come quelle di una persona. Il minimo è chi ha chiesto, quale agente ha agito per loro conto, quali strumenti sono stati eseguiti, con quali input, con quale risultato e quando. Le stesse linee guida del protocollo indicano che i clienti dovrebbero registrare l'uso degli strumenti per l'audit; il server dovrebbe fare lo stesso dal suo lato, perché è il server a sapere cosa è effettivamente cambiato.

La prova è il registro stesso, dopo la richiesta di demo. Aprilo e controlla quattro cose: attribuzione a una persona, non a un utente di integrazione generico; la sequenza delle chiamate agli strumenti, non solo i registri che sono stati modificati; input e risultati, in modo che un'azione errata possa essere ricondotta a un input errato; e rifiuti, perché un modello di autorizzazione che non registra i suoi dinieghi non può essere ottimizzato.

Test 5: un marketplace, e cosa ti dice

Il quinto test è indiretto ma rivelatore. Se una piattaforma ha un marketplace di app costruite da persone diverse dal fornitore, e quelle app sono gestite da agenti attraverso la stessa interfaccia degli strumenti dei moduli principali, allora l'interfaccia degli strumenti è reale, documentata e abbastanza stabile per consentire agli esterni di costruire. Un marketplace è l'architettura del fornitore messa alla prova da estranei ogni giorno. Risponde anche alla domanda pratica su cosa succede quando hai bisogno di una funzionalità che il prodotto principale non ha: se aspetti la roadmap, paghi per un lavoro personalizzato o installi qualcosa che esiste già.

La prova è un'app pubblicata da una terza parte, installata nel tuo spazio di prova, che appare nell'elenco degli strumenti dell'agente nella richiesta successiva. Se il marketplace esiste ma le app sono tutte del fornitore, o se installarne una non cambia ciò che l'agente può fare, il test è solo parzialmente superato.

Il punteggio

Porta questo in ogni demo e compilalo il giorno stesso. Valuta ogni test come superato, parziale o fallito, e insisti per vedere le prove piuttosto che sentirne parlare. Un prodotto che fallisce il primo test è un prodotto con un assistente, qualunque cosa dica la copertura, e gli altri quattro test diventano accademici.

Sois è un'implementazione contro cui puoi eseguire questi test, e poiché lo costruiamo possiamo dire come risponde. Uno spazio di lavoro è un server MCP; qualsiasi client compatibile si connette aggiungendo l'indirizzo dello spazio di lavoro e accedendo una volta tramite OAuth, senza token da incollare. Gli strumenti sono filtrati in base al ruolo dell'utente prima di essere offerti e controllati di nuovo quando vengono eseguiti, e l'accesso fallisce in modo chiuso. La spesa può essere limitata per integrazione, ogni azione è registrata, e quando il tuo agente esegue il ragionamento la piattaforma non esegue alcuna IA per tuo conto e non addebita nulla per questo. Gli sviluppatori costruiscono app con il proprio agente, validano localmente gratuitamente e pubblicano in un marketplace dove ogni agente connesso può richiamarle. Esegui gli stessi cinque test contro di essa come contro tutti gli altri; questo è ciò per cui servono.

Domande che le persone pongono

Questo articolo viene revisionato quando i prodotti che descrive cambiano. Prossima revisione programmata: 4 dicembre 2026.