Harness ha presentato gli Autonomous Worker Agents, agenti AI progettati per operare direttamente nelle pipeline di software delivery e gestire attività che normalmente restano tra la scrittura del codice e il rilascio in produzione. La piattaforma estende quindi l’automazione oltre le pipeline basate su script fissi, permettendo di usare componenti capaci di interpretare contesto, analizzare eventi operativi e scegliere azioni entro confini tecnici e di governance già definiti dall’organizzazione.
Gli agenti vengono eseguiti come step nativi delle pipeline Harness e possono intervenire nelle fasi di build, test, sicurezza, deployment, validazione, remediation e gestione operativa. Invece di limitarsi a lanciare comandi preconfigurati, ricevono informazioni come modifiche al codice, log, stato degli ambienti, risultati delle pipeline, incidenti e configurazioni dei servizi, elaborando il problema attraverso un modello linguistico e gli strumenti autorizzati disponibili nel workflow.
Il contesto operativo viene fornito dal Harness Knowledge Graph, che collega servizi, pipeline, rilasci, deployment, policy e incidenti dell’organizzazione. Questo consente agli agenti di ragionare su informazioni che appartengono al ciclo reale di delivery, evitando di operare come assistenti isolati dal repository, dagli ambienti e dalle regole di rilascio. Le capacità di azione sono invece esposte attraverso Harness MCP, con la possibilità di collegare server MCP esterni e strumenti personalizzati per interagire, ad esempio, con Git, Jira, Slack o altri sistemi aziendali.
L’esecuzione può essere attivata da eventi come l’apertura di una pull request, il fallimento di una build CI, un controllo pianificato, un incidente o una richiesta avviata tramite interfaccia AI. Un agente può quindi analizzare una pipeline non riuscita, raccogliere i log necessari, individuare un errore ricorrente, proporre o applicare una correzione entro i privilegi disponibili e produrre un output tracciabile per il team. Gli agenti possono inoltre essere concatenati in workflow multi-step, passando risultati e contesto da un’unità all’altra per costruire processi più articolati.
Il modello di sicurezza è basato sull’eredità diretta dei controlli già presenti nelle pipeline Harness. Ogni agente viene eseguito in un container isolato, con accesso limitato a file, rete e strumenti. Le credenziali sono scoped, cioè associate a una specifica identità AI e a un insieme circoscritto di autorizzazioni: l’agente può compiere soltanto le operazioni consentite dal proprio ruolo, indipendentemente da chi lo ha attivato o dal contenuto del prompt ricevuto.
Quando un agente deve invocare un modello linguistico, prompt e contesto transitano attraverso un LLM Gateway che applica controlli di policy e conserva la tracciabilità delle richieste. Le stesse regole OPA, i gate di approvazione, i controlli RBAC e le policy che regolano i deployment effettuati dagli utenti possono quindi governare anche gli agenti. Un’organizzazione può, per esempio, impedire l’uso di modelli non approvati nelle pipeline di produzione, richiedere approvazioni umane per specifiche azioni o limitare l’attività automatica a determinati ambienti.
Ogni azione viene registrata con una distinta identità AI, mantenendo informazioni sull’evento che ha avviato l’agente, sulle decisioni prese, sugli strumenti richiamati e sull’esito finale. La piattaforma espone inoltre il consumo di token per agente e per pipeline, rendendo possibile collegare i costi dell’uso dei modelli ai singoli processi di delivery e alle attività che li hanno generati.
Gli Autonomous Worker Agents possono essere definiti tramite un singolo file in formato Markdown, salvato nel repository e distribuito nell’organizzazione come componente governato. I team possono partire da agenti gestiti da Harness, personalizzarli, crearne di nuovi con il supporto dell’AI della piattaforma oppure pubblicare agenti nel nuovo Agent Marketplace. Il catalogo comprende agenti Harness Managed, agenti certificati e contributi della community, mentre le policy aziendali possono stabilire quali categorie siano autorizzate a operare nelle pipeline di produzione.
L’obiettivo è spostare una parte crescente della software delivery da automazioni rigide, costruite e mantenute attraverso script, a unità autonome in grado di interpretare il contesto tecnico e agire all’interno di limiti verificabili. In questa architettura l’agente non viene introdotto come un sistema separato dalla delivery, ma come uno step governato della pipeline esistente, con gli stessi confini di rete, autorizzazione, audit e controllo già applicati ai rilasci software aziendali.