Claude Code in profondità: dal terminale a un sistema operativo di agenti

Claude Code non è semplicemente uno strumento che scrive codice più in fretta. È un modo diverso di organizzare il lavoro: un agente con accesso al repository, al terminale, ai test e agli strumenti che decidi di collegargli. Quando viene configurato con contesto, metodo, permessi e revisione, può diventare una capacità condivisa da tutto un team.

In Impulsa3 portiamo questa idea su un terreno più ampio con I3OS, il nostro caso pratico di agentizzazione. I3OS non è nato per accumulare bot né per sostituire il criterio professionale. È nato per collegare il contesto di ogni cliente con metodi riutilizzabili, dati autorizzati, strumenti e revisione umana.

Claude Code è uno dei pezzi che permette di capire meglio questo cambiamento. Questo articolo raccoglie i fondamenti, la configurazione, le Skill, gli Hook, MCP, i subagenti, l’automazione, i plugin e l’esecuzione sul tuo computer. La tesi è semplice: la produttività non arriva quando dai più autonomia al modello, ma quando progetti meglio il sistema in cui lavora.

1. Che cosa cambia quando passi dall’assistente all’agente

Un assistente conversazionale risponde a ciò che gli dai. Un agente può lavorare con l’ambiente che gli autorizzi. In Claude Code quell’ambiente è di solito un repository: file, comandi, Git, test, documentazione e, se lo configuri, servizi esterni.

• Chatbot: riceve testo e restituisce testo. L’utente sposta manualmente le informazioni ed esegue le decisioni.
• Copilot: suggerisce righe, funzioni o risposte all’interno di un’interfaccia di sviluppo.
• Agente: riceve un risultato desiderato, ispeziona il contesto, usa strumenti, modifica artefatti e verifica ciò che ha fatto.
• Sistema agentizzato: trasforma quella capacità in un metodo ripetibile, misurabile, governato e riutilizzabile da un team.

Per questo Claude Code può spiegare una base di codice, implementare una funzionalità che tocca diversi file, eseguire test, analizzare un errore di CI, preparare una revisione o proporre un cambio di architettura. Ma può anche sbagliare a grande velocità. L’accesso a più strumenti non elimina la necessità di criterio: la rende più importante.

Questo è il collegamento con ciò che intendiamo per agenti di IA in azienda: l’autonomia utile non è una proprietà magica del modello. È il risultato di combinare obiettivo, contesto, strumenti, permessi, verifica e responsabilità.

2. Il modello mentale corretto: esplorare, pianificare, eseguire e verificare

L’errore più comune è aprire Claude Code e chiedergli di iniziare a programmare prima che abbia capito il problema. In un progetto reale, il flusso professionale assomiglia di più a una mini-catena di ingegneria:

1. Esplorare

Per prima cosa Claude deve leggere la struttura del repository, individuare i file rilevanti, capire come si esegue il progetto e rilevare le convenzioni esistenti. In questa fase non vogliamo che produca codice. Vogliamo che costruisca un modello mentale e formuli domande.

2. Pianificare

Poi si definisce il risultato, si separano i compiti, si individuano le dipendenze e si esplicitano i rischi. Un buon piano non è un elenco di frasi generiche: indica che cosa cambia, che cosa non cambia, come verrà verificato e quali decisioni richiedono approvazione.

3. Eseguire

L’implementazione avviene a piccoli passi. Claude può modificare, eseguire comandi, leggere gli errori e correggere. La persona deve tenere visibile l’obiettivo, rivedere i diff ed evitare che una prima soluzione ragionevole diventi una catena di patch senza direzione.

4. Verificare e conservare

Il lavoro non finisce quando Claude dice di aver finito. Bisogna eseguire test, linter, type-check, verifiche visive o prove di business. Il risultato deve rimanere in un commit, una pull request, una documentazione o un artefatto che un’altra persona possa rivedere.

La velocità di Claude Code si nota nell’esecuzione. La qualità si decide prima e dopo: nel contesto che riceve e nella verifica che pretendiamo.

3. Primi passi: come iniziare senza trasformarlo in magia

La prima sessione dovrebbe svolgersi su un progetto reale, ma con un compito a basso rischio. La sequenza più utile è:

