Maven Apps: i tuoi agenti hanno bisogno di operatori, non di pannelli di controllo

Un quadro di commutazione fa esattamente ciò per cui è stato cablato: azioni l'interruttore e ottieni sempre la stessa risposta fissa. Chiedigli di gestire qualcosa al di fuori di quel circuito e non ci riesce, perché non gestisce le variazioni, solo il cablaggio.

Un operatore è diverso. Dai a un operatore una richiesta, "passami la reception", e capisce lui come fare: quale linea usare, cosa fare se è occupata, cosa fare se la richiesta stessa era ambigua. Non si limita a trasmettere il segnale: lo interpreta e agisce di conseguenza.

Le Maven Apps sono operatori, non quadri di commutazione. Quando ci siamo messi a costruire il framework alla base della nostra infrastruttura di App, abbiamo fatto una scommessa precisa: non costruire l'ennesimo livello di integrazione. Costruire una vera piattaforma applicativa, in cui gli agenti AI siano cittadini di prima classe.

Oggi sul nostro framework girano migliaia di app. Certo, ci sono app per i principali sistemi di terze parti come Salesforce, Zendesk e Notion. Ma ci sono anche centinaia di app personalizzate in produzione su agenti attivi.

Perché le integrazioni di base non bastano

Chiedi a 10 fornitori cosa significa "si integra con Salesforce" per il loro prodotto e otterrai 10 risposte diverse, perché un sistema come Salesforce, Zendesk o Front non è mai una cosa sola. Può essere:

• Un luogo in cui il tuo agente deve andare a cercare informazioni (una knowledge base, lo storico dei casi)
• Un luogo in cui il tuo agente deve andare per agire (creare un ticket, aggiornare un record, emettere un rimborso)
• Una superficie in cui il tuo agente deve comparire (un co-pilot di agent assist all'interno della console in cui il tuo team di supporto lavora già)

Una "integrazione con Salesforce" che conosce solo gli articoli non è lo stesso prodotto di una che può anche aprire un caso, e non è lo stesso prodotto di una che può stare nella console degli operatori come co-pilot. Spesso tutto questo viene raggruppato sotto un'unica parola di marketing, e le lacune le scopri durante l'implementazione.

È il problema del distributore automatico: un menu fisso che funziona esattamente come promesso finché ciò che ti serve non è nell'elenco, e a quel punto ti sei già impegnato. Non volevamo che le Maven Apps funzionassero così, quindi abbiamo costruito il framework attorno alla vera domanda posta (conoscenza, capacità o canale) anziché attorno a un "connettore" generico.

Maven Apps: più che integrazioni

Le Maven Apps possono assumere molte forme, ma la maggior parte si basa su alcuni schemi comuni. Qualche esempio di ciò che le app possono fare:

• Le app di conoscenza leggono e indicizzano contenuti da un sistema esterno, così l'agente può rispondere basandosi su di essi: sola lettura, con versioni, etichettabili per pubblico.
• Le app di capacità permettono all'agente di fare davvero qualcosa in quel sistema: una vera chiamata API, concatenata in un workflow in più passaggi (cerca l'ordine, verifica la politica di reso, emetti il rimborso, conferma al cliente), tutto all'interno di un'unica conversazione. Se un bancomat esegue una sola transazione predefinita da un menu fisso, un'app di capacità si comporta piuttosto come un consulente bancario personale: riceve un risultato da raggiungere, non una voce di menu, e fa ciò che serve per arrivarci, gestione delle eccezioni inclusa.
• Le app di canale portano l'agente dove si trovano già i tuoi clienti o il tuo team di supporto: un widget incorporato, una telefonata, una casella di posta o un pannello co-pilot nella console che i tuoi operatori usano ogni giorno.

Un'app predefinita della nostra directory si installa di solito in pochi minuti. Quando il sistema di un cliente non è nel catalogo, uno sviluppatore usa lo stesso framework, lo stesso SDK, gli stessi lifecycle hook e lo stesso modello di sicurezza per crearne una personalizzata.

Non esiste un livello "enterprise-grade" separato del framework riservato ai nostri ingegneri: App Studio, la nostra piattaforma per sviluppatori per creare app, gira sulla stessa identica architettura. È vero TypeScript, un vero SDK (@mavenagi/mavenagi) e una vera pipeline di deploy, non un linguaggio di scripting proprietario da imparare solo per noi.

