Gli agenti gestiti ora rispondono all'Harness

Alle quattro del pomeriggio, la sessione Claude Code di uno sviluppatore apre una sessione di lavoro sulla Billing API per aggiungere il calcolo pro rata ai cambi di piano. Venti minuti dopo, mentre quella sessione sta ancora lavorando, un'esecuzione pianificata di Archyl sul profilo backend-fixer prende in carico un ticket sull'arrotondamento delle fatture, che vive anch'esso nella Billing API.

Fino a questa settimana, ecco cosa faceva l'esecuzione pianificata. Apriva la propria sessione di lavoro, come già facevano le esecuzioni gestite. Il gate di preflight restituiva warn, con il motivo 1 target element(s) are being worked on by other active sessions — coordinate before changing them. Quel verdetto compariva nel feed degli eventi dell'esecuzione. Poi l'esecuzione partiva comunque, perché niente agiva sul verdetto, e nessuno stava seguendo un'esecuzione pianificata con cui coordinarsi.

Preferisco dirlo chiaramente: per le esecuzioni in hosting, l'involucro era perlopiù cosmetico. Il gate veniva mostrato e ignorato. I file modificati dall'agente non venivano mai ricondotti alla sua sessione, quindi la memoria finiva sugli elementi che il testo del task menzionava per caso. E la sessione si chiudeva con un riepilogo di una riga, che lasciava al prossimo agente ben poco da imparare.

Questa settimana è cambiato. L'harness ora guida le esecuzioni gestite, e le esecuzioni in hosting e gli agenti di coding locali si coordinano sullo stesso modello.

Far girare un agente sta diventando la parte facile

Tre dei nomi più importanti del settore offrono ormai un posto in hosting dove far girare gli agenti. La documentazione di Anthropic descrive Claude Managed Agents come "un harness per agenti già pronto e configurabile che gira su un'infrastruttura gestita", con sandbox nel cloud o self-hosted, sessioni persistenti ed esecuzioni pianificate via cron. L'Agents API di OpenAI, annunciata in beta pubblica il 10 settembre, esegue il loop dell'agente sull'infrastruttura di OpenAI e si occupa di "orchestrazione, sessioni di lunga durata e gestione del contesto". Cursor Projects, annunciato lo stesso giorno, mette un agente coordinatore su una propria macchina cloud, che delega a subagenti e può girare secondo una pianificazione o seguire le tue pull request.

Sono buoni prodotti, e puntano nella stessa direzione: sandbox, loop di tool, sessioni e pianificazioni stanno diventando qualcosa che si sceglie da un elenco.

Quello che un runtime non può sapere da solo è il tuo sistema. A quale container appartiene il codice delle fatture. Chi ne è il responsabile. Il contratto da cui dipendono i suoi consumatori. La decisione che ha reso intenzionale un confine. E la parte che conta quando nessuno guarda: quale altro agente, compresi quelli che questo runtime non ha avviato, sta lavorando su quale parte in questo momento.

Questa conoscenza non può vivere in un runtime, perché i tuoi agenti non girano tutti nello stesso. Alcuni girano su un portatile, altri in CI, altri in un worker in hosting. Per questo la vediamo così: il tuo runtime, la nostra architettura. Qualunque cosa faccia girare l'agente, il modello a cui risponde è lo stesso.

Le esecuzioni gestite degli agenti di Archyl, lanciate ad aprile, sono uno di questi runtime. Questa settimana hanno iniziato a comportarsi come tale. Puoi anche seguire e guidare un'esecuzione dal vivo.

Ora un'esecuzione può essere rifiutata, con il motivo

Il coordinamento è opzionale. Ogni profilo agente ha una nuova impostazione nella sezione Coordinamento, Rispetta il lavoro degli altri agenti, disattivata per impostazione predefinita. Quando è attiva, l'esecuzione apre la sua sessione di lavoro in esclusiva, e il verdetto del gate decide cosa succede dopo.

Se un altro agente ha un lease sugli stessi elementi, l'esecuzione viene rifiutata, che quell'agente sia Claude Code sul portatile di qualcuno o un'altra esecuzione gestita. L'esecuzione termina prima che venga clonato qualsiasi cosa, l'evento del gate riporta Esecuzione rifiutata, e il motivo indica chi sta lavorando lì e su cosa. Per il pomeriggio descritto sopra:

