Come un BDR di Anthropic in Giappone gestisce la propria giornata con gli Agenti gestiti di Claude

In qualità di addetto allo sviluppo commerciale del team giapponese di Anthropic, il mio compito è mostrare alle aziende giapponesi come Claude possa semplificare e automatizzare i flussi di lavoro. Tuttavia, fino all'inizio di quest'anno, la maggior parte dei miei flussi di lavoro era ancora manuale. Ogni mattina passavo un paio d'ore a smistare e qualificare i lead, per poi scrivere e-mail in giapponese o in inglese. Nel tempo che mi restava, mi occupavo di aggiornare il CRM, che spesso risultava indietro di un giorno o più. Ora i miei agenti preparano gran parte di questo lavoro prima che inizi la mia giornata, e io lo controllo.

Il primo flusso di lavoro gestito da Claude che ho creato era piuttosto rudimentale, ma funzionava. Consegnavo a Claude una parte del mio lavoro alla volta, correggevo ciò che era sbagliato e salvavo le correzioni. Col tempo, questo approccio si è trasformato in una manciata di agenti, ciascuno dedicato a una routine diversa.

La voce si è sparsa in fretta e i membri del team hanno iniziato a chiedermi i prompt e le skill che utilizzavo per crearne di propri. Tutto ciò che potevo inviare loro era un file zip con le mie skill e alcuni file Markdown della knowledge base, che dovevano caricare su Claude, per poi rispondere a una serie di domande di configurazione prima che tutto funzionasse. Anche la mia configurazione stava diventando sempre più difficile da monitorare. Ogni agente era composto da una skill, un'attività pianificata e una cartella condivisa, e li modificavo chiedendo a Claude, all'interno di qualsiasi chat avessi aperta: in questo modo, la stessa skill veniva ritoccata a partire da numerose conversazioni differenti.

Volevo definire ogni agente una sola volta, in un unico posto, e poter vedere tutte le modifiche che vi avevo apportato. Ho quindi deciso di provare gli Agenti gestiti di Claude (opens in new tab) in versione beta, la nostra infrastruttura di agenti gestiti sulla Claude Platform.

All'inizio ero riluttante a provarlo. La documentazione parla di pianificazioni, strumenti e depositi di credenziali e io sono un rappresentante commerciale, quindi ho dato per scontato che gli Agenti gestiti fossero pensati per team di sviluppo in grado di creare e gestire l'infrastruttura necessaria. L'ho comunque provato perché i miei agenti esistevano già e dovevo solo trasferirli.

Alla fine, è emerso che non avevo bisogno di essere uno sviluppatore. Ho descritto il compito di ciascun agente in un linguaggio semplice, Claude ha scritto alcuni brevi script di configurazione e io li ho eseguiti dal terminale sul mio laptop. (Se stai partendo da zero, la Console offre inoltre un avvio rapido con modelli di agenti già pronti.) Da allora, non c'è stata alcuna infrastruttura di cui dovessi occuparmi.

In questo post spiegherò come ho progettato e prototipato la flotta, perché sono passato agli Agenti gestiti, come Claude Tag intercetta tutto ciò che non rientra nella routine, in che modo tutto questo ha cambiato la mia settimana e cosa consiglierei ai venditori che desiderano creare i propri agenti per automatizzare flussi di lavoro manuali e ripetitivi.

Progettare la mia flotta di agenti

Ho suddiviso il mio flusso di lavoro tra più agenti e ho assegnato a ciascuno un unico compito ben definito. Avere una singola responsabilità rende ciascun agente facile da comprendere e da monitorare, soprattutto quando qualcosa non va. Ho inoltre dato a ogni agente un nome giapponese, poiché lavorano principalmente in lingua giapponese. Insieme vengono chiamati Nakama, "la ciurma" o, più letteralmente, i compagni con cui si lavora:

