Esplorare il design del Super-agent: verso un sistema di agent più autonomo

1. Super-agent

Nell'ultimo anno gli agent a compito singolo — i coding agent in primis — hanno dimostrato che i modelli sanno usare strumenti per risolvere problemi complessi, con sempre meno monitoraggio umano continuo e intervento passo-passo. Nel frattempo la capacità di coordinare più agent cresce, rendendo fattibile l'organizzazione e il dispatch tra sessioni. Man mano che la partecipazione umana all'esecuzione si riduce, il ruolo della persona sale verso decisioni e accettazione di livello più alto.

Questo salto di capacità ha generato nuove forme d'uso. Recentemente i personal agent sono sbocciati: collegati a messaggistica, calendari, email e piattaforme di lavoro, osservano il flusso di informazioni e aiutano a sbrigare le faccende. Questa modalità continuamente online ed event-driven non è limitata allo scenario personale — l'assistente personale è solo una classe di applicazione; in scenari commerciali come lo sviluppo software vale altrettanto.

I design mainstream, però, faticano a sostenere questa modalità su scala multi-compito e collaborativa. Il lavoro degli agent è ancora organizzato per sessioni singole, tra loro indipendenti. Chi porta avanti più sforzi in parallelo deve passare a mano da una all'altra e ricordarsene il contesto — e, osserva il team, una persona segue in media solo 3-5 sessioni attive. In questo design il tetto del singolo compito è la capacità del modello; il tetto del multi-compito è l'attenzione umana.

Estendere un agente locale mono-sessione con CLI, MCP o connettori esterni gli fa ricevere messaggi dall'esterno, ma resta vincolato dal blocco sincrono della sessione unica, dal contesto multi-compito confuso e dal fatto che il dispositivo offline ferma tutto — con molto manutenzione manuale.

Per superare questi limiti occorre sciogliere il legame tra agente e singola sessione manuale, facendone un'entità continua che mantiene il contesto tra sessioni e porta avanti più compiti complessi in parallelo senza interferenze. Il team chiama questa forma — e la sua architettura — Super-agent.

Nell'istanza interna su DeepSeek Harness, ad esempio, uno stesso compito di sviluppo avanza in modo continuo tra IM e GitHub; l'istanza osserva anche i feedback nei gruppi pubblici e, senza essere @-menzionata, individua la causa radice e apre una pull request di fix.

In concreto, il Super-agent ha quattro proprietà fondative:

• Continuo: l'utente interagisce nelle superfici familiari — chat IM, commenti GitHub — e percepisce un solo agente sempre presente, senza chiedersi "il fatto Y stava nel contesto della sessione X?". Può proporre il piano A in IM e passare al piano B in un commento di PR, e l'agente capisce e si adegua.
• Efficiente: interazione reattiva mentre più compiti complessi procedono in parallelo con qualità; accetta il prossimo comando senza attendere la fine del precedente.
• Proattivo: non attende istruzioni una a una; osserva gli eventi dell'ambiente e procede su ciò che merita, restando in silenzio quando non serve intervenire.
• Persistente: sempre online, collegato agli ambienti di lavoro reali, con auto-ripristino dalle anomalie nella corsa di lunga durata.

Un singolo ReAct loop non può sostenere le quattro proprietà insieme: serve un'architettura sotto. Vincoli simili producono scelte architetturali simili. Che si tratti di un assistente personale o di un agente commerciale di sviluppo, un sistema continuamente online e concorrente sugli eventi convergerà su fondamenta analoghe. E molti problemi qui somigliano da vicino a problemi classici dei sistemi distribuiti, quindi il pensiero sistemistico classico si applica direttamente.

Nella pratica la architettura ha varianti, ma cinque moduli formano lo scheletro: un'architettura a due livelli (sez. 2) per continuità ed efficienza; event-driven (sez. 3) per la proattività; interazione umana (sez. 4) continua ed efficiente nell'interfaccia; separazione di calcolo, stato e ambiente (sez. 5) e un Watchdog (sez. 6) per la persistenza cross-device e l'auto-guarigione.