1. Apri il terminale in un repository che conosci e che puoi ripristinare con Git.
2. Chiedi a Claude di spiegare l’architettura e di citare i file in cui ha trovato ogni risposta.
3. Richiedi una modifica piccola ed esplicita, per esempio un test o un miglioramento localizzato.
4. Fagli eseguire la verifica del progetto e mostrarti il diff.
5. Correggi i suoi presupposti prima di affidargli un compito più grande.

L’installazione cambia a seconda del sistema e del metodo di autenticazione. Conviene seguire la documentazione ufficiale di Claude Code per ottenere il comando aggiornato. Dopodiché, la domanda importante non è «quale prompt gli scrivo?», ma «che cosa gli serve sapere per lavorare come qualcuno che è appena entrato nel mio team?».

Un’istruzione iniziale utile sarebbe: Esplora il repository, spiegami come si esegue, individua i rischi di questo compito e fammi le domande che ti servono prima di proporre modifiche. È un modo semplice per obbligare l’agente a capire prima di agire.

4. Contesto e configurazione: il sistema comincia dai file

La differenza tra una sessione generica e una sessione che sembra conoscere il progetto sta nel contesto persistente. Claude Code può leggere regole di progetto, preferenze personali e configurazione tecnica. Ogni pezzo ha una funzione diversa:

CLAUDE.md: meno documentazione, più decisioni

Un CLAUDE.md utile non è un manuale infinito né una copia della documentazione pubblica del framework. È il posto in cui si scrivono le cose che Claude non dovrebbe dover indovinare: come avviare il progetto, quali comandi passano in CI, quali pattern sono considerati corretti, quali directory non deve toccare e perché esiste una decisione apparentemente strana.

In I3OS applichiamo una separazione simile: Project = il contesto che ricorda; Skill = il metodo che sa applicare. In Claude Code, il progetto porta la realtà concreta e le Skill trasformano l’esperienza del team in una capacità attivabile.

Permessi: autonomia graduata, non modalità YOLO

Claude Code può leggere, modificare, eseguire comandi e connettersi a servizi. Ogni permesso amplia la capacità e anche la superficie di rischio. La configurazione professionale parte dal minimo necessario:

• Consenti prima i comandi di lettura e di test e solo dopo i comandi distruttivi.
• Limita l’accesso per comando, directory, dominio o tipo di strumento.
• Evita credenziali reali nel repository, nel prompt o nei log.
• Richiedi l’approvazione umana per pubblicare, cancellare, distribuire, inviare messaggi o toccare dati sensibili.
• Rivedi periodicamente i permessi: ciò che era un’eccezione finisce spesso per diventare permanente.

L’autonomia deve crescere per evidenza, non per entusiasmo. Se un compito fallisce in modo imprevedibile, la risposta di solito non è dargli più permessi. Prima bisogna migliorare il contesto, il metodo o la verifica. È anche una delle conclusioni del nostro lavoro sulla supervisione umana.

5. Skill: trasformare la conoscenza del team in un metodo riutilizzabile

Una Skill non è un prompt lungo con un bel nome. È una ricetta operativa che spiega quando usarla, quale contesto le serve, quali passi deve seguire, quali strumenti può utilizzare e come deve consegnare il risultato.

Un esempio semplice sarebbe una Skill di audit di una landing:

---
name: auditar-landing
description: Revisa una landing en busca de problemas de conversión, accesibilidad y rendimiento.
---

1. Identifica el objetivo de negocio y la audiencia.
2. Revisa estructura, propuesta de valor y llamadas a la acción.
3. Comprueba accesibilidad, responsive y estados de error.
4. Ejecuta las pruebas disponibles y documenta la evidencia.
5. Devuelve hallazgos priorizados, no una lista genérica de opiniones.
6. No modifiques archivos sin pedir aprobación explícita.

La forza della Skill sta nel fatto che si può migliorare a ogni utilizzo. Se l’agente si dimentica di verificare il contrasto, lo si aggiunge al metodo. Se una fonte non è affidabile, si fissa una regola. Se un compito richiede l’approvazione del cliente, diventa un punto di controllo.

• Skill di esplorazione: capire un repository, un cliente o un account senza toccare nulla.
• Skill di produzione: eseguire una procedura con input e output chiari.
• Skill di valutazione: confrontare il risultato con una rubrica e restituire evidenze.
• Skill di manutenzione: aggiornare documentazione, test o configurazioni quando il sistema cambia.