• Furiwake ("smistamento") è la fase iniziale: analizza la coda giornaliera dei contatti in entrata e assegna ogni lead al membro del team più indicato, bilanciando il numero di lead e la priorità di ciascuno e verificando chi è presente quel giorno. In questo modo, ogni lead ha una persona responsabile assegnata ancora prima che la giornata lavorativa abbia inizio. Alla fine di ogni esecuzione, il sistema pubblica un report in un canale Slack dedicato, con ogni lead in entrata e ogni lead assegnato, in modo che io possa monitorare il passaggio di consegne.
• Sabaki ("gestione") smista i lead che mi vengono assegnati: qualifica ogni lead, lo categorizza in base a criteri preimpostati, esegue il passo successivo definito per quella categoria (prepara una risposta che indirizzi il contatto alle opzioni self-service, redige una prima e-mail personalizzata), aggiorna il record del lead in Salesforce e crea una bozza dell'e-mail di primo contatto. Trae i contenuti della bozza dalla knowledge base condivisa dei Nakama, un archivio di memoria (opens in new tab) in cui ogni agente può scrivere e da cui può leggere (maggiori dettagli in seguito).
• Henji ("risposta") esegue ogni ora la scansione della mia casella di posta alla ricerca di e-mail dei clienti che richiedono un riscontro e prepara una bozza di risposta in giapponese o in inglese, a seconda della conversazione, attingendo alla stessa knowledge base utilizzata da Sabaki. Posso revisionare, modificare e inviare la bozza.
• Shoudan ("opportunità") legge le interazioni effettuate recentemente con i clienti e invia gli aggiornamenti in Salesforce, così i record delle opportunità rimangono aggiornati senza l'inserimento manuale dei dati.
• Nokori ("ciò che rimane") viene eseguito alla fine della giornata: analizza il mio calendario, legge le trascrizioni delle riunioni allegate, riassume ogni riunione e redige le bozze dei follow-up, sempre partendo dalla stessa knowledge base.

Ogni agente viene eseguito secondo una pianificazione. Un sesto agente, il coordinatore dei Nakama, è il responsabile delle operazioni della flotta. Aggiorna le istruzioni degli agenti e la knowledge base condivisa tra un'esecuzione e l'altra. Quando voglio cambiare il modo in cui funziona un agente, scrivo ciò che voglio in un linguaggio semplice nel canale Slack di Nakama. Solo io posso inviare richieste di modifica alle istruzioni degli agenti e ai prompt di sistema. Il coordinatore controlla il canale ogni 15 minuti circa, prende in carico la richiesta ed esegue l'aggiornamento.

Prototipazione della flotta in Claude

Non sono necessari Agenti gestiti per iniziare. Ho innanzitutto creato un prototipo dell'intera flotta in Claude, utilizzando i seguenti componenti:

• Una skill per agente: le istruzioni per un singolo lavoro.
• È prevista un'attività pianificata per ogni skill, in modo da non doverla eseguire manualmente.
• Una cartella condivisa sul mio laptop come knowledge base in cui ogni skill scrive ciò che ha imparato: la differenza tra ciò che ha redatto e ciò che ho inviato, oltre a qualsiasi novità scoperta lungo il percorso.

Sugli Agenti gestiti, la skill è diventata il prompt di sistema dell'agente, l'attività pianificata è diventata una pianificazione sulla distribuzione dell'agente (opens in new tab) e la cartella condivisa è diventata un archivio di memoria. Continuo a chiedere modifiche in un linguaggio semplice, ma ora faccio tutto in un unico canale Slack e ogni modifica alle istruzioni di un agente viene salvata come una nuova versione, pertanto ogni agente conserva una cronologia numerata delle proprie istruzioni. Suggerirei di iniziare in Claude e di trasferire i tuoi agenti in Agenti gestiti una volta che il loro numero diventa tale da non riuscire a monitorarli agevolmente.

Esecuzione della flotta su Agenti gestiti di Claude

Tre aspetti degli Agenti gestiti che si sono rivelati più importanti per il mio flusso di lavoro:

Gli agenti possono essere eseguiti in background

Gli agenti vengono eseguiti secondo la loro pianificazione, indipendentemente dal fatto che il mio laptop sia aperto o meno, anche quando è offline. La pianificazione fa parte della distribuzione di ogni agente. Potevo anche pianificare le skill in Claude, ma ognuna di quelle pianificazioni era un'attività configurata nella mia app. In Agenti gestiti, definisco la frequenza di esecuzione e il fuso orario nella Console, accanto alle istruzioni e agli strumenti dell'agente distribuito; non devo quindi gestire alcun cron job separatamente. Se un'esecuzione non va a buon fine, posso aprirla nella Console e visualizzare ciascun passaggio compiuto dall'agente. Mentre sto testando una modifica a un agente, le esecuzioni pianificate continuano a utilizzare la versione distribuita; in questo modo, una modifica ancora incompleta non finisce nell'esecuzione prevista per domani.