2. L'architettura a due livelli

Per avere interazione continua cross-canale e concorrenza multi-compito insieme, l'organizzazione delle sessioni affronta un trade-off radicale tra continuità e throughput.

Se ogni evento passa a un'unica sessione, il contesto è massimamente continuo, ma la velocità seriale del ReAct loop impone tempi lunghi e throughput basso, e i dettagli intermedi di più compiti si mescolano peggiorando la qualità.

Se ogni evento apre una sessione indipendente, il throughput concorrente è massimo, ma se i compiti non sono del tutto indipendenti l'assenza di contesto globale frantuma i risultati, e più sessioni che rispondono ciascuna per conto suo generano caos.

Per bilanciare, si separano "mantenere la continuità globale" ed "esecuzione concorrente" in due livelli: un livello Router residente (2.1) che riceve tutta l'interazione umana e il coordinamento globale, e un livello Worker a contesto isolato (2.2) che esegue i compiti in concorrenza.

Con questa divisione il sistema assume in basso la gestione del contesto e dell'esecuzione concorrente, sfumando la sessione agli occhi dell'utente: davanti c'è sempre un solo Super-agent. Visto così, far gestire le sessioni a mano all'utente è in gran parte inerzia progettuale ereditata dalle API LLM; la sessione dovrebbe essere un dettaglio implementativo, non un carico cognitivo.

"Due livelli" è una divisione logica di responsabilità; ciascun livello non deve essere una sessione singola e può avere struttura interna propria. Seguono i due livelli.

2.1 Il livello Router

Il Router è il livello di routing globale residente che riceve tutta l'interazione umana da ogni entry point. Ogni informazione e decisione cross-compito converge qui: punto di sequenza globale, punto di coordinamento e memoria. Per non diventare il collo di bottiglia, il Router non esegue compiti — solo interazione e dispatch; può anche non avere il tool Bash.

Un dispatcher centrale sopra più esecutori ricorda superficialmente un Agent Team, ma l'enfasi differisce. Un Agent Team serve a decomporre i passi dentro un compito complesso; i sotto-passi sono accoppiati, quindi il lead deve capire a fondo il compito, pianificare i sotto-task e coordinare i membri ad alta frequenza — carico di ragionamento pesante. Nel Super-agent il Router gestisce solo le associazioni di alto livello tra compiti e il dispatch. Viceversa, se si vincola via prompt la sessione principale di un Agent Team a non eseguire mai nulla di proprio — solo interfaccia esterna e assegnazione ai membri — anche quella diventa questa architettura. In pratica i compiti del Router sono spesso meno complessi del previsto, e un modello leggero bilancia bene velocità e qualità.

Anche internamente il Router non deve essere una sessione sola; parti della logica potrebbero non chiamare alcun LLM. Il team ha scelto il nucleo più diretto — una sessione LLM residente — scoprendo che non è così facile da mandare in collo di bottiglia, perché gli eventi d'ambiente (i Trigger della sez. 3) arrivati durante un turno di inferenza si accumulano e vengono processati insieme al turno successivo, formando il batching, il cui sovraccosto è piccolo:

• Con il flusso di eventi calmo, i Trigger entrano uno alla volta e la latenza resta bassa.
• Quando gli eventi si affollano e la coda cresce, i Trigger accumulatisi durante il turno precedente si fondono da soli e vengono iniettati insieme nella chiamata LLM successiva. I passi del Router sono tipicamente input lungo, output corto; fondere più Trigger in una chiamata parallelizza il prefill, e la latenza per richiesta cresce molto più lentamente della dimensione di batch. Entro un certo range, più backlog, meno tempo di inferenza per decisione — con il limite di finestra di contesto e di quanti Trigger il modello gestisce con accuratezza in un turno.

