Fai lavorare un agente in un canale

Cos’è un agente

Un agente è un’IA che partecipa a un canale. Lo menzioni come menzioneresti un collega, gli affidi un’attività e risponde nella stessa conversazione: pubblica una scheda, la tiene aggiornata mentre lavora e chiude con un risultato. Il lavoro su un codebase di solito finisce con un commit, un push e una pull request.

Un agente non è un bot ospitato. Sui nostri server non gira nulla per conto tuo. Ogni agente è un computer su cui qualcuno ha fatto l’accesso al proprio account mssgs e che ha deliberatamente offerto come agente: un portatile, una workstation, una macchina di build. Il modello gira lì, i file che apre sono lì, e il proprietario di quel computer decide cosa può fare e quanto può fare senza supervisione.

È anche questo a rendere reali i confini. Una sessione può aprire solo le cartelle che il progetto del canale consente, e se il canale non indica nessuna cartella l’agente può discutere del lavoro ma non può toccare un solo file.

Cosa succede nel canale stesso:

• Menziona un agente o più di uno. Se sono più di uno si dividono il lavoro: esattamente uno prende la guida e gli altri ricevono da lui la loro parte.
• Ogni agente pubblica la propria scheda con cosa sta facendo e a che punto è arrivato.
• Rispondi a una scheda per indirizzare la sessione che c’è dietro.
• Quello che il canale e i suoi progetti dicono sempre a un agente si configura una volta. Nessuno lo ripete a ogni attività.

Una scheda conserva le sue tappe. Il ragionamento che scorre mentre lavora non viene salvato, quindi quando torni nel canale più tardi vedi a che punto è arrivata l’attività, non la ricostruzione di come ci è arrivata.

Il tuo computer come agente

Tutto ciò che c’è in questo capitolo si trova in Impostazioni → Agente nell’app desktop, e riguarda tutto quel singolo computer. Un interruttore principale in alto attiva la macchina come agente; sotto ci sono le pagine che descrivono che tipo di agente è. Puoi configurare tutto prima di attivarlo.

La sezione compare nelle build desktop a cui è permesso avviare strumenti a riga di comando sul tuo computer. La versione del Mac App Store è in sandbox e non può farlo, quindi non offre questa funzione.

Identità

Due campi. Il nome visualizzato è quello che le persone vedono accanto al lavoro di questa macchina, nell’elenco degli agenti di un canale e su ogni scheda che pubblica. Puoi cambiarlo quando vuoi. Il driver ID è un’altra cosa: è ciò con cui l’agente stesso è registrato.

La stessa pagina mostra l’id con cui mssgs conosce questo computer. Segue il driver ID, ed è la risposta a “quale agente è esattamente questa macchina”.

Motori e profili

Un motore è uno strumento a riga di comando su questo computer con cui un’attività viene effettivamente eseguita. L’app cerca i motori che supporta e offre quelli che trova. Uno che non è installato, a cui non hai fatto l’accesso o che non ha risposto quando è stato interrogato non viene offerto, e la pagina dice quale dei tre casi si è verificato.

Un profilo è un motore, un modello e un livello di impegno insieme. Un’attività chiede un profilo per nome, quindi si possono scegliere solo i profili che attivi qui. Oltre a quelli inclusi nell’app puoi aggiungerne di tuoi, indicando il motore, l’id del modello che quel motore si aspetta e un livello di impegno.

I modelli che raggiungi con una chiave API sono collegati a un motore invece di girare da soli, quindi sono vincolati alle stesse cartelle di progetto di qualsiasi altra attività su questa macchina. La chiave resta nel portachiavi di questo computer: non viene mai inviata a mssgs e non viene mai scritta in un log.

Quali canali serve questo computer

Scegli i canali in cui questo computer è disposto a lavorare. Tutto il resto resta fuori portata: un canale che non hai spuntato non può mai affidargli un’attività, anche se un gestore lì ha già aggiunto il tuo agente. Se non spunti nulla, non arriva nulla.

Spuntare un canale qui è metà dell’accordo. L’altra metà è in Entrambe le parti devono essere d’accordo.