Una Skill non sostituisce il professionista: impacchetta un metodo perché il professionista possa dedicare la sua attenzione alle decisioni difficili. Più un compito si ripete, più ha valore trasformarlo in una capacità condivisa e verificabile.

6. Hook: le regole che non dipendono dalla memoria del modello

Le istruzioni di CLAUDE.md orientano l’agente, ma restano istruzioni che il modello interpreta. Un Hook introduce un’automazione deterministica in un momento preciso del ciclo di lavoro: prima di uno strumento, dopo una modifica, quando una sessione termina o quando il contesto cambia.

• Eseguire il formattatore dopo aver modificato.
• Lanciare test o analisi statica dopo una modifica.
• Bloccare pattern di segreti prima di salvare un file.
• Registrare quale strumento è stato usato e con quale risultato.
• Notificare che un compito è terminato senza tenere una finestra aperta.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npm run lint",
            "timeout": 60
          }
        ]
      }
    ]
  }
}

L’esempio è volutamente semplice: il comando reale dipende da ogni stack e conviene evitare che un Hook lento blocchi l’intera sessione. La regola pratica è mettere negli Hook ciò che deve avvenire sempre e lasciare nelle Skill ciò che richiede interpretazione.

Per un’azienda la domanda decisiva è: quali errori vogliamo impedire per progettazione, anche se il modello propone una soluzione apparentemente corretta?

7. MCP: quando Claude smette di lavorare con una copia del mondo

Il Model Context Protocol permette di collegare Claude Code a strumenti e fonti esterne tramite interfacce strutturate. Invece di copiare a mano una conversazione di Slack, un documento, un ticket o una metrica, l’agente può interrogare il sistema autorizzato e lavorare con informazioni più vicine alla fonte.

• Documentazione e conoscenza: consultare un archivio di decisioni, una wiki o documenti di progetto.
• Prodotto e operazioni: leggere ticket, attività, calendari o stati di rilascio.
• Qualità: aprire l’applicazione, catturare una schermata, consultare i log o eseguire una verifica.
• Azienda: collegare dati e processi interni sempre con permessi, tracciabilità e finalità definita.

MCP non è una scusa per collegare tutto. Ogni server aggiunge strumenti, contesto, permessi e un’altra dipendenza. La connessione giusta è quella che riduce il lavoro di ricostruire informazioni senza creare una superficie di rischio sproporzionata.

In pratica, collega prima una fonte che abbia un proprietario, dati relativamente puliti e un caso d’uso concreto. Poi misura se migliora il risultato. Se l’informazione va comunque copiata, interpretata o validata a mano, probabilmente il problema non si risolve aggiungendo un altro server.

La differenza tra un’API generica e un server di strumenti con contesto sta nel fatto che l’agente può lavorare con un’interfaccia pronta per consultare e agire. Nel modello di I3OS, questo strato equivale a collegare l’IA ai dati e ai sistemi reali del cliente, non a chiederle di improvvisare con una copia non aggiornata.

8. Subagenti: dividere il lavoro senza perdere la responsabilità

Un subagente è una sessione specializzata che lavora in un contesto isolato e restituisce un risultato sintetico all’agente principale. È utile quando un compito può essere separato per obiettivo: indagare una dipendenza, rivedere la sicurezza, analizzare i log, esplorare una parte del repository o eseguire una valutazione indipendente.

• Esploratore: cerca dove vive una funzionalità e restituisce una mappa di file.
• Revisore: analizza un diff con una rubrica precisa e non modifica nulla.
• Ricercatore: confronta alternative e documenta i trade-off.
• Verificatore: esegue i test e porta l’evidenza di ciò che accade.

I subagenti non moltiplicano automaticamente l’intelligenza. Moltiplicano il lavoro e il costo se li lanciamo senza una divisione chiara. Non ha senso mettere cinque agenti a modificare gli stessi file né chiedere a tutti di fare un audit generico. La parallelizzazione funziona quando ogni agente ha un contratto piccolo e un output utile.

Nei compiti che possono modificare il codice, i worktree di Git permettono di isolare i rami ed evitare che più sessioni si pestino i piedi. Anche così, l’integrazione finale deve avere un punto di revisione comune. Un agente può produrre una modifica; il team decide se quella modifica appartiene al prodotto.