Se hai già lavorato con MCP, una Maven App ti offre un'idea simile, completamente gestita. Un server MCP standard significa comunque doverlo avviare, registrare, mantenere attivo e scalare da solo. Una Maven App è più simile a un endpoint MCP che si registra e si scala in automatico, senza alcuna infrastruttura da gestire: tu scrivi la logica, mentre endpoint, autenticazione e hosting sono gestiti per te.

Come sono progettate le App per essere potenti

Una Maven App è un'applicazione serverless che gira in un ambiente sicuro e isolato e comunica con la piattaforma Maven tramite un SDK definito. In concreto:

È multi-tenant. Una singola app viene creata una volta e installata molte volte, in organizzazioni e agenti diversi. Ogni installazione ha il proprio contesto delimitato (il proprio ID organizzazione, ID agente e configurazione di runtime), ma condivide lo stesso codice sottostante. Questo significa che quando rilasciamo un miglioramento all'app Salesforce, ne beneficia ogni cliente che la usa, e nessuno resta bloccato su una versione obsoleta e fatta a mano della "propria" integrazione.

È isolata, non appiccicata. Ogni app gira come funzione a sé in un ambiente sicuro, separata dal backend principale di Maven e dalle app degli altri clienti. La tua logica personalizzata non gira mai in un monolite condiviso accanto a quella di qualcun altro. Le connessioni verso i tuoi sistemi di riferimento possono passare via VPN, VPC peering, OIDC o semplice HTTPS con IP allowlisting: scegli tu, non noi.

Reagisce a eventi reali, non a pianificazioni di polling. Invece di un job di sincronizzazione notturno, un'app può implementare hook di evento chiamati trigger: è stata creata una conversazione, è arrivato un feedback, una knowledge base è stata aggiornata, e la piattaforma avvisa l'app nel momento in cui l'evento si verifica. È un modello diverso dagli strumenti di automazione che forse conosci già. Un trigger Maven è passivo: è la piattaforma stessa ad ascoltare i cambiamenti di stato e a inviarli a qualsiasi app interessata, senza alcun accoppiamento tra l'app che ha causato l'evento e quella che reagisce. In pratica, un'app di risposta email e un'app di sincronizzazione Salesforce del tutto separata possono reagire entrambe allo stesso evento "conversazione aggiornata" in modo indipendente, ognuna per conto suo, senza che nessuna delle due sappia dell'esistenza dell'altra.

È lo stesso meccanismo di coordinamento di una colonia di formiche. Nessuna singola formica pianifica il comportamento della colonia e nessuna formica comunica direttamente con un'altra: una formica modifica qualcosa nell'ambiente condiviso (una traccia di feromoni) e tutte le altre reagiscono a quel cambiamento in modo indipendente, ognuna seguendo la propria semplice regola. L'intelligenza a livello di colonia (percorsi di foraggiamento ottimizzati, bilanciamento del carico, persino decisioni collettive come lo spostamento del nido) emerge da qui, senza un coordinatore centrale e senza che alcuna formica conosca il piano. Le Maven Apps si coordinano allo stesso modo: un evento modifica lo stato condiviso e ogni app interessata reagisce per conto proprio.

Ha un vero ciclo di vita. Ogni app implementa un piccolo insieme di lifecycle hook:

• preInstall: convalida credenziali e configurazione prima che qualsiasi cosa vada live. Se la tua chiave API è sbagliata, l'installazione fallisce in modo evidente qui, invece che in silenzio 3 settimane dopo.
• postInstall: registra le azioni dell'app e predispone le risorse necessarie una volta completata l'installazione.
• executeAction: esegue il lavoro effettivo richiesto dall'agente, esposto ai clienti come capacità: cercare un ordine, creare un caso, emettere un rimborso, verificare il saldo di un conto.

La maggior parte delle integrazioni è un interruttore della luce: acceso o spento, niente in mezzo. Le nostre seguono un ciclo di vita completo di installazione, convalida, esecuzione e dismissione, più simile a una routine che legge il contesto e si adatta (verifica cosa è aperto, conferma cosa è sicuro, poi agisci) che a un interruttore a 2 stati. È esattamente la disciplina che ti aspetteresti da un software di produzione, perché è esattamente ciò che è.