Nakama condivide un'unica memoria e impara dalle mie modifiche

Ogni agente legge e scrive all'interno dello stesso archivio di memoria (opens in new tab), quindi ciascun agente può utilizzare gli apprendimenti degli altri. Gli agenti confrontano le bozze che hanno scritto con le e-mail che ho inviato e salvano ogni differenza sotto forma di nota su come io la formulerei. Conservano inoltre tutte le nuove informazioni che trovano durante la ricerca di una risposta, dalla nostra documentazione interna e dai nostri siti web ufficiali. Correggo una formulazione una sola volta nelle bozze di Henji, e Sabaki e Nokori smettono di commettere lo stesso errore.

Le credenziali risiedono in un vault gestito con permessi con ambito definito

I miei agenti hanno accesso alle mie e-mail e ai nostri record su Salesforce, ma poiché si tratta di conversazioni con i clienti e record aziendali, volevo che tale accesso fosse gestito. Le credenziali risiedono in vault gestiti (opens in new tab), che proteggono le credenziali utilizzate dagli agenti per accedere a servizi esterni, come i token di accesso e aggiornamento OAuth, le chiavi API e i token di accesso personali. L'implementazione di ogni agente utilizza solo i vault necessari per il compito assegnato, l'agente non vede mai le credenziali e posso revocare l'accesso in un unico passaggio.

Affidare i passaggi successivi a Claude Tag

Per la maggior parte di ciò che il Nakama produce, mi basta leggere una bozza nella mia casella di posta e inviarla, o dare un'occhiata a un record Salesforce aggiornato. Tuttavia, alcuni elementi richiedono un passaggio di follow-up, come l'individuazione di un percorso di aggiornamento o di acquisto, o l'escalation di un problema a un altro team.

In questi casi, gli agenti non si fermano ad aspettarmi. Affidano l'elemento a Claude Tag (opens in new tab), attualmente in versione beta. Claude Tag è Claude configurato come membro del nostro spazio di lavoro Slack: chiunque si trovi in un canale a cui si è unito, una persona o uno dei miei agenti, può menzionare @Claude con una richiesta, che viene presa in carico e gestita nel thread. Una volta configurato nel tuo spazio di lavoro, non c'è nulla di nuovo da imparare. Puoi taggare Claude come faresti con un membro del team.

Nella mia configurazione funziona così. Un agente pubblica l'attività da svolgere sul canale Slack di Nakama e menziona Claude. Claude legge il thread, verifica le nostre regole e i termini che si applicano, delinea le opzioni e redige quanto necessario. Mi menziona quando un passaggio richiede la mia revisione o approvazione. Quando un cliente o un altro team deve rispondere per primo, Claude imposta un promemoria per ricontrollare la situazione in un giorno prestabilito. Nel thread riportato di seguito, è stato impostato un promemoria per martedì per verificare se il cliente avesse risposto e se il deal desk avesse dato riscontro al ticket. Quando scatta il promemoria, Claude controlla entrambi e pubblica un aggiornamento sullo stato delle cose nello stesso thread. Se qualcuno ha bisogno di un sollecito, redige il messaggio e mi menziona affinché lo invii.

Claude pubblica inoltre un brief mattutino con gli aggiornamenti sui prodotti e sui prezzi. Il coordinatore Nakama prende in carico quel brief e scrive le modifiche necessarie nella knowledge base condivisa.

Cosa è cambiato nella mia settimana

Ora che Claude prepara le risposte ai messaggi in entrata e mantiene aggiornati (nella maggior parte dei casi) i record CRM senza il mio intervento manuale, il mio ruolo è quello di esaminare tutto ciò che richiede un giudizio umano. Un regolamento scritto definisce l'ambito di ogni agente e stabilisce che questioni come domande sui prezzi, account sensibili o richieste ambigue vengano inoltrate a me. Ogni bozza di e-mail creata da Henji, Sabaki o Nokori arriva con un breve riepilogo in alto sulla situazione, così non devo ripercorrere l'intero thread per comprendere il contesto: leggo il riepilogo, confermo, apporto le modifiche e invio.