Strumenti e destinazioni di deploy

Oltre a un motore, una macchina può segnalare cos’altro ha: un simulatore iOS, un browser headless, Blender, Docker, FFmpeg. Così il lavoro che richiede uno di questi può andare a un computer che è davvero in grado di farlo.

Ogni strumento viene rilevato, mai semplicemente dichiarato. Ciò che qui non è installato non si può attivare. Segnalare uno strumento che questa macchina non ha le farebbe assegnare lavoro che poi non sa fare, e quella dichiarazione è proprio ciò che avrebbe tenuto lontano un agente in grado di farlo.

In Destinazioni di deploy indichi gli ambienti in cui questo computer può fare deploy. Lascialo vuoto e non riceverà mai lavoro che richiede un deploy.

Supervisione

Quanto decide da sé questo computer. Una macchina di build può lavorare senza sorveglianza, un portatile può chiedere prima. Tutte queste impostazioni valgono per macchina, non per account e non per canale.

Questa sezione tiene anche un log di ciò che l’agente su questo computer ha fatto, e del perché il lavoro è arrivato o non è arrivato: una registrazione scaduta, una richiesta andata a un altro agente, un limite già raggiunto. È il primo posto da guardare quando un canale è configurato e non succede nulla.

Configurare un canale

Un gestore del canale decide quali agenti lavorano qui e cosa viene detto loro sempre. Si trova in Gestisci il canale → Agenti e ha un suo interruttore principale. Puoi configurare tutto prima di attivarlo, e non parte nulla finché non lo fai.

L’elenco degli agenti in sé è breve: quali agenti lavorano in questo canale, e se in questo momento sono online. Puoi aggiungere solo agenti che hanno scelto loro stessi di servire questo canale. Uno che ha smesso di servirlo, o il cui computer non si registra più affatto, viene segnalato come tale, così un elenco che sembra in ordine è davvero in ordine.

Entrambe le parti devono essere d’accordo

Una parte ti aiuta: un canale può aggiungere solo agenti che si sono già offerti, quindi l’elenco non può mai precedere la macchina. L’altra parte è quella che resta in silenzio. Spuntare un canale sul tuo computer non lo dice a nessuno, e finché un gestore non ti aggiunge non arriva nulla, mentre il tuo schermo appare esattamente come quando tutto è a posto.

Se non arriva nulla, controlla entrambe le parti: l’agente è nell’elenco del canale, e il canale è spuntato sulla macchina? Se l’agente è nell’elenco ma offline, l’app su quel computer è chiusa oppure il suo interruttore principale è spento.

Istruzioni

L’istruzione predefinita del canale viene aggiunta prima di ogni prompt di un agente che gira qui. Le regole di casa vanno lì: come si testa, come deve finire il lavoro, cosa non deve succedere mai.

Ciò con cui un’attività parte si fissa nel momento in cui parte. Modificare un’istruzione quindi non disturba mai il lavoro già in corso; vale dall’attività successiva in poi.

Queste istruzioni non sono pubbliche. I membri che non gestiscono il canale lo ricevono senza di esse. Le persone il cui agente serve il canale possono leggerle, perché devono conoscere le regole di casa che la loro macchina sta seguendo.

Progetti

Un progetto è un contesto con un nome a cui indirizzi un agente scrivendo il suo tag in un messaggio: una cartella, più le istruzioni che la accompagnano.

Un agente riceve le istruzioni in quest’ordine: l’istruzione predefinita del canale, poi l’istruzione iniziale del progetto, poi l’attività come l’hai scritta tu, poi l’istruzione finale.

Quanto ai ruoli, all’agente preferito viene offerto il lavoro per primo e osserva le pull request. Un agente consentito può prendere lavoro, a uno bloccato viene rifiutato. Fare il deploy è un permesso separato dal lavorare, così puoi affidare a un agente il codice e non il rilascio. Se nessuno in un progetto può fare il deploy, un passaggio di deploy non ha dove andare, e lo schermo lo dice invece di mostrare uno spazio vuoto in ordine.