App vs integrazioni

Un'integrazione tipica risponde a una domanda molto circoscritta, di solito "i dati possono passare da A a B?", e la considera il traguardo. Una Maven App è costruita per rispondere a una domanda più difficile e più utile: un agente AI può sapere in modo affidabile cosa è vero nei tuoi sistemi in questo momento, e ci si può fidare che agisca per tuo conto quando serve?

La maggior parte delle piattaforme enterprise offre una versione di "costruiscilo tu se non lo abbiamo già pronto". Quello che di solito non ti dicono è che costruirlo da te significa gestire il tuo server, il tuo scaling, la tua revisione di sicurezza, sulla tua infrastruttura. Così una semplice lacuna nel catalogo dei connettori diventa una decisione sul personale: ottieni un budget per ingegneria e infrastruttura o resti limitato a ciò che è predefinito? Con le Maven Apps, i nostri clienti non sono costretti a scegliere il male minore. Un'app personalizzata creata da te o dal tuo sviluppatore gira sulla nostra infrastruttura, con lo stesso monitoraggio, lo stesso scaling e la stessa sicurezza di ogni app predefinita della nostra directory. Tu scrivi il codice, noi lo eseguiamo.

Per questo l'architettura insiste su aspetti di cui un semplice webhook non deve mai preoccuparsi:

• Risposte strutturate e di dimensione limitata. Ogni azione eseguita da un'app restituisce una risposta chiara più dati strutturati su cui l'agente può ragionare, non un blob grezzo e illimitato da interpretare a tentativi.
• Autenticazione firmata e reciproca. La piattaforma firma ogni richiesta a un'app, così l'app può verificare che a chiamare sia davvero Maven, e l'app si autentica a sua volta presso la piattaforma con le proprie credenziali. Nessuna delle due parti deve fidarsi solo della rete.
• Configurazione convalidata prima ancora di arrivare in produzione. Poiché preInstall viene eseguito prima che un'app vada live, una credenziale non valida o un'impostazione mancante vengono intercettate in fase di installazione, non la prima volta che un cliente ne ha bisogno.
• Una vera infrastruttura sotto, non solo una chiamata di funzione. Essendo applicazioni complete, le app possono mantenere uno stato reale: una cache, un conteggio delle richieste, un piccolo database, non solo richieste e risposte stateless. È questo che permette, per esempio, di monitorare se il tasso di risoluzione per un dominio specifico è calato di oltre il 10% nelle ultime 24 ore e avvisare il tuo team quando succede. Una semplice chiamata API non può avere questo tipo di memoria. Una vera applicazione sì, così come una colonia di formiche ricorda dove si trova il cibo anche se nessuna singola formica lo sa.
• Dati sensibili lontani dal modello. Alcuni passaggi non dovrebbero proprio passare da un'AI. Quando un cliente è pronto ad acquistare ciò che ha nel carrello, l'agente avvia il checkout dell'app, e l'app raccoglie pagamento e dati personali direttamente dal cliente tramite la propria interfaccia sicura. L'agente orchestra il flusso, ma numeri di carta e altre informazioni sensibili non entrano mai nella conversazione con l'AI.
• Un unico codebase, tutti i clienti, impatto isolato. Il multi-tenancy fa sì che correzioni e miglioramenti vengano rilasciati una volta sola e arrivino a tutti, mentre l'isolamento garantisce che la logica personalizzata di un cliente non possa mai influire su quella di un altro.

Cosa significa per te

Se stai valutando Maven, il punto pratico è questo: quando diciamo che un agente può rispondere a una domanda e agire di conseguenza, intendiamo che dietro quell'azione c'è una vera applicazione, con versioni, autenticata, isolata e costruita sullo stesso framework, che sia stata rilasciata dal nostro team o dal tuo. È la differenza tra un agente che sa parlare dei tuoi sistemi e uno che vi è davvero collegato.

Abbiamo creato le Maven Apps perché pensiamo che sia questo il significato che "integrazione" avrebbe dovuto avere fin dall'inizio.