Oggi presentiamo AIsuru Vibe Coder, il connettore (patent pending) con cui un agente AIsuru costruisce la propria applicazione parlando con il suo proprietario: database, interfacce, form, automazioni e regole di accesso, nella stessa conversazione in cui vengono chiesti. In questo articolo raccontiamo tutto: cosa fa, come lo fa passo per passo, perché non inventa mai un dato, come orchestra gli altri connettori della Suite e del catalogo, cosa ci hanno già costruito tester e clienti, e cosa significa per un'azienda che vuole portare gli agenti dentro processi veri.
Una conversazione che finisce con un'applicazione
La scena che abbiamo visto ripetersi decine di volte nelle ultime settimane comincia sempre allo stesso modo. Una persona apre la chat del proprio agente e scrive "iniziamo". L'agente non parte a generare codice: fa domande. A cosa serve questa applicazione? Chi potrà usarla? Chi deve vedere quali dati? Solo quando le risposte ci sono, si mette al lavoro. Crea il database, prepara le viste e i form, aggiunge le automazioni. Qualche minuto dopo, accanto alla chat c'è un pannello con un'applicazione vera, popolata di dati veri, che funziona.
La prima volta l'abbiamo fatto in casa, con la rendicontazione delle ore del nostro team. Nessun capitolato, nessuno sprint di sviluppo: una conversazione. "Mi serve un registro delle ore per il team." L'agente ha chiesto quali progetti esistessero, chi avrebbe inserito le ore, chi avrebbe potuto vedere quelle degli altri. Poi ha creato lo schema dei dati, un form con l'elenco dei progetti in un menu a ricerca, i timestamp compilati da soli, un timesheet tabellare nel pannello a fianco della chat e un messaggio di conferma dopo ogni inserimento. Il tempo di un caffè, e il team stava già registrando le ore.
Da allora, con lo stesso metodo, sono nati un CRM con la pipeline dei contatti, un sistema di ticketing con il suo layout pubblico, archivi personali con le copertine caricate da form, rassegne di notizie che si aggiornano da sole ogni mattina, flussi aziendali di approvazione fatture e revisione documenti. Nessuno di questi progetti ha richiesto una riga di codice scritta da un umano. Nessuno ha richiesto un deploy.
Il pezzo che rende possibile tutto questo si chiama AIsuru Vibe Coder. È uno dei sei connettori originali della Suite AIsuru, e sulla sua architettura Memori ha depositato una domanda di brevetto per invenzione industriale. In una frase: è il dev del tuo agente, dentro la conversazione.
Perché gli agenti, finora, non bastavano
Per capire cosa cambia oggi bisogna essere onesti su cosa mancava ieri. Gli agenti conversazionali, anche i migliori, hanno tre limiti strutturali.
Il primo: non hanno mani. Parlano, spiegano, riassumono, ma non possono creare strumenti, interfacce, automazioni. Ogni funzionalità nuova richiede uno sviluppatore, un progetto, un rilascio. L'agente resta un consulente eloquente seduto accanto a un cantiere fermo.
Il secondo: allucinano sui dati. Se chiedi a un modello linguistico "mostrami l'archivio", il modello non ha l'archivio: ha la capacità di generare una tabella plausibile. Plausibile, non vera. Numeri, date e relazioni possono essere inventati con la stessa fluidità con cui viene scritta una frase corretta. Per una chiacchierata va bene; per una fattura, un ordine o un turno di lavoro, no.
Il terzo, meno citato ma decisivo: non conoscono il proprio ambiente. Un agente ospitato in una piattaforma non sa cosa quella piattaforma può fare, quali capacità ha attive, quali potrebbe attivare. Quindi non può proporre soluzioni, né tantomeno costruirle. Può solo rispondere dentro il perimetro di ciò che gli è stato detto, sperando che chi lo ha configurato abbia pensato a tutto.
La Suite AIsuru nasce per superare tutti e tre i limiti insieme, e il Vibe Coder è il connettore che li affronta nel punto in cui convergono: dà le mani (la costruzione conversazionale), elimina le allucinazioni sui dati (con un'architettura, non con un prompt) e presuppone un agente consapevole del proprio ambiente, che sa cosa ha a disposizione e cosa gli manca.
Che cos'è, esattamente
AIsuru Vibe Coder è un connettore della piattaforma AIsuru che mette a disposizione dell'agente circa 45 strumenti orchestrati per costruire applicazioni reali attraverso la conversazione. Non genera mockup, non produce prototipi da rifinire: crea risorse operative e isolate, dedicate a quell'agente. Un database proprio. Viste proprie. Form propri. Automazioni proprie. Regole di governance proprie. Un registro di audit proprio.
E lo fa senza deployment. L'applicazione di un agente non è un progetto software da rilasciare: è un insieme di risorse che nascono in secondi, nella stessa conversazione in cui vengono richieste. Questo ha una conseguenza pratica che chi gestisce infrastrutture apprezzerà: migliaia di agenti possono vivere sulla stessa piattaforma, ciascuno con la propria applicazione isolata, e ogni miglioramento del runtime vale per tutti, all'istante.
Si attiva dal catalogo connettori di AIsuru con un click, come tutti gli altri. Da quel momento, basta scrivere "iniziamo".
Il percorso di costruzione, passo per passo
Prima le regole: l'onboarding di governance
Chi ha provato il vibe coding con gli strumenti per sviluppatori conosce la sensazione: si va veloci, e proprio per questo si può andare veloci nella direzione sbagliata. Per un'azienda il rischio non è estetico, è di governo: chi può costruire? Chi vede i dati inseriti dagli altri? Cosa succede se l'agente modifica qualcosa che non doveva?
Per questo il Vibe Coder comincia dalle regole, non dal codice. Le prime domande che l'agente fa al proprietario servono a stabilire lo scopo dell'applicazione, chi ha il permesso di costruire e chi ha visibilità su quali dati. E finché queste risposte non ci sono, vale una postura precisa, che in gergo si chiama default-deny: nessuna costruzione da parte degli utenti finali, nessuna visibilità sui dati altrui. Il permesso è l'eccezione da concedere, non la condizione di partenza da revocare.
C'è anche una distinzione di ruoli non negoziabile: le azioni che modificano l'agente stesso, il suo prompt, le sue funzioni, la sua applicazione, sono riservate al proprietario. Un utente finale usa l'applicazione; non la riscrive.
Il database che nasce vuoto
Quando la costruzione parte, la prima risorsa è la memoria strutturata: un database dedicato e isolato per l'agente, fornito da AIsuru Persistence. Nasce vuoto. Si popola soltanto attraverso l'interazione: la chat, i form, le automazioni. Le collezioni si creano dinamicamente man mano che la conversazione fa emergere le entità del dominio (i progetti, i clienti, i ticket, le copertine), senza migrazioni da scrivere e senza uno schema da progettare prima a tavolino.
È un rovesciamento del metodo tradizionale che merita una sottolineatura: normalmente si progetta lo schema e poi si spera che il lavoro reale ci si adatti. Qui lo schema emerge dal lavoro reale, e quando il dominio cresce, cresce anche lui, in conversazione.
Le viste e il pannello applicativo
I dati senza interfacce sono un magazzino senza porte. Il Vibe Coder crea viste: tabelle, card visuali, calendari, metriche. Vivono in un pannello applicativo accanto alla chat, ridimensionabile, utilizzabile anche da mobile, e brandizzabile in un'unica operazione: colori, logo, tono di voce. L'applicazione di un archivio personale può avere l'estetica di chi l'ha voluta; quella di un'azienda, l'identità dell'azienda.
E c'è un dettaglio che a chi fa il nostro mestiere piace particolarmente: l'agente può pilotare l'interfaccia. Mentre risponde in chat, può emettere comandi invisibili che aggiornano una vista o cambiano scheda nel pannello. Inserisci un dato parlando, e la tabella accanto si aggiorna. La conversazione e l'applicazione non sono due mondi separati: sono la stessa cosa vista da due lati.
I form intelligenti
Per i dati che entrano dalle persone, il Vibe Coder genera form con i campi derivati automaticamente dagli schemi: menu a tendina con ricerca per le entità collegate, timestamp compilati in automatico, upload di immagini e documenti che finiscono direttamente nelle viste, come le copertine di un archivio o gli allegati di una pratica. E i dati sono filtrati per l'utente collegato: ognuno vede i propri, secondo le regole decise nell'onboarding.
I form, inoltre, possono eseguire azioni reali lato server. Quando un invio deve innescare qualcosa nel mondo esterno, l'esecuzione avviene nell'infrastruttura, e i segreti necessari non transitano mai dal modello linguistico. È un principio che ritorna in tutta l'architettura: il modello decide cosa va fatto, l'infrastruttura lo fa, e le chiavi restano nell'infrastruttura.
Le automazioni
Un'applicazione che vive solo quando qualcuno le parla è un'applicazione a metà. Con AIsuru Scheduler, il Vibe Coder aggiunge i task ricorrenti o una tantum eseguiti per conto dell'agente: la rassegna che si popola ogni mattina alle sei, il promemoria che parte prima di ogni riunione, il report che si prepara da solo a fine settimana. I task sono isolati per utente e possono concatenare più passi. È il pezzo che trasforma un assistente reattivo in un collaboratore proattivo.
I layout pubblici
Non tutte le applicazioni vivono dentro una chat privata. Il Vibe Coder può creare layout pubblici con avvio automatico: chi arriva dal link trova l'applicazione già aperta e pronta, come è successo con il sistema di ticketing costruito da uno dei nostri team, dove il cliente apre la pagina, compila il form e ritrova i propri ticket nella scheda dedicata. E l'agente può essere incorporato via web component dentro portali di terzi, con l'applicazione al seguito.
REGOLA ZERO: mai dati finti
Il principio che governa ogni vista, e che ripetiamo dal primo giorno di sviluppo, è brutale nella sua semplicità: mai dati finti. Nel Vibe Coder le interfacce non sono mai testo generato dal modello: sono viste renderizzate dal server sui dati reali del database dell'agente, a ogni apertura. Il modello produce specifiche, l'infrastruttura produce i contenuti. Se i clienti a Roma sono 47, la tabella dice 47. Non "circa cinquanta", non un numero plausibile: quello vero. La chiamiamo allucinazione zero, e non è una promessa di buon comportamento: è un vincolo architetturale. Il modello non ha il compito di ricordare i dati, quindi non può sbagliarli.
Anche il modello deve sapere la verità
C'è poi un problema speculare, che chiunque abbia integrato modelli linguistici ed esecuzione di operazioni conosce bene: quando il sistema esegue un'operazione sui dati e mostra il risultato all'utente, il modello che ha generato la richiesta normalmente non lo viene a sapere. Ha lavorato alla cieca.
Facciamo l'esempio dei 47 clienti. L'utente chiede "quanti clienti ho a Roma?", il sistema esegue l'operazione sui dati veri, l'utente vede 47. Ma se il modello non ricevesse quel risultato, alla domanda successiva ("e quanti di questi hanno ordinato questo mese?") ragionerebbe su supposizioni, e potrebbe tornare a inventare. Per questo il sistema lavora su due canali: il risultato va all'utente, in forma leggibile e curata, e va anche al modello, in forma strutturata, entrando nella sua memoria di lavoro. E quando l'utente esplora le interfacce, il dialogo continua: apre la scheda di un cliente, e l'interfaccia lo dice al modello, passandogli quel dato reale in forma invisibile. Da quel momento il modello sa quali dati esistono davvero e cosa l'utente sta guardando, e i follow-up poggiano su fatti, non su probabilità. È la separazione tra layer di presentazione e layer di contesto: l'umano riceve la presentazione, il modello riceve la struttura.
Un beneficio collaterale: costi e privacy
Questa architettura ha due conseguenze che di solito si scoprono solo in produzione. La prima riguarda i costi: le viste renderizzate dal server non transitano dal contesto del modello, quindi una tabella da migliaia di righe non consuma token e non satura la finestra di contesto. La seconda riguarda la privacy: le viste possono essere filtrate per utente, e i dati filtrati restano filtrati, perché non vengono riversati indiscriminatamente nella memoria del modello. Il modello riceve ciò che serve al ragionamento, non tutto ciò che passa sullo schermo.
Il prompt che evolve, ma governato
"Il prompt si modifica da solo" è il genere di frase che, detta così, farebbe scattare in piedi qualunque responsabile IT. Ed è esattamente per questo che nel Vibe Coder l'evoluzione del prompt è governata.
Il punto di partenza è che un'applicazione costruita in conversazione cresce: nuove entità, nuove viste, nuovi comandi, nuove regole. L'agente deve saperlo, altrimenti dall'inferenza successiva si comporterebbe come se nulla fosse cambiato. Per questo, a fine costruzione, l'agente documenta sé stesso: inietta nel proprio prompt cosa fa l'applicazione, quali viste e comandi esistono, quali regole valgono. Ma lo fa con anteprima, con le differenze visibili riga per riga, con la possibilità di annullare, e con una garanzia precisa: le istruzioni scritte dal proprietario non vengono toccate. Il proprietario resta l'autore delle proprie regole; l'agente aggiorna solo la parte che descrive l'applicazione.
E ogni modifica, che riguardi i contenuti, le funzioni, le viste o il prompt, finisce in un registro con la propria differenza, e può essere riportata indietro. Costruire in conversazione non significa costruire senza memoria: significa costruire con un audit più leggibile di quello di molti progetti tradizionali.
L'agente sa dove vive
Il Vibe Coder da solo, però, non basterebbe a spiegare quello che vediamo succedere nelle conversazioni. La differenza la fa un'idea che attraversa tutta la Suite AIsuru: l'agente conosce la piattaforma in cui vive. A ogni inferenza riceve un manuale operativo aggiornato con le capacità che ha attive e, cosa ancora più utile, con quelle che gli mancano. Se gli chiedi una cosa che richiede un pezzo non ancora attivo, invece di fingere ti propone di attivarlo. "Per mandarti il riepilogo ogni mattina mi serve lo scheduler: lo attivo?"
È qui che il Vibe Coder smette di essere un generatore di applicazioni e diventa un orchestratore. Non lavora da solo. Attiva e coordina gli altri connettori della Suite: la Persistence per i dati, lo Scheduler per le automazioni, la Data Analysis quando servono aggregazioni e conti fatti davvero sui dati e non "a mente" dal modello. E attiva i connettori del catalogo MCP quando l'applicazione deve parlare con il mondo: la posta, i documenti, il gestionale, le API interne. Compresi gli schemi aziendali del tenant, cioè i connettori già preconfigurati dall'azienda con le proprie credenziali, che l'agente preferisce quando esistono: se l'azienda ha già il suo "SharePoint aziendale" pronto, l'agente usa quello, non ne improvvisa uno.
Questa è la nostra visione degli agenti orchestratori, e il motivo per cui insistiamo tanto sulla consapevolezza: un agente può orchestrare la propria infrastruttura solo se sa dove si sta muovendo. Sa cosa c'è, sa cosa manca, sa cosa è permesso. Il contrario dell'improvvisazione.
Un solo gateway, governato
Tutta questa orchestrazione passa da un unico punto: il gateway MCP di AIsuru, il componente che dà agli agenti l'accesso al mondo e che applica le stesse regole a ogni chiamata, di qualunque connettore.
Il gateway governa l'identità: i connettori personali, come Outlook, SharePoint, Google Workspace, ClickUp o il nuovo Work IQ di Microsoft, usano il login individuale, quindi ogni utente vede solo ciò che il suo account può vedere, e l'agente eredita i limiti della persona per cui sta lavorando, senza scavalcarli. Governa le credenziali, cifrate e mai esposte al modello. Governa la trasparenza: ogni connettore ha una pagina informativa pubblica e una privacy policy dedicata. E governa l'audit: le esecuzioni sono tracciate, le costruzioni del Vibe Coder registrate con differenze e possibilità di annullamento.
Il catalogo oggi conta 33 connettori attivabili in un click. Il mondo Microsoft, con Outlook (comprese le caselle condivise e la lettura degli allegati, con estrazione del testo dai PDF e analisi delle immagini), SharePoint in modalità applicativa o con login aziendale per utente, Word ed Excel, Dynamics 365 e Work IQ. Google Workspace al completo: Docs, Sheets, Slides, Drive, Calendar, Gmail. Gli strumenti di produttività come ClickUp, Monday.com e Linear. I database: PostgreSQL, MySQL, SQL Server, MongoDB, Firebird, compresi i gestionali legacy che nelle aziende italiane sono spesso il vero cuore dei dati. I contenuti e il web: Ghost CMS, Wikipedia, il recupero di pagine, la generazione di immagini, la ricerca web che l'agente può attivare da solo. Il mondo business, con Salesforce, n8n, Zapier e il connettore generico OAuth/API con cui si collega qualunque REST aziendale, anche descritta via OpenAPI, senza scrivere un server MCP. E gli esperimenti di frontiera, come il connettore ufficiale di un exchange per il trading assistito, dove ogni ordine richiede la conferma esplicita dell'utente.
Il punto non è la lunghezza della lista. È che per il Vibe Coder ogni voce del catalogo è un mattone disponibile: l'applicazione che nasce in conversazione può leggere le fatture da una casella condivisa, archiviare documenti, interrogare il gestionale, pubblicare contenuti. Con le identità giuste, dentro le regole giuste.
Agenti che parlano con agenti, agenti che diventano servizi
Due connettori della Suite completano il quadro e aprono la parte che ci entusiasma di più per i prossimi mesi.
Con AIsuru Network, un agente può consultare un altro agente AIsuru: cercare nella sua conoscenza, fargli una domanda, riportare la risposta. È la base della collaborazione tra agenti specializzati: l'agente dell'amministrazione che interpella quello del magazzino, l'assistente personale che chiede all'esperto di prodotto.
Con AIsuru Agent Link, il movimento si inverte: ogni agente può essere esposto come server MCP standard, raggiungibile da Claude, da Cursor, da altri agenti, da qualunque client compatibile, con token distinti per la fruizione e per l'amministrazione. L'applicazione costruita in conversazione con il Vibe Coder può così entrare nella toolchain dei vostri clienti e dei vostri partner. Il vostro agente non è più solo un interlocutore: è un servizio.
Cosa ci hanno costruito, davvero
I progetti che citiamo non sono demo preparate per il lancio: sono nati durante i test, alcuni per gioco e alcuni per lavoro, e i più seri sono già in produzione.
Il TimeTracker è il registro ore del nostro team, quello della scena iniziale: form con menu a ricerca dei progetti, timestamp automatici, timesheet accanto alla chat. Il CRM interno è nato con l'onboarding di governance completo, la pipeline dei contatti e le viste filtrate per utente. Il sistema di ticketing ha il layout pubblico con avvio automatico: il cliente apre il link, compila, e ritrova i propri ticket nella scheda "I miei ticket".
Poi ci sono i progetti dei tester, che ci hanno insegnato quanto il meccanismo sia generale. Un archivio personale di anime con le copertine caricate da form, le card visuali e le schede arricchite dalle ricerche web che l'agente attiva da solo, il tutto con un brand personalizzato. Una todo list con vista calendario e il pannello che occupa metà schermo. Una rassegna quotidiana di notizie sull'intelligenza artificiale, popolata ogni notte da un'automazione, con la tabella dei link alle fonti.
E i flussi aziendali. Il registro delle riunioni del team, con i promemoria email automatici prima di ogni incontro e la deduplicazione degli avvisi. La revisione di documenti su template aziendali protetti, con lo stato della pratica in Persistence. L'approvazione delle fatture per un cliente enterprise: l'agente legge gli allegati che arrivano in una casella condivisa, estrae il testo dai PDF e alimenta il flusso di approvazione. Le attestazioni formative gestite da un agente con login aziendale, incorporato via web component nel portale di un'altra organizzazione. E un esperimento di assistenza al trading che legge saldi e mercati, propone operazioni e le esegue soltanto dopo conferma esplicita.
La varietà è il punto. Non abbiamo costruito un template di CRM o un template di ticketing: abbiamo costruito il meccanismo con cui l'applicazione giusta emerge dalla conversazione con chi la userà.
Per le aziende: la fiducia è un requisito, non una feature
Se lavorate in un'organizzazione strutturata, probabilmente avete letto fin qui con una domanda in testa: tutto molto bello, ma come lo governo?
La risposta attraversa tutto l'articolo, e vale la pena raccoglierla. La governance è default-deny: finché il proprietario non definisce le regole, nessuno costruisce e nessuno vede i dati degli altri. Le identità sono individuali sui connettori personali: l'agente lavora con i permessi della persona, non con un passe-partout. Le credenziali sono cifrate e non transitano mai dal modello. Ogni modifica è registrata con la propria differenza ed è annullabile. Ogni agente vive con il proprio database e le proprie risorse, isolato dagli altri; e dove la compliance richiede una separazione ancora più forte, l'architettura prevede l'isolamento completo dell'applicazione, fino a infrastrutture dedicate per singolo agente. Gli agenti si possono incorporare in portali esterni mantenendo il login aziendale. E tutto questo si innesta sul percorso di conformità che Memori ha già costruito, con le certificazioni ISO, tra cui la ISO/IEC 42001 sui sistemi di gestione dell'intelligenza artificiale, e la conformità NIS2.
C'è un modo semplice di riassumere la filosofia: l'orchestrazione senza governo è il far west; il governo senza orchestrazione è la paralisi. Il punto di questa architettura è tenerli insieme.
Patent pending
Sull'architettura che rende possibile tutto questo, Memori ha depositato una domanda di brevetto per invenzione industriale. È una scelta che racconta come consideriamo questo lavoro: non una funzionalità in più, ma un modo diverso di far convivere i modelli linguistici con l'esecuzione su dati reali. Dei contenuti della domanda non parliamo, per le ragioni ovvie di ogni procedimento in corso: la domanda seguirà la sua strada e parlerà da sola a tempo debito. Quello che possiamo mostrare fin da subito è il risultato, ed è tutto in questo articolo, e soprattutto in una demo.
Domande frequenti
Serve saper programmare? No. Il Vibe Coder esiste esattamente per questo: la costruzione avviene in conversazione, e le domande dell'onboarding sono domande di business, non tecniche. Chi sa programmare apprezzerà quello che succede sotto; chi non sa programmare non se ne accorgerà.
Dove stanno i dati della mia applicazione? In un database dedicato e isolato del vostro agente, che nasce vuoto e si popola solo attraverso l'interazione. Non in un database condiviso con altri, non nel modello.
L'agente può sbagliare una modifica? Può proporla, e per questo esistono l'anteprima, le differenze visibili e l'annullamento. Ogni modifica è registrata; ogni modifica è reversibile. E le istruzioni scritte dal proprietario non vengono mai toccate dall'evoluzione automatica del prompt.
Le interfacce possono mostrare dati inventati? No, per architettura: le viste sono renderizzate dal server sui dati reali a ogni apertura. Il modello non genera i contenuti delle interfacce.
Posso collegare i miei sistemi aziendali? Sì, in tre modi: con i 33 connettori del catalogo, con gli schemi preconfigurati del vostro tenant, o con il connettore generico OAuth/API per qualunque REST aziendale, anche descritta via OpenAPI.
Sostituisce gli sviluppatori? Sposta il loro tempo. Le applicazioni operative da giorni-uomo, i registri, i flussi, gli archivi, nascono in conversazione; le persone che scrivono software tornano a occuparsi dei problemi in cui il software è il prodotto, non la burocrazia del processo.
Quanto ci vuole? L'attivazione è un click. La prima applicazione, dall'"iniziamo" al pannello funzionante, si misura in minuti. Ed è operativa da subito, senza deploy.
Come iniziare oggi
AIsuru Vibe Coder è disponibile da oggi nel catalogo connettori di AIsuru, accanto agli altri cinque connettori originali della Suite: Persistence, Scheduler, Data Analysis, Network e Agent Link. Si attiva con un click. Poi si apre la chat del proprio agente e si scrive "iniziamo": l'onboarding fa il resto, domande di governance comprese.
Se invece volete vederlo lavorare sui vostri processi, con i vostri dati e le vostre regole, scriveteci a demo@memori.ai con oggetto DEMO SUITE: organizziamo una demo personalizzata.
Un agente che risponde è un assistente. Un agente che costruisce, dentro regole chiare e senza mai inventare un dato, è un collega. Da oggi potete assumerlo.