Analizzando il registro settimanale delle attività svolte dal Nakama e calcolando per ogni singolo compito il tempo che avrei impiegato a eseguirlo manualmente, emerge che la flotta mi fa risparmiare circa 60 ore di lavoro. Dedico il tempo che si libera ad attività che gli agenti non sono (ancora) in grado di svolgere in modo efficace: conversazioni con i clienti, strategie di outbound, progetti interfunzionali e supporto al team nella creazione delle proprie flotte.

Progettare agenti più efficienti

Gli agenti pianificati vengono eseguiti ogni giorno, a prescindere dal fatto che io li stia monitorando o meno; di conseguenza, possono accumularsi sprechi, sia in termini di costi che di affidabilità. Tra gli errori più comuni ci sono l'aggiunta di nuove indicazioni alle istruzioni esistenti anziché il loro aggiornamento, la fornitura agli agenti di più contesto di quanto necessario per le loro attività e l'esecuzione di ogni lavoro sul modello più grande con il livello di sforzo più elevato.

Ciò che rende gli agenti efficienti è soprattutto il modo in cui ho progettato la flotta: ogni agente ha un solo compito, quindi le istruzioni rimangono focalizzate su quel compito specifico; ogni agente operativo segue una pianificazione, quindi si attiva, completa il proprio ciclo e si ferma; infine gli agenti condividono la memoria, quindi una correzione effettuata una volta viene riutilizzata ovunque.

L'altro fattore importante è il modello su cui viene eseguito ogni agente. Una volta che il lavoro di un agente è ben definito, potrebbe non essere necessario ricorrere al nostro modello più capace. Furiwake e Shoudan seguono un insieme di regole scritte, quindi vengono eseguiti su Sonnet, il nostro modello più piccolo. Sabaki, Nokori e il coordinatore utilizzano Opus, il nostro modello più grande, poiché il loro lavoro richiede una maggiore capacità di giudizio. Il coordinatore ne ha maggiormente bisogno, poiché modifica le istruzioni degli altri agenti e una modifica errata raggiungerebbe ogni agente. Henji necessita di tanta capacità di giudizio quanto Sabaki, poiché l'e-mail di ogni cliente è diversa; inoltre, Henji viene eseguito più spesso di qualsiasi altro agente, durante l'intera giornata lavorativa. Eseguirlo ogni volta su Opus sarebbe l'opzione più costosa, perciò utilizzo la strategia del consulente (opens in new tab) in Agenti gestiti: Henji viene eseguito su Sonnet e, quando arriva a una decisione che non può prendere da solo, chiede un consiglio a Opus. Il consulente esamina quanto Henji ha fatto finora e invia un piano, una correzione o un segnale di stop, dopodiché Henji completa la bozza affinché io possa revisionarla. Inoltre, imposto il livello di impegno di ciascun agente (ovvero quanto tempo il modello dedica a pensare prima di rispondere), separatamente dal relativo modello, e lo aumento solo nei casi in cui il ragionamento risulta complesso, come avviene nelle risposte di Henji.

Cosa ho imparato

Tre cose che trasmetterei a chiunque stia costruendo la propria flotta.

1. Non è necessario un prompt dettagliato ogni volta. Descrivi il lavoro una volta, lascia che Claude prepari una bozza, correggila e lascia che memorizzi la correzione.
2. La knowledge base è più importante del prompt. Ogni correzione e interazione precedente viene salvata in uno spazio in cui tutti gli agenti possono leggere e scrivere, così Claude attinge il contesto da lì anziché da un prompt più lungo. Ci sono volute alcune centinaia di stesure rapide e semplici, tra bozze, correzioni e salvataggi, per far sì che i testi rispecchiassero il mio stile.
3. Dai a Claude più spazio, prima. All'inizio ho continuato a svolgere le attività che ritenevo richiedessero il mio intervento, come l'aggiornamento della knowledge base o la modifica manuale delle istruzioni di ogni agente. Entrambi hanno funzionato bene una volta che ho smesso di occuparmene in prima persona. Gli agenti ora scrivono autonomamente ciò che imparano nella knowledge base e il coordinatore aggiorna le istruzioni degli altri agenti quando glielo chiedo in linguaggio semplice. Ero stato troppo cauto riguardo al lavoro che avrei potuto affidare agli agenti.

Comincia a usare gli Agenti gestiti di Claude (opens in new tab)