La sez. 7.2 quantifica il batching. Insieme a sottoscrizione/pass-through e chain of recall (3.2, 3.3), una singola sessione Router residente basta alla scala attuale del team.

Oltre certa scala, il Router può adottare una struttura interna a filtri multipli o sharding orizzontale in più sessioni. Il design interno del Router diventa esso stesso un trade-off continuità-throughput: shard più fini alzano la concorrenza ma abbassano la continuità di memoria tra frammenti. Finché la memoria globale non è risolta, il trade-off resta.

2.2 Il livello Worker

I Worker sono le sessioni di esecuzione: contesto mutuamente isolato, completo di strumenti, ciascuna concentrata su un solo compito. Poiché determinano risultati e qualità del codice, i Worker vogliono in genere il modello più capace.

I Worker non parlano con gli umani; ragionamento e chiamate a tool non finiscono sui canali esterni. Riportano lo stato al Router, che risponde all'utente per tutti — qualità e concorrenza senza il caos di risposte multiple.

In multi-compito, i Worker avanzano indipendenti e di norma non comunicano tra pari. I conflitti nascono di solito in ambienti condivisi, come la stessa pull request; se entrambi sottoscrivono il Thread (3.2), ricevono gli stessi eventi e possono scoprire e risolvere i conflitti da soli, con il Router a inoltrare le poche coordinazioni cross-compito.

Come il Router, un Worker può non essere una sessione singola: dentro un compito complesso può generare subagent o essere esso stesso un Agent Team, in modo trasparente al Router. Vale per la collaborazione su codice — riproduzioni, review e feature in parallelo senza bloccarsi — e per l'assistente personale: una sola finestra di chat che, con più argomenti, mantiene la continuità in superficie mentre sotto assegna un Worker per argomento, avanzando in parallelo e abbozzando le risposte.

3. Event-driven

La proattività comincia col cambiare ciò che guida il sistema. L'input principale non sono i prompt battuti dall'umano in sessione, ma eventi semi-strutturati dall'ambiente. Messaggi di gruppo, promemoria di email e calendario, commenti di review, esiti di CI: tutto questo è Trigger. Rispondendo ai Trigger, l'agente non esegue più una volta per comando come nel mono-sessione.

Attorno al ciclo di vita di un evento, quattro domande progressive: filtrare il rumore con una politica a due livelli programma+modello (3.1); instradare agli worker via sottoscrizione e pass-through (3.2); iniettare e richiamare contesto ad alta densità con Inline & Spill e chain of recall (3.3); agire in anticipo con l'esecuzione speculativa (3.4).

3.1 Filtraggio degli eventi

Collegati a chat reali e piattaforme di codice, i flussi di eventi sono vistosamente "alto rumore, bassa trigger-rate": la maggior parte dei messaggi non richiede l'agente. Giudicare ogni evento con una chiamata al modello è insostenibile in latenza e costo. Preso in prestito il Fast Path / Slow Path dei sistemi, l'inferenza LLM è una Slow Path flessibile ma costosa; fissare in codice deterministico i giudizi chiari e stabili ad alta frequenza dà una Fast Path economica e a bassa latenza.

Il primo passo dopo l'ingresso di un evento è dunque filtrare: scremare il rumore con politiche deterministiche prima di ogni chiamata al modello, passando al modello solo i candidanti che richiedono semantica. Filtro a due livelli:

• Politica a livello programma (Fast Path): ammissioni deterministiche in codice su sorgente, perimetro di gruppo, allowlist di utenti e bot — per sorgente, ad esempio, "rispondi solo a richieste esplicite", "candidato", o "ignora" — eliminando la maggior parte dei messaggi irrilevanti prima del modello.
• Politica semantica (Slow Path): i candidati passati vanno al LLM che, sulla base delle politiche scritte in prompt e del contesto, decide se agire. Il livello semantico è anche il punto d'estensione in linguaggio naturale: attivare o aggiungere politiche è modificare un prompt.

3.2 Instradamento degli eventi