session denied by preflight gate: "Billing API" is being worked on by
claude-code/vincent (add proration to plan changes)

Il formato è quello reale; il task è un esempio. Chi legge l'esecuzione la mattina sa esattamente con chi parlare.

Se il gate si limita ad avvisare, ad esempio perché al task si applica un guardrail di livello error, l'esecuzione non parte e non fallisce. Resta In attesa di approvazione senza occupare uno degli slot di concorrenza della tua organizzazione. La pagina dell'esecuzione elenca i motivi, con Approva e avvia e Annulla esecuzione.

Approvare non ratifica a occhi chiusi il vecchio verdetto. Il gate viene valutato di nuovo, quindi se un agente locale ha preso un lease su quegli elementi mentre l'esecuzione aspettava, l'esecuzione approvata viene comunque rifiutata. Un'esecuzione che nessuno approva entro 24 ore viene annullata.

Perché un'esecuzione in attesa non trattiene niente

Mentre un'esecuzione aspetta, la sua sessione viene abbandonata. La sessione che ha sollevato l'avviso viene annullata, i suoi lease se ne vanno con lei, e l'approvazione ne apre una nuova. Tenere i lease sembrerebbe più prudente e sarebbe peggio: un'esecuzione che nessuno approva mai terrebbe tutti gli altri agenti lontani da quegli elementi per un giorno, dicendo a ciascuno di loro che lì c'era qualcosa al lavoro quando non c'era niente.

Questo segue una linea che abbiamo tracciato ad agosto. I lease sono consultivi, non lock. L'esclusività è qualcosa che un profilo chiede, non qualcosa che la piattaforma impone, e un'esecuzione che aspetta una persona non rivendica niente.

Il Guard si è spostato nel worker

La sessione copre l'intenzione. Il Guard copre ciò che viene scritto. Gli agenti locali ce l'hanno come hook di Claude Code da agosto, e ora le esecuzioni gestite hanno la stessa verifica dentro il worker.

Quando il progetto ha un repository collegato, ogni write_file ed edit_file dell'agente viene verificato rispetto alle regole di conformità del progetto prima che la modifica venga applicata. Una violazione critica rifiuta la scrittura, e l'agente legge quale regola ha violato e perché:

blocked by Archyl Guard: 1 critical architecture violation(s) in
backend/internal/adapter/http/handlers/invoice.go. Change the content so it
conforms, then write again:
- [critical] No direct database access from HTTP handlers — move the query behind a service

L'agente sposta la query e scrive di nuovo. Una violazione di gravità alta lascia passare la scrittura con un avviso. Se è la verifica stessa a fallire o ad andare in timeout, la scrittura passa: il Guard non blocca mai un agente per i propri errori, perché un controllo di governance che rompe il lavoro che governa finisce per essere spento.

Ogni verifica porta anche l'ID della sessione, che attribuisce il file alla sessione dell'esecuzione mentre l'agente lavora. Questo conta due sezioni più avanti.

L'agente conosce la sua sessione, ma non ne è il proprietario

Il prompt dell'esecuzione ora nomina la sua sessione e dice all'agente che la piattaforma l'ha aperta e la chiuderà, "quindi non ci sono tool di sessione da chiamare". L'agente non può aprire una seconda sessione né chiudere questa in anticipo. Il ciclo di vita appartiene alla piattaforma, l'unica parte che sa quando un'esecuzione è terminata.

Quello che appartiene all'agente è il suo resoconto del lavoro. Subito prima di finire, chiama report_outcome una volta, con un riepilogo onesto, le decisioni che meritano un ADR, i follow-up per il lavoro rimasto da fare e le memorie del briefing su cui si è basato. La descrizione del tool gli dice di tenere fuori dalle decisioni le osservazioni contingenti, perché le decisioni vengono riproposte alle sessioni future e una nota di debug non dovrebbe vincolare nessuno.

L'esito arriva dove è arrivato il lavoro

Quando l'esecuzione termina, Archyl per prima cosa attribuisce alla sessione i file modificati dall'esecuzione. Questo chiude la più silenziosa delle tre lacune. Gli elementi su cui una sessione prende i lease vengono dedotti dal testo del task, e il testo del task è un'ipotesi. I file modificati sono ciò che è successo. La memoria ora va agli elementi toccati dal lavoro reale, non a tutto quello che il ticket menzionava.