La regola che portiamo in I3OS è la stessa: ogni capacità deve avere una finalità, una fonte di contesto, un metodo e una persona responsabile.

9. Plugin e Agent Plugin: impacchettare capacità perché possano viaggiare

Quando un team crea diverse Skill, Hook, agenti e connessioni MCP, nasce un’esigenza naturale: impacchettarli. I plugin permettono di distribuire una capacità completa con una struttura che altre persone possano installare, rivedere e aggiornare.

Il riferimento che condividi dal post di midudev su LinkedIn punta proprio a una conversazione importante: se ogni client di agenti impacchetta le estensioni con un formato diverso, i team finiscono per duplicare il lavoro. La Agent Plugins Specification propone un contratto aperto e agnostico per impacchettare componenti come Skill e server MCP.

La specifica 1.0.0 definisce un manifesto plugin.json, una struttura di Skill con file SKILL.md e uno schema per la configurazione MCP quando il plugin la include. Non significa che tutti i client supportino automaticamente tutti i plugin. Significa che l’ecosistema ha una base comune su cui costruire portabilità e distribuzione.

mi-plugin/
├── plugin.json
├── skills/
│   └── auditar-landing/
│       └── SKILL.md
└── mcp.json

Per Impulsa3 questa evoluzione è particolarmente rilevante. Se un metodo di analisi, QA, onboarding o produzione diventa una capacità ben documentata, è nell’interesse di tutti che non resti legata a una singola sessione né alla memoria di una persona. Un plugin può essere l’imballaggio; la governance e il criterio restano responsabilità dell’organizzazione.

La specifica si presenta come uno standard aperto e neutrale, con sviluppo pubblico e partecipazione di diversi attori dell’ecosistema. Conviene seguirla come segnale della direzione che sta prendendo la distribuzione degli agenti, senza però confondere ancora una specifica con una garanzia di piena interoperabilità.

10. Claude Code sul tuo computer: Remote Control e il dibattito sul calcolo

L’esecuzione remota introduce una distinzione che non conviene semplificare. Una sessione di Claude Code può essere eseguita sull’infrastruttura cloud del fornitore, oppure sul tuo computer ed essere controllata da un’altra interfaccia. Non sono la stessa cosa.

Il riferimento di Anthropic che condividi, Run Claude Code sessions on your own compute, anticipa questa direzione. La documentazione attuale lo concretizza come Remote Control: esegui Claude Code sulla tua macchina e usi claude.ai o l’applicazione mobile per continuare e supervisionare la sessione. Il file system, gli strumenti locali e i server MCP restano disponibili nel tuo ambiente.

# En una sesión nueva
claude remote-control

# O desde una sesión interactiva existente
/remote-control

Questo può essere molto utile per un team che deve mantenere un ambiente privato, strumenti interni o dati che non vuole spostare su una macchina effimera. Ma «viene eseguito sul mio computer» non significa «non esce nessun dato». La connessione remota sincronizza la conversazione e l’attività perché tu possa vederla da altri dispositivi. Bisogna verificare la politica sui dati, i permessi, l’accesso fisico, la sospensione del portatile e la disponibilità della rete.

La decisione giusta dipende dal rischio e dal lavoro. Un’analisi che ha bisogno solo di un repository pulito può essere eseguita nel cloud. Un compito che ha bisogno del tuo server di sviluppo, dei tuoi MCP locali o di dati interni può richiedere il tuo calcolo. In entrambi i casi la sicurezza non si delega al nome del prodotto: si progetta nelle credenziali, nei limiti e nella revisione.

11. Il ponte con I3OS: da uno strumento per programmare a un sistema di lavoro

Il caso di I3OS aiuta a vedere la differenza tra usare Claude Code in modo individuale e costruire una capacità organizzativa. Nel nostro sistema l’obiettivo non è che ogni persona impari una collezione diversa di prompt. L’obiettivo è che il lavoro possa conservare il contesto, applicare un metodo, consultare le fonti giuste e produrre un risultato verificabile.

• Project: separa il contesto di ogni cliente, prodotto o iniziativa.
• CLAUDE.md e regole: fissano le convenzioni e le decisioni che devono essere mantenute.
• Skill: trasformano la pratica di una persona esperta in una procedura condivisa.
• MCP e connettori: avvicinano i dati e gli strumenti reali al flusso di lavoro.
• Hook e permessi: fanno sì che certi controlli non dipendano dalla memoria del modello.
• Subagenti: separano ricerca, esecuzione e valutazione quando il compito lo merita.
• Revisione umana: mantiene la responsabilità verso il cliente, il business e la comunicazione esterna.