Il Router mantiene la continuità cross-canale, ma se ogni evento successivo di un compito già assegnato passasse ancora da lui, il nodo globale si sovraccaricherebbe e la latenza salirebbe. Fast/Slow Path vale anche per l'instradamento: il Router gestisce solo cold start dei compiti nuovi e coordinamento cross-compito; gli eventi successivi con ownership nota vanno via codice direttamente alla sessione worker.

Nei flussi reali, gli eventi consecutivi sotto una stessa PR GitHub, un topic IM o un thread di email formano un flusso — un Thread. Creato un worker per l'evento iniziale di un Thread, quel worker sottoscrive il Thread, e l'instradamento si biforca:

• Sottoscritto (Fast Path): gli eventi successivi dello stesso Thread vanno diretti al worker sottoscritto, senza inoltri del Router. Se un nuovo evento esce dallo scopo del compito, il worker può annullare la sottoscrizione o restituirlo al Router.
• Non sottoscritto (Slow Path): il Router osserva tutto per consapevolezza globale ma giudica e smista solo gli eventi non ancora sottoscritti.

La sottoscrizione Thread-worker è molti-a-molti: un worker può seguire più Thread correlati, un Thread può avere più worker. Quando più worker si incrociano nello stesso ambiente, i nuovi eventi del Thread arrivano a tutti i sottoscrittori, che apprendono le azioni altrui e risolvono i conflitti senza messaggi punto-a-punto. In uscita, i worker riportano le conclusioni chiave al Router, che risponde all'utente e aggiorna la memoria globale.

3.3 Organizzazione del contesto

Filtrato e instradato l'evento, resta quanto iniettare nella finestra di contesto. Con input passati da prompt umani limitati a eventi semi-strutturati continui, la struttura di iniezione e chiamate a tool conta di più. Troppo riempie la finestra e diluisce l'attenzione; troppo poco moltiplica i giri di lettura. Sprecare la finestra di contesto è sprecare l'intelligenza del modello.

Si gestisca la finestra finita come una cache. Dell'ottimizzazione dei compilatori e dei sistemi, due operazioni bastano: Inline porta direttamente in finestra ciò che servirà presto, risparmiando i giri di tool; Spill lascia fuori dalla finestra l'informazione completa oltre budget o raramente usata, tenendo dentro solo riferimento o sommario da leggere a richiesta.

Col principio di località:

1. Partire dal minimo: solo ID dell'oggetto e un digest del contenuto.
2. Inline per località: prima gli ID degli oggetti strettamente correlati, poi i contenuti vicini nello spazio-tempo — i primi 50 caratteri, i messaggi adiacenti e quello risposto, i commenti adiacenti nella discussione di review.
3. Spill oltre il limite: un tetto piccolo per ciò che non si può inlineare per intero; l'eccesso esce dalla finestra con un punto di ripresa che il modello legge a tool quando serve.

Con molti eventi che passano dritti ai worker e sistemi di lunga durata che accumulano storia, il Router non può tenersi in finestra tutta la storia di ogni compito, ma deve recuperare il contesto quando l'utente riprende un compito vecchio su un altro canale. Applicando Inline & Spill uniformemente agli oggetti di sistema si ottiene il richiamo multi-hop a domanda — la chain of recall — che attenua la perdita di informazioni di lungo periodo del Router.

In concreto, Trigger, Thread e sessioni worker ricevono ID unici, e le iniezioni incorporano gli ID degli oggetti strettamente correlati, formando un grafo di riferimenti. Poiché anche ogni oggetto richiamato a tool segue Inline & Spill, il suo risultato incorpora sommario e ID del salto successivo: dal messaggio corrente si legge il Thread, dal Thread si risale alla sessione worker correlata, e da lì all'altro Thread di review.

3.4 Agire in anticipo

Con l'esecuzione speculativa dei sistemi, l'agente può provare in anticipo su segnali d'ambiente, prima di sapere se il risultato servirà: compute in più dietro le quinte per ridurre attesa e intervento umano. Utile si consegna, inutile si butta.