Poi chiude la sessione, salva il riepilogo come memoria su quegli elementi e dà credito alle memorie che l'agente dice di aver usato, che è il segnale da cui impara il ranking della memoria.

Le decisioni vengono registrate solo se l'esecuzione è riuscita. Diventano memoria del progetto e aprono un Architecture Change Request in bozza, così una persona rivede come il modello deve mettersi in pari. Un'esecuzione fallita conserva il riepilogo e i follow-up, che sono ciò di cui ha bisogno il tentativo successivo, ma non registra decisioni. Il lavoro che non si è concluso non ha niente da sostenere.

La pagina dell'esecuzione mostra tutto questo in una scheda Esito della sessione di lavoro: riepilogo, decisioni, follow-up, gli elementi toccati, le memorie citate e un link al Change Request. Un elemento occupato da un'altra sessione è segnalato come Occupato da un'altra sessione di lavoro, così un'esecuzione che ha modificato codice dentro il lease di qualcun altro non passa inosservata.

Due tipi di agente, un solo modello

Questo è il pezzo a cui mirava molti agenti, una sola architettura: coordinamento tra agenti che non condividono mai un processo, in entrambe le direzioni.

Un'esecuzione gestita apre la sua sessione come managed-agent/<profile name>. Rovescia la scena all'inizio di questo post: l'esecuzione pianificata è nella Billing API quando uno sviluppatore ci avvia Claude Code. Il suo briefing ora riporta l'esecuzione come conflitto:

- **Conflicts** (someone else is already working here):
  - Billing API — held by managed-agent/backend-fixer: fix rounding on prorated invoices

All'agente locale viene detto di coordinarsi prima di modificare quell'elemento, la console Fleet mostra entrambe le sessioni, e quella che finisce lascia una memoria che l'altra leggerà la volta successiva.

Uscito anche questa settimana

Brevemente, perché il resto si regge su questo. I profili ora includono skill integrate e allowlist dei tool, così un revisore in sola lettura può essere limitato a read_file, list_* e get_*. Gli heartbeat del worker rilevano le esecuzioni morte e le ripuliscono, la chiave API di ogni esecuzione viene revocata quando l'esecuzione termina, e un'esecuzione fallita pubblica comunque il suo lavoro come pull request in bozza. Le esecuzioni girano sempre nel worker di Archyl, sul provider di IA della tua organizzazione quando BYO è attivo.

Cosa non fa

Il coordinamento vede solo gli agenti che usano l'harness. Un lease esiste perché un agente ha aperto una sessione. Un agente che modifica il repository senza sessione è invisibile al gate, e un'esecuzione che rispetta il lavoro degli altri agenti partirà proprio accanto a lui.

Il worker non esegue i tuoi test. Ha tool per i file del workspace (leggere, scrivere, modificare, elencare, grep) e nessuna shell. Non può compilare il progetto né eseguire la suite, quindi una scheda di esito pulita significa che le scritture hanno superato il Guard, non che il codice compila. Quel lavoro lo fa ancora la CI.

Le decisioni di un agente non sono revisionate. Una decisione nella scheda di esito è un'affermazione dell'agente finché qualcuno non revisiona il Change Request. Quella revisione è il punto, non una formalità.

Il Guard ha bisogno di qualcosa con cui confrontare. Senza un repository collegato non c'è verifica delle scritture, e un insieme vuoto di regole di conformità lascia passare ogni scrittura.

Da dove iniziare

Scegli il profilo che gira in modo pianificato su codice che anche le persone modificano a mano, e attiva Rispetta il lavoro degli altri agenti in Coordinamento. Lascia gli altri come sono.

Se rifiuta un'esecuzione, il motivo nomina l'agente e il task che si sovrapponevano al suo. Finora quella sovrapposizione sarebbe passata senza che nessuno ne sapesse niente.

Le esecuzioni gestite degli agenti, le sessioni di lavoro, il Guard e la memoria fanno parte di archyl. Ogni impostazione citata sopra è nella documentazione delle esecuzioni gestite degli agenti, e il lato locale è nella guida all'Harness. Letture correlate: molti agenti, una sola architettura, sessioni di lavoro per gli agenti di coding, memoria per agenti di coding e il lancio delle esecuzioni gestite degli agenti.