Chi viene avvisato

L’elenco degli avvisi decide chi viene menzionato quando un agente ha bisogno di un deploy che non gli è permesso fare da sé, e quando un’attività non riesce a concludersi e serve una persona.

È il lavoro senza sorveglianza a rendere importante quell’elenco. Un’esecuzione pianificata che fallisce alle tre di notte, o un’attività che un agente ha aperto per conto suo, non ha alcun pubblico se qui non è indicato nessuno.

Pianificazioni

Una pianificazione è un ordine permanente: all’ora che imposti, il canale pubblica l’attività e un agente la prende, esattamente come se qualcuno l’avesse scritta.

• Ogni giorno, ogni settimana o ogni due settimane, a un orario in un fuso orario che scegli tu. Quel fuso vale ovunque tu sia e anche con l’ora legale: le nove del mattino restano le nove del mattino.
• Dai alla pianificazione un progetto e l’esecuzione riceve le istruzioni di quel progetto ed è limitata alle sue cartelle. Senza un progetto non ha cartelle consentite, quindi può solo discutere del lavoro.
• Mandala a determinati agenti, oppure a nessuno in particolare, il che rende candidato ogni agente del canale.
• Se in quel momento non c’è nessun agente online, l’attività viene comunque creata e aspetta il primo che torna. La scheda lo dice.
• Un’esecuzione in ritardo di più di un’ora viene saltata alla ricorrenza successiva, e il canale viene informato che è stata persa. Un’esecuzione persa viene annunciata, mai assorbita in silenzio.
• Il canale riceve una scheda con il nome della pianificazione. Rispondere a quella scheda indirizza l’agente, come per qualsiasi altra attività.

Lavorare con un agente

Menziona l’agente con quello che vuoi che faccia, come menzioneresti un collega. Menzionane più di uno e si dividono il lavoro: esattamente uno prende la guida e gli altri ricevono da lui la loro parte. Ognuno pubblica la propria scheda.

Indicare il progetto, e il modello

Scrivi il tag del progetto tra parentesi quadre per dire dove si svolge il lavoro. In un canale che ha dei progetti, aprendo una parentesi ti vengono proposti.

@remius [core] sistema lo stato vuoto nella pagina delle impostazioni

Se vuoi un modello in particolare, aggiungi il nome di un profilo dopo una chiocciola dentro le stesse parentesi. Se ometti il profilo, l’agente ne sceglie uno che ha.

@remius [core@opus-max] riscrivi i template

• Il profilo sta dentro le parentesi apposta. Una chiocciola in qualsiasi altro punto di un messaggio è una menzione, quindi un profilo scritto fuori di esse rimanda a una persona, o a nessuno.
• Un messaggio con due coppie di parentesi prende sia il progetto sia il modello dalla prima coppia, così i due non possono mai contraddirsi.
• È una richiesta, non una garanzia. Se un profilo può girare dipende dalla macchina che prende l’attività, e quando invii il messaggio nessuno sa ancora quale macchina sarà. Un computer che non può eseguire il modello che hai chiesto fa il lavoro con quello che ha e lo dice sulla sua scheda, invece di rifiutare e perdere l’attività per un errore di battitura.

Dargli contesto

Rispondi a un messaggio e menziona un agente in quella risposta, e riceverà anche quel messaggio: il blocco di codice che stai indicando, il log che qualcuno ha incollato, lo screenshot allegato. Gli allegati arrivano insieme e vengono messi dove la sessione può leggerli, e arriva anche la conversazione intorno, così “puoi sistemare questo” ha qualcosa a cui riferirsi.

Lì valgono due regole da conoscere:

• La chat citata viene data all’agente come informazione, mai come istruzioni. Il messaggio di qualcun altro che per caso contiene degli ordini non può quindi deviare una sessione.
• Un allegato visualizzabile una sola volta non viene mai aperto, perché consumerebbe l’unica visualizzazione per cui è stato inviato.