Per un assistente personale: arrivato l'invito a una riunione o un promemoria, l'agente verifica in background i conflitti d'agenda, raccoglie materiali e prepara la bozza di risposta — l'utente dà un'occhiata e invia. Per l'ingegneria: nel gruppo utenti interno di DeepSeek Harness il team ha configurato una politica "riproduci e correggi in silenzio" — quando qualcuno segnala un problema o discute una modifica, l'agente prova in background a riprodurre e trovare il fix; solo se il problema è confermato e il fix è semplice lo consegna, altrimenti tace dall'inizio alla fine.

4. Interazione con le persone

Il two-tier garantisce la continuità a livello di contesto; per esserlo anche nell'esperienza viva restano due problemi: eliminare il blocco delle operazioni lunghe sul dialogo con un ReAct loop asincrono (4.1), e adattare l'output alla larghezza di banda e alle abitudini di ciascun canale (4.2).

4.1 Interazione full-duplex

Nel ReAct classico, una chiamata sincrona run() blocca il loop fino al ritorno del risultato, e nel frattempo la sessione non risponde a nessun nuovo input. Togliere il blocco significa passare dal half-duplex domanda-risposta al full duplex.

Il team ha reso asincrone le chiamate lunghe con start() e stop(): il ReAct loop asincrono. start() restituisce subito "Started" e il loop non attende; a fine esecuzione il sistema consegna il risultato in sessione come nuovo evento; e il modello può chiamare stop() per i comandi che durano troppo.

Dialogo in primo piano ed esecuzione in background si disaccoppiano: l'agente risponde mentre i task lunghi girano. Il nuovo input è processato subito dopo il passo di inferenza corrente, mai dietro un tool in attesa. Il meccanismo è già in DeepSeek Harness, non ancora attivo di default.

4.2 Interazione multi-canale

I canali differiscono in densità e abitudini, e l'output deve corrispondere. Trapiantare l'interazione da terminale singolo in una chat di gruppo — ragionamenti verbosi e raffiche di chiamate in pasto diretto — produce sovraccarico.

Il two-tier già isola gran parte del problema: ragionamenti e chiamate restano nei worker; il Router parla all'esterno. Sopra, il sistema si collega agli ambienti reali e calibra le norme per canale via prompt:

• Canali IM: comunicazione leggera e a basso disturbo — come un collega che avvisa solo per decisioni o accettazioni, chiede diretto e risponde corto. Una regola dura semplice e validata: mai oltre 100 parole per risposta.
• GitHub, email, documenti (canali asincroni): consegne strutturate e dense — PR scritte secondo le norme di progetto con background, descrizione delle modifiche e verifica; per l'assistente, bozze di email e sommari strutturati.

5. Separare calcolo, stato e ambiente

Gli agent locali legano di default a un solo dispositivo il calcolo che spinge il loop, lo stato di sessione persistente e l'ambiente di esecuzione — repository e toolchain. Il dispositivo dorme o va offline, l'agente si ferma; gli ambienti degli altri dispositivi restano irraggiungibili. Per la persistenza e l'accesso flessibile si prende a prestito la separazione calcolo-storage, in due passi: prima separare il calcolo del loop dallo stato persistente, liberando l'agente dal ciclo di vita della singola macchina (5.1); poi separare il loop cloud dall'ambiente pesante, lasciando gli ambienti reali al loro posto con accesso cross-device (5.2).

5.1 Calcolo e stato

Il calcolo del loop può essere stateless; ciò che persiste è lo stato di sessione. Prima separazione: il loop in container elastici stateless sul cloud, le sessioni in database. I container scalano, si riavviano e si sostituiscono; la continuità la garantisce lo storage persistente — l'agente sfugge al ciclo di vita di una macchina.

5.2 Calcolo e ambiente di esecuzione

