Agenti AI come interfaccia: dai wearable alle suite aziendali, tre nodi da risolvere

Zach Yadegari, 19 anni, ha lanciato Persona e raccolto 10 milioni di dollari. Il progetto promette un assistente “sempre attivo” su un bracciale da 179 dollari. Google introduce un agente unico che attraversa Workspace e mantiene il contesto tra dispositivi. OpenAI presenta Dots come agente continuo con “propri computer cloud”. La tesi: gli agenti non stanno più al margine. Diventano l’interfaccia. La sfida si sposta dall’idea alla messa in produzione: orchestrazione, isolamento e controllo degli accessi in tempo reale.

1) Un nuovo ruolo per gli agenti: dove e perché

L’agente entra nei momenti in cui si lavora e si vive. Persona punta al polso. Google lo mette al centro di Gmail, Drive, Docs, Sheets e Calendar. OpenAI parla di un assistente che opera in background e si connette alle app usate ogni giorno. Il comune denominatore è la continuità: l’agente non aspetta il prompt. Prosegue verso un obiettivo, si sposta tra strumenti e recupera il contesto quando cambi dispositivo.

Questa continuità sposta il baricentro tecnico. Non basta un modello capace di rispondere. Serve un’infrastruttura che tenga vive le sessioni, coordini più strumenti e applichi i permessi corretti quando l’agente accede a dati aziendali. È qui che le scelte di architettura contano più del singolo tocco di interfaccia.

2) Wearable e startup: promessa e limiti dichiarati

Persona nasce dopo un’uscita rapida. A marzo Yadegari ha venduto Cal AI, un’app per il conteggio delle calorie, a MyFitnessPal per una cifra non divulgata. Dopo l’acquisizione ha lavorato in MyFitnessPal. A giugno è uscito e ha avviato Persona con un cofondatore non ancora annunciato. Il round da 10 milioni è guidato da Vine Ventures, con la partecipazione di Cory Levy (Z Fellows) e Collective Global.

Il piano è un assistente personale basato su agenti, con un dispositivo da polso “in arrivo” al prezzo di 179 dollari. Yadegari ha detto che l’hardware “differisce in diversi modi” da Bee, citata come riferimento. Non ha condiviso specifiche, funzioni o una data di lancio. Al momento l’unico elemento concreto è il prezzo. Il resto va verificato sul campo.

Qui emerge la prima tensione pratica. Un agente “sempre attivo” su hardware dedicato deve gestire sessioni persistenti, invocare tool esterni e tenere il filo quando il contesto cambia. Senza dettagli su isolamento, aggiornamenti o integrazione con app terze, la promessa resta aperta. Il rischio è spostare la complessità dal telefono a un nuovo dispositivo senza risolvere i nodi di base.

3) Agente unico nelle suite di lavoro: continuità, sub‑agent e controllo del contesto

Google affronta la stessa ambizione in ambiente aziendale. Presenta un agente Gemini “universale”, accessibile dall’app Gemini Enterprise, che lavora in background tra app e dispositivi. Dentro Workspace l’assistente è lo stesso ovunque. Si conversa in un’unica chat. Si chiede l’attività. L’agente la esegue su Gmail, Drive, Docs, Sheets, Calendar, senza cambiare strumento.

L’agente resta accessibile anche fuori da Workspace. Si raggiunge da mobile, desktop e via web. È disponibile in applicazioni di terze parti come Slack o Microsoft 365. Mantiene il contesto quando si passa da un dispositivo all’altro. Si riprende da dove si era, con le stesse informazioni di sessione. Google descrive un’architettura con sub‑agent dedicati a compiti specifici. Un agente principale li coordina. Il sistema sceglie in automatico il modello più adatto al lavoro richiesto. Esegue le richieste nel cloud.

OpenAI inserisce Dots nello stesso quadro di continuità. Dots usa “propri computer cloud”, si collega “alle app che le persone usano ogni giorno” e prosegue “verso un obiettivo in background” senza interventi continui. Alexander Embiricos, product lead di Dots, salirà sull’AI Stage del TechCrunch Disrupt 2026 al Moscone West di San Francisco dal 13 al 15 ottobre, a ridosso dell’annuncio. Il palco mette al centro le frizioni pratiche: controllo, delega, rischi e fiducia quando un’IA resta attiva e agisce mentre l’utente fa altro.