Nel caso di successo di I3OS raccontiamo come un pilota SEO sia diventato un’architettura che collega operazioni, tecnologia, contenuti, squad di cliente e adozione interna. Claude Code si inserisce in questa visione perché rende possibile iterare in fretta sui metodi: documentarli, testarli, collegarli e correggerli.

Un agente isolato automatizza un compito. Un sistema agentizzato migliora il modo in cui un’organizzazione impara e crea valore.

12. Un caso pratico: costruire una capacità di revisione del frontend

Immaginiamo una capacità interna per rivedere una landing prima di consegnarla a un cliente. Un flusso immaturo sarebbe chiedere: «rivedi questa pagina e dimmi se va bene». Un sistema progettato meglio separa il lavoro:

1. Il Project porta l’obiettivo di business, il pubblico, l’identità di marca e i vincoli del cliente.
2. Una Skill definisce la rubrica: proposta di valore, gerarchia, conversione, accessibilità, responsive e prestazioni.
3. MCP permette di consultare l’analytics, aprire la pagina in un browser e recuperare i ticket collegati.
4. Un Hook esegue il lint e blocca segreti o errori di base prima che l’agente consegni il risultato.
5. Un subagente rivede l’accessibilità e un altro confronta l’implementazione con il design.
6. La persona responsabile riceve un report con evidenze, decide che cosa correggere e approva la consegna.

La differenza non sta nell’avere un prompt più sofisticato. Sta nell’aver progettato un circuito in cui ogni pezzo ha una funzione e in cui il risultato si può rivedere. È lo stesso principio che applichiamo al ridisegno dei processi con l’IA: prima di automatizzare bisogna capire il processo reale, le sue decisioni, le sue eccezioni e il suo criterio di qualità.

13. Governance: l’IA accelera, ma non firma

Più l’agente è capace, più è importante decidere dove finisce la sua autonomia. In Impulsa3 riassumiamo questa idea così: l’IA accelera; non firma. Il sistema può preparare, analizzare e proporre. Le decisioni che riguardano il cliente, il business, i dati sensibili o la reputazione hanno bisogno di una persona responsabile.

• Accesso con uno scopo: ogni strumento deve rispondere a un’esigenza concreta del flusso.
• Privilegio minimo: l’identità dell’agente deve avere solo la portata che le serve.
• Fonti con un responsabile: un dato senza data, proprietario o qualità nota non diventa affidabile solo perché è collegato.
• Revisione prima di eseguire: pubblicare, cancellare, distribuire, acquistare o comunicare richiede un’approvazione.
• Tracciabilità: conviene poter sapere che cosa è stato consultato, che cosa è stato modificato, quali test sono stati eseguiti e chi ha validato.
• Privacy by design: le informazioni sensibili non devono entrare in un flusso solo perché tecnicamente è possibile.

Queste regole si collegano con la qualità del dato, il comitato di IA e la necessità di passare dai piloti a sistemi controllati. La governance non è uno strato burocratico che compare dopo l’innovazione: fa parte della progettazione tecnica.

14. Come introdurre Claude Code in un team senza creare caos

Un’adozione responsabile può iniziare da un solo flusso e crescere a partire dall’evidenza. Questo percorso è di solito più solido che distribuire licenze e sperare che nasca una metodologia spontanea:

1. Scegli un compito ripetitivo e verificabile. Ricerca, documentazione, QA, analisi dei log o manutenzione sono di solito buoni punti di partenza.
2. Definisci il risultato e l’evidenza. Prima di usare l’agente, decidi che cosa significa «fatto» e come verrà verificato.
3. Costruisci il contesto minimo. Raccogli fonti, comandi, vincoli, eccezioni e responsabili.
4. Documenta il metodo come una Skill. Non nascondere il modo corretto di lavorare dentro una conversazione.
5. Aggiungi controlli deterministici. Usa permessi e Hook per evitare errori ricorrenti.
6. Collega solo gli strumenti necessari. Ogni server MCP deve avere un caso d’uso e un proprietario.
7. Misura e migliora. Registra tempo, qualità, rilavorazioni, errori, costo, interventi e soddisfazione del team.
8. Scala la capacità, non il rumore. Se funziona, impacchetta il metodo, forma il team e decidi se merita di diventare un plugin o un servizio condiviso.