Loop e stato sul cloud, resta l'accesso agli ambienti. Gran parte del contesto necessario arriva via tool da repository, file locali e servizi — in senso lato, l'ambiente stesso è contesto.

Due strade comuni: sandbox cloud che tirano il codice e tentano di ricostruire l'ambiente — costoso e fallace, perché gli ambienti reali portano modifiche non committate, credenziali private, dipendenze intranet e hardware o toolchain specifiche; oppure chiedere all'utente di abbandonare il locale per il cloud — costo di migrazione proibitivo per molti.

Se è l'ambiente a non essere copiabile, non si porti l'ambiente sul cloud. Seconda separazione: il loop gira sul cloud, l'ambiente pesante resta dov'è, e sul dispositivo gira solo un daemon leggero senza stato di sessione che esegue comandi e restituisce risultati — l'ambiente fuori dal cloud, letto dall'agente a domanda.

È la "separazione del cervello dalle mani" di Anthropic: harness stateless, log di sessione fuori, ambienti collegati via interfaccia unica. Differisce lo scenario — quel testo descrive servizi gestiti, sandbox on-demand e risorse nel VPC del cliente; qui il primo obiettivo sono le macchine personali d'uso quotidiano, magari intermittentemente online, con modifiche non committate e credenziali locali. Da cui il sostegno al BYOM (Bring Your Own Machine), oltre alle macchine gestite e al calcolo on-demand.

L'agente non è più vincolato a una macchina: sceglie il dispositivo d'esecuzione per compito, esegue dove serve e attinge il contesto da lì. Sostiene perfino i dispositivi intermittenti: quando una macchina personale torna online, l'agente cloud fa scattare e completa ciò che andava eseguito lì.

6. Watchdog

Alla separazione si aggiunga il ripristino automatico: i sistemi long-running difficilmente si reggono solo con la logica interna; serve un circuito di controllo esterno — il Control Loop.

E per gli agent i probe di processo e gli script di monitoraggio non bastano: molte anomalie non sono crash ma loop inutili o derive dal objetivo. Un sistema long-running deve vigilare non solo la vitalità dell'infrastruttura ma il progresso dei compiti.

Il team ha una Watchdog Session indipendente, guidata da messaggi a orologio. Gestisce i guasti d'infrastruttura — errori d'API, recovery falliti — e affida al modello il giudizio sul progresso reale di ogni worker e sulla coerenza con l'obiettivo. Interviene a riparare, e sui guasti transitori ricontrolla finché non passa. Essendo essa stessa una sessione con strumenti completi, i maintainer possono chiederle a voce le cause di un guasto o farle correggere online il comportamento del sistema — prompt aggiunti o tolti, regole di trigger aggiustate.

7. Esperimenti preliminari

Per valutare scheduling e routing, due strati di esperimenti: end-to-end a confronto tra two-tier, sottoscrizione/pass-through e mono-sessione (7.1), e stress separato del batching del Router (7.2). Carichi sintetici e ambienti semplificati: i risultati sono riferimenti preliminari.

7.1 Ablation

Flussi di chat di gruppo e CI GitHub guidano quattro schemi: circa 300 messaggi per run, di cui ~20 richieste di lavoro e il resto chiacchiere, follow-up, annullamenti e CI. Il lavoro di coding è sostituito da un tool che consuma solo tempo: si misura scheduling e coordinamento, non l'esecuzione del singolo compito. Cinque run per schema.

I quattro: Super-agent; Super-agent senza pass-through; sessione singola + tool subagent in due configurazioni di prompt. Prompt neutro: "Use a subagent for a piece of work when appropriate...". Delegate-first: "Every message of the chat reaches you, so work you run yourself keeps stopping for new messages. Prefer handing each piece of work to a subagent of its own, and do only small things yourself..."