La direzione è chiara. L’agente diventa un servizio che attraversa interfacce e dispositivi, coordina componenti specializzati e conserva il contesto. Questo approccio riduce attriti d’uso. Aumenta però l’area d’impatto su sicurezza e governance.

4) Orchestrazione cloud‑native e accessi dinamici: le condizioni per la produzione

Quando l’agente vive nel cloud, tre fragilità emergono presto: sessioni che si interrompono, esecuzione dei tool senza isolamento e contesto che si disperde tra i passaggi. Craig McLuckie e Joe Beda propongono di trattare gli agenti di coding come carichi cloud‑native, gestiti da control loop e orchestrazione. Obiettivo: affidabilità da produzione per sessioni, tool ed esperienza d’uso, oltre il laptop degli sviluppatori. Il parallelo con i container è diretto: nel 2014 arrivò Kubernetes, open source, sviluppato da Google. È diventato lo standard per distribuire e gestire applicazioni cloud su larga scala, con control loop che tengono vivi i carichi e recuperano gli stati desiderati. Dal 2025 OpenAI e Anthropic riportano l’harness nel cloud proprio per affrontare quei limiti, con esiti diversi ma gli stessi ostacoli di base.

Questo punto tecnico si lega al tema dell’accesso ai dati. Le aziende interrogano basi documentali sensibili con soluzioni RAG. Le risposte devono rispettare i permessi già presenti in sistemi come SharePoint, Google Drive e Confluence. Amazon propone di verificare le autorizzazioni “al momento della domanda”, consultando la fonte autorevole durante la query e filtrando i contenuti in base ai diritti effettivi dell’utente. Indica Amazon Quick insieme alle Knowledge Bases di Amazon Bedrock come combinazione per un enforcement delle ACL in tempo reale. Obiettivo: ogni persona vede solo ciò che può vedere nelle fonti originali, applicando le policy esistenti mentre l’assistente costruisce l’output.

Orchestrazione e controllo degli accessi si tengono. Un agente “universale” o “sempre attivo” che attraversa app e dispositivi deve:

• Persistere lo stato e recuperarlo in caso di cadute di rete o cambi di device.
• Isolare l’esecuzione di tool per contenere effetti collaterali e garantire ripetibilità.
• Applicare le ACL delle fonti durante retrieval e generazione, non a valle della risposta.

Senza questi tre pilastri, la promessa di continuità si scontra con incidenti di sessione, perdite di contesto o esposizioni indebite di dati.

5) Cosa imparano team AI, software e QA

Le mosse di Persona, Google, OpenAI e Amazon disegnano un vincolo operativo. I team che progettano agenti devono trattare l’esperienza utente e l’affidabilità come problemi di sistema, non solo di modello. L’architettura a sub‑agent o l’uso di “propri computer cloud” cambia poco se le sessioni si spezzano o i permessi non si applicano in tempo reale.

Il QA deve aggiornare i casi di test. Servono prove di continuità tra dispositivi, verifica dell’isolamento dei tool e scenari di autorizzazione end‑to‑end sulle fonti aziendali. L’ingegneria deve considerare control loop, osservabilità e riparazione automatica come parti strutturali della piattaforma, in linea con la proposta di trattamento cloud‑native degli agenti di coding.

La scelta tra hardware dedicato e integrazione nelle suite non è neutra. Il bracciale di Persona promette prossimità e presenza. L’agente di Google e Dots puntano su integrazione profonda e continuità nel cloud. In entrambi i casi, i tre nodi restano gli stessi: persistenza, isolamento, permessi. La differenza la farà chi li risolve in modo verificabile, prima del lancio e non dopo gli incidenti.

L’esito pratico è misurabile: meno frizioni, meno regressioni tra passaggi e meno sorprese in sicurezza. Se i prossimi annunci parleranno di control loop, sessioni resilienti e ACL applicate “al momento della domanda”, non sarà lessico da addetti ai lavori. Sarà il segnale che l’agente, finalmente, regge il carico della quotidianità.