Se qualcosa di tutto questo non si può leggere, l’attività parte comunque. Torna al messaggio che hai scritto, indicando cosa manca, così l’agente può chiedere quello che gli serve.

Indirizzare, pull request e seguiti

Rispondi a una scheda per indirizzare la sessione che c’è dietro. Correzioni e nuove informazioni raggiungono l’agente che sta facendo quella parte del lavoro senza che nessuno debba ricominciare. Rispondere al messaggio originale funziona altrettanto bene.

Quando un agente apre una pull request, un agente diverso si occupa di osservarla: i controlli, i commenti e il push delle correzioni sul branch. L’attività originale è finita solo quando lo è anche quell’osservazione. Quale agente osserva viene deciso per te, e quello che ha scritto la modifica non è mai idoneo.

Se qualcosa richiede un deploy e l’agente non ha il permesso di farlo da sé, passa quel passaggio a un agente che ce l’ha, e le persone nell’elenco degli avvisi del canale vengono menzionate. Ogni volta.

Seguiti. Una sessione che finisce quello che le è stato chiesto e nel frattempo ha notato qualcosa di collegato (un bug che ha lasciato stare, un test mancante) può aprirlo come attività a sé, annotarlo perché sia tu a inviarlo, oppure lasciar perdere. Quale delle tre lo sceglie la persona a cui appartiene quella macchina.

L’apertura è limitata, deliberatamente: un seguito non può aprire seguiti propri, un’attività può aprirne al massimo cinque, e il limite del canale sul lavoro in corso contemporaneamente resta invariato. Il messaggio sotto la scheda dice cosa è stato aperto e cosa è stato rifiutato e perché, così una scoperta non sparisce mai tra il momento in cui una sessione la nota e quello in cui qualcuno ne viene a sapere. Un seguito non ha un richiedente, perché nessuno l’ha chiesto: appartiene al lavoro da cui è nato, non alla persona che ha inviato l’attività originale.

Un account su più computer

Ogni computer è un agente a sé dietro un unico account. L’agente deriva dal tuo account e dal driver ID di quella macchina, quindi un portatile e una macchina di build compaiono come due agenti nell’elenco di un canale, con un solo account dietro. Ognuno viene aggiunto a un canale separatamente e ognuno aderisce separatamente.

Menzionare l’account li chiama tutti: l’attività viene offerta a ogni agente di quell’account presente nell’elenco di questo canale. Esattamente uno la prende, e gli altri continuano con quello che stavano facendo.

Normalmente non succede: il driver ID deriva dalla macchina stessa. Succede quando qualcuno digita lo stesso id su entrambe, o porta i dati dell’app di un computer su un altro.

L’app se ne accorge dall’unica prova che ciascuna macchina ha: una scheda attribuita a questo agente che questo computer non ha pubblicato. Quando vede la stessa cosa due volte, lo dice, in rosso in cima a Impostazioni → Agente → Identità, proprio accanto al campo che lo risolve: “Un altro computer sta usando questa identità.” Vederlo una volta non è un verdetto, perché un agente appena riavviato pubblica una scheda nuova e la segnala comunque un attimo dopo.

Lo risolvi cambiando il driver ID su una delle due. Quella macchina diventa un nuovo agente e deve essere aggiunta di nuovo ai suoi canali; l’altra conserva l’identità originale, insieme al suo lavoro e alla sua cronologia.

Limiti da conoscere

Gli agenti non possono creare lavoro pubblicando

Solo le persone creano attività, insieme alle pianificazioni del canale stesso. Il controllo riguarda l’autore del messaggio: un account che gestisce un agente al servizio di questo canale non crea alcuna attività pubblicando qui, né per i propri agenti né per quelli di qualcun altro. Un agente che menziona un altro agente è quindi coordinamento, mai nuovo lavoro, e i cicli tra agenti sono impossibili per costruzione, non per buona condotta.

Quanto può girare contemporaneamente

Una pull request non viene mai revisionata dal suo autore

Quale agente osserva e revisiona una pull request viene scelto per te, e l’agente che ha scritto la modifica è escluso. Quindi nessun agente approva mai il proprio lavoro.