Tempi di completamento: p50 e p95 del Super-agent a 12,4 e 15,7 minuti, nettamente meglio della mono-sessione con subagent. La mono-sessione è molto sensibile al prompt: la sessione principale spesso sceglie di eseguire da sé, con tempi lunghi e instabili. Col prompt neutro il subagent non è mai chiamato (5 run su 5): tutto nella sessione principale, interrotto di continuo, p95 a 29,5 minuti. Col delegate-first delega in 4 run su 5 — meglio, ma ancora sotto il Super-agent — e nell'ultima giudica il lavoro "piccolo", lo fa da sé e genera la coda viola del grafico. Invece di affidare a prompt engineering e giudizio al volo se dividere o no il lavoro, il two-tier lo decide strutturalmente: il Router non esegue, i worker ricevono solo i messaggi del Thread sottoscritto.

Costi: mantenere più sessioni costa — i cache-read token per run del Super-agent superano la mono-sessione: più token per tempi più brevi e stabili. Dentro il Super-agent, togliere il pass-through lascia i tempi quasi uguali, ma le decisioni del Router salgono di ~30% e i cache-read token da 23,23M a 31,77M (+37%). Sotto questo carico il pass-through non migliora qualità né velocità: risparmia token e inferenza al Router.

7.2 Batching del Router

Per testare il tetto della sessione Router residente, stress mirato: modello reale per il Router, mock per i worker, tasso d'arrivo dei Trigger da decidere da ~1 a ~40 al minuto, osservando batch medio, latenza per richiesta e inferenza per decisione.

Da ~1 a ~40 al minuto il batch medio sale da 1,0 a 2,8 mentre la latenza cresce solo da 2,5s a 3,9s — meno del batch — e l'inferenza per decisione scende da 6,4s a 1,6s. Sotto picchi di eventi il Router alza il throughput effettivo fondendo il backlog. Spiega perché in 7.1, tolto il pass-through e col picco di carico sul Router, il tetto non è mai stato toccato — dunque, alla scala attuale, niente sharding precoce che sacrificherebbe la continuità del contesto globale.

8. Questioni aperte

Le sezioni 2-6 compongono l'architettura di base; la 7 ne ha validato scheduling e routing sotto carico. Il sistema resta a bassa complessità grazie a semplificazioni deliberale. Oltre il loro perimetro restano aperte: scalare il two-tier (8.1), collaborare dopo le sessioni (8.2), confini di contesto e A2A (8.3), sicurezza e privacy (8.4).

8.1 Scalare il two-tier

"Un Router residente + pass-through + nessuna comunicazione diretta tra worker" copre la maggior parte dei compiti quotidiani a costo ingegneristico contenuto. Oltre la soglia, la struttura interna non ha risposte fisse: quando sharding e con che granularità; quando introdurre comunicazione diretta tra worker e con quale topologia. Il co-design di sistema e modello è un'altra direzione: addestrare specificamente discriminazione degli eventi, dispatch batch e recall del contesto del Router potrebbe alzare throughput e qualità delle decisioni.

Intanto, Router residente + chain of recall su grafo di riferimenti risolve soprattutto il recupero a domanda del recente. Su orizzonti di mesi la memoria di lungo periodo diventa il vincolo principale alla scalabilità.

8.2 Collaborare dopo le sessioni

Nascosta la gestione multi-sessione, la sessione cessa di essere il problema primario del prodotto; ma quando le sessioni d'esecuzione non corrispondono più alle conversazioni visibili, come presentare i compiti e offrire interazione e project management naturali è la nuova domanda. La centralità della finestra di chat è in parte dipendenza dal percorso. L'interazione può spostarsi su superfici specializzate — come negli esempi, il Super-agent che lavora direttamente in issue e pull request. La sessione può restare in superficie per abitudine, ma una conversazione vista non corrisponde necessariamente a una sessione sola.

E il testo ha trattato soprattutto l'umano a inizio e accettazione; nel periodo di transizione delle capacità, molti compiti vogliono partecipazione intermedia — far entrare, prendere in mano o collaborare dal vivo durante l'esecuzione in background è tutto da esplorare. In somma, la forma finale di interazione e project management sarà probabilmente molto personalizzata per dominio e stile; l'architettura aperta di DeepSeek Harness rende facile supportarla.