L’obiettivo non è dimostrare che un agente può fare molte cose. È dimostrare che una capacità concreta migliora il lavoro senza perdere il controllo. Quando il processo è già compreso e misurato, ha senso aumentare l’autonomia o parallelizzare con i subagenti.

15. Che cosa non conviene fare

• Non iniziare dalla modalità più autonoma. Comincia osservando come ragiona e quali presupposti fa.
• Non riempire CLAUDE.md di informazioni che l’agente può dedurre. Riserva il contesto a decisioni, limiti e convenzioni.
• Non collegare MCP per accumulo. Più strumenti possono significare più costo, più rumore e più superficie di attacco.
• Non lanciare agenti in parallelo sugli stessi file. La velocità non compensa i conflitti difficili da rivedere.
• Non misurare il successo con la quantità di prompt o di Skill. Misuralo con i risultati, la qualità e la capacità liberata.
• Non nascondere l’incertezza. Un report che distingue fatti, ipotesi e dubbi vale più di una risposta sicura ma fragile.

Domande frequenti su Claude Code

Claude Code è solo per programmatori?

È progettato attorno al lavoro con codice e terminale, ma il suo modello è più ampio: leggere il contesto, applicare un metodo, usare strumenti e produrre un risultato verificabile. Può essere utile per documentazione tecnica, QA, analisi dei dati o automazione operativa, purché esistano un ambiente chiaro e una persona responsabile.

Devo usare Skill, Hook, MCP e subagenti fin dal primo giorno?

No. Comincia con una sessione locale, un CLAUDE.md breve e un compito che puoi verificare. Aggiungi le Skill quando il metodo si ripete, gli Hook quando ci sono controlli che devono essere sempre eseguiti, MCP quando ti servono dati esterni e i subagenti quando esiste una vera divisione del lavoro.

Remote Control esegue Claude nel cloud?

Remote Control permette di controllare dal web o dal cellulare una sessione di Claude Code che continua a essere eseguita sulla tua macchina. È diverso da una sessione di Claude Code nel cloud. Anche così, la conversazione e l’attività vengono sincronizzate perché le interfacce possano restare collegate, quindi bisogna verificare la politica sui dati della tua organizzazione.

Agent Plugins garantisce già che tutto funzioni in qualsiasi client?

No. La specifica offre un formato comune per impacchettare le estensioni e una base per la portabilità. La compatibilità reale dipende dal fatto che ogni client implementi lo standard e dalle capacità concrete che supporta.

Come faccio a sapere se un processo è pronto per essere agentizzato?

Quando puoi spiegarne obiettivo, fonti, passi, eccezioni e criterio di qualità, e quando una seconda persona può rivedere il risultato. Se nessuno sa descrivere come si svolge il compito, prima bisogna ridisegnarlo e documentarlo.

Conclusione: il moltiplicatore non è Claude, è il sistema

Claude Code rappresenta un salto importante perché porta l’IA nel posto in cui il lavoro accade: il repository, il terminale, i test, i servizi e i processi. Ma il valore non sta nel chiedergli di fare più cose senza supervisione. Sta nel progettare un flusso in cui possa lavorare con contesto, metodo e limiti.

I pezzi si incastrano così: CLAUDE.md porta la memoria; le Skill portano il metodo; MCP porta la connessione; gli Hook portano il determinismo; i subagenti portano la specializzazione; i plugin portano la distribuzione; Remote Control porta la continuità; la revisione umana porta la responsabilità.

È quello che stiamo esplorando con I3OS in Impulsa3: trasformare l’intelligenza artificiale in una capacità organizzativa, non in una collezione di strumenti isolati. L’obiettivo finale non è produrre più codice, più contenuti o più automazioni. È liberare capacità per capire meglio il business, risolvere problemi complessi e portare più valore ai clienti.

Se vuoi individuare quali processi della tua azienda possono essere agentizzati, progettare un’architettura con contesto e governance o accompagnare il tuo team nell’adozione, possiamo aiutarti a trasformare l’opportunità in un sistema di lavoro pratico e misurabile.