8.3 Confini di contesto e A2A

Il testo ha trattato un solo instance, assumendo che tutto ciò che rientra nel suo perimetro confluisca in un contesto globale. Da individui e piccoli team a organizzazioni più larghe, decidere quante istanze avere è disegnare i confini di condivisione e isolamento del contesto: chi condivide, condivide istanza; chi isola, istanza propria.

E con più istanze isolate dentro o tra organizzazioni — gli assistenti personali e il Super-agent del team — la collaborazione oltre confine è agent-to-agent (A2A, nessun protocollo specifico). Comunicazione A2A sicura e affidabile tra parti che non condividono contesto e rappresentano permessi diversi resta da esplorare.

8.4 Sicurezza e privacy

L'event-driven espone l'agente a input non fidati. Senza buone risposte su sicurezza e privacy, il Super-agent funziona solo in un perimetro piccolo e fidato.

La sez. 5 — loop sul cloud, daemon leggeri sui dispositivi — presuppone fiducia reciproca tra cloud e endpoint. Ma un loop che insegue eventi esterni, agganciato a macchine con codice privato, dati sensibili e credenziali locali, introduce rischi reali: una compromissione del loop lato server o una prompt injection mettono a rischio il controllo di tutti i dispositivi collegati.

E anche senza compromissione, se le credenziali entrano nel contesto del modello, la fuga è possibile in piena operazione. Servono meccanismi per usare credenziali senza mai toccarle. Per l'adozione ampia, l'architettura deve richiamare contesto da ambienti diversi e risolvere insieme questi problemi.

9. Conclusione

Riletto tutto, il team non ha proposto teorie nuove: ha applicato l'ingegneria classica dei sistemi agli agent. Le implementazioni evolveranno; il pensiero di design sottostante manterrà valore di riferimento. L'istanza interna costruita su queste idee e DeepSeek Harness gira tuttora, partecipando ogni giorno a riproduzione e fix, risposta alle review e all'iterazione di Harness stesso.

Come da apertura: via via che i modelli richiedono meno intervento per compito, il collo di bottiglia della produttività diventa l'attenzione umana. Two-tier, event-driven, interazione asincrona multi-canale, separazione calcolo-storage e Watchdog esterno portano il sistema a farsi carico della gestione di sessioni e sincronizzazione dei contesti, lasciando alle persone decisioni e accettazione.

In questa forma l'agente non è più la finestra che attende istruzioni, ma un collaboratore autonomo sempre online nell'ambiente digitale: per gli individui un assistente cross-device; per i team un partecipante incorporato nel flusso di sviluppo che prende e porta avanti compiti concreti. Con il progresso congiunto di capacità dei modelli e architetture, questo modo di lavorare più autonomo potrà diventare la norma della collaborazione uomo-macchina.

Come da originale: parte del design è implementata in dsh-superagent-prototype; il plugin è un prototipo per validare la rotta tecnica, non un prodotto ufficiale DeepSeek. Autore e ringraziamenti: il testo nasce dalla pratica condivisa del team DeepSeek Harness; Yujia Qiao ha realizzato il sistema e scritto il testo, con Huanqi Cao, Zui Chen, Xieting Chu, Tianyi Cui, Shiyuan Feng, Yudong Han, Kexin Liu, Shichun Liu, Gesi Luo, Yifan Shi, Tongrui Xiong, Hanxiang Xu, C.C. Yu, Ziya Zhang e F. Zhou alle revisioni e alla discussione.

Fonti

• DeepSeek 产品部 (WeChat ufficiale) — il testo originale cinese, 1° nov 2026
• deepseek-ai/dsh-superagent-prototype — il prototipo MIT (README, docs 000–008)
• Riferimenti interni: traduzione inglese integrale · originale cinese · copertura dsh-superagent