Nel 1968, un celebre studio scoprì qualcosa che avrebbe plasmato la Silicon Valley per decenni: i migliori ingegneri software erano drammaticamente più produttivi dei loro colleghi. Da allora, ogni azienda tecnologica è stata a caccia di quei rari individui capaci di generare risultati straordinari.
Di ritorno dalle vacanze a gennaio, dopo essere stati influenzati dai progressi dei modelli di frontiera, il nostro team di ingegneria ha iniziato a eseguire agenti in parallelo con git worktrees, Claude Code e Codex. Su alcuni compiti riuscivano a fare 5 volte di più.
Questo ha sollevato una domanda più grande: se gli agenti potessero rendere gli ingegneri così più produttivi in un mese, cosa servirebbe per portare tutti in Sierra a quel livello? Abbiamo creato un team di accelerazione AI di sei persone per scoprirlo. Questo blog spiega cosa abbiamo costruito e cosa abbiamo imparato nel processo.
1. Agente, singolare
Abbiamo iniziato con un gruppo di agenti specifici per ruolo: un agente di supporto (PINE), un analista dati (Pinewood), un ingegnere (Pinecone) e un agente di vendita (Reggie Jr). Un agente per ruolo può sembrare intuitivo, ma in pratica ha fallito.
Superficialmente, il problema era il carico sui dipendenti, che dovevano ricordare quale agente facesse cosa. Il nostro amore per i nomi a tema pino non ha aiutato. Ma il problema più profondo era strutturale: il lavoro più importante avviene tra i team, non al loro interno.
In fondo, le aziende sono un insieme di lavori da svolgere. Prendiamo il lancio di un prodotto. Coinvolge team tecnici, ma anche vendite, marketing, legale e operazioni. I dipartimenti esistono perché un team o una persona non può fare ogni parte del lavoro. L'AI cambia tutto questo, poiché può sempre più completare il lavoro dall'inizio alla fine.
Così abbiamo riunito tutti questi agenti specifici per ruolo in Pinecone: un unico agente con un singolo handle Slack, un singolo URL e un unico thread ininterrotto dalla domanda al risultato finale. Pinecone capisce da quali sistemi attingere e cosa fare con una richiesta, così i dipendenti non devono preoccuparsene. È tecnicamente difficile, ma questo è il punto dell'AI: la tecnologia assorbe la complessità, non il dipendente.
È una lezione che avevamo già imparato con la nostra piattaforma. Gli agenti costruiti su Sierra sono full-service: un solo agente può gestire qualsiasi cosa, dalla scoperta del prodotto alla configurazione dell'account, alla risoluzione dei problemi, alla fatturazione e altro ancora. Non "premi 1 per le vendite, premi 2 per il supporto" come un vecchio IVR.
Riunire tutto in un unico agente ti avvicina molto di più a dove risiede il valore in un'azienda: i lavori da svolgere. Ogni miglioramento avvantaggia l'intera attività, quindi tutti migliorano, più velocemente.
2. Proattivo, non reattivo
La maggior parte del lavoro non viene completata in una singola sessione. Si svolge nell'arco di giorni, settimane o addirittura mesi, mentre i team imparano, le priorità cambiano e emergono nuove informazioni. Un agente che si presenta quando viene chiamato e scompare quando la sessione finisce è solo fino a un certo punto utile. Pinecone persiste durante l'intero processo: porta avanti il contesto e riprende il filo, fino a quando il lavoro, non solo la singola richiesta, è completato.
La persistenza rende anche Pinecone proattivo. Invece di aspettare di essere interpellato, può agire quando il passo successivo è pronto: un webhook si attiva su un artefatto, un'attività arriva in Linear, arriva una revisione. Raccoglie il contesto e fa un primo passaggio, coinvolgendo le persone quando è necessario il loro giudizio. Le note preparatorie sono pronte prima di una riunione. I debrief dei colloqui sono abbozzati prima che ti siedi per aggiungere i tuoi punteggi. Le revisioni arrivano con riassunti, rischi chiave e commenti suggeriti. L'obiettivo non è più notifiche. È meno lavoro che arriva incompiuto.
Non l'abbiamo ancora perfezionato del tutto — la maggior parte delle sessioni inizia ancora con un prompt umano — ma invertire quella relazione, così che siano gli agenti a sollecitare gli umani quando necessario, è dove la persistenza ci sta portando.
3. Il contesto aziendale è il collo di bottiglia, non l'intelligenza
Il collo di bottiglia con l'AI era l'intelligenza grezza: se un modello fosse abbastanza intelligente. Oggi, i modelli di frontiera sono sufficientemente capaci per la maggior parte delle esigenze aziendali. Quindi il collo di bottiglia si è spostato sul contesto: ciò che è specifico della tua azienda, dei tuoi flussi di lavoro, della tua storia, delle valutazioni che non compaiono in nessun set di addestramento.
A gennaio, due persone del nostro team hanno assemblato un agente analista dati con Claude Code e Opus 4.6, collegato ai nostri sistemi tramite Model Context Protocol (MCP) e strumenti da riga di comando. Senza molte ulteriori indicazioni, poteva indagare su un problema di un cliente attraverso Slack, GitHub, ClickHouse, Salesforce e PagerDuty in pochi minuti. Un lavoro che una volta consumava un intero pomeriggio è diventato il primo passo nel debugging e nella risposta agli incidenti.
Lo stesso schema si estende ben oltre il debugging. Un agente con contesto completo può preparare una riunione con un cliente, fare ricerche su un account, revisionare un contratto o una RFP, tracciare una decisione di prodotto e trasformare un lavoro frammentato in un artefatto finito. Naturalmente, dare a un agente accesso a tutto quel contesto introduce un nuovo problema. Un agente senza restrizioni è un enorme rischio per la sicurezza e la privacy. Il nostro MCP Gateway risolve questo: Pinecone eredita l'accesso di ogni dipendente, applica le policy a ogni chiamata agli strumenti, isola i dati dei clienti e lascia una traccia di audit.
leggi descrizione immagine
ALT
Il gateway MCP di Sierra collega gli agenti a 37 sistemi
Pinecone è costruito su Claude Code e Codex. I loro frequenti miglioramenti sono un vento a favore, ma lo stato dell'arte cambia costantemente: un modello può essere il migliore per la pianificazione, un altro per la codifica, un altro per la prosa. Possedere il livello sopra i modelli ci consente di instradare ogni compito al modello giusto, fallire durante i downtime e gestire i costi, evitando di essere in balia di un singolo attore. Ma il vantaggio duraturo non è possedere il modello sottostante. È possedere il contesto, i flussi di lavoro e il livello di instradamento che rendono ogni modello più utile.
Stiamo anche sperimentando lasciando sognare Pinecone: riflettere sul lavoro di ogni giorno e proporre miglioramenti alle proprie capacità. Col tempo, questa è la differenza tra un agente che funziona solo per Sierra e uno che impara da Sierra.
4. L'agente è l'interfaccia utente, il sistema di registrazione il backend
Ogni pezzo di lavoro produce qualcosa di concreto, un artefatto. Gli agenti di codifica hanno trovato prima il loro: la pull request. Ogni altro dipartimento ha il suo equivalente: una storia cliente, un contratto, un questionario RFP, una presentazione, una valutazione delle prestazioni.
Gli artefatti sono sia input che output. Danno agli agenti il contesto di cui hanno bisogno per svolgere il lavoro — e sono il luogo in cui il lavoro finito appartiene. Chiedi a Pinecone di stringere una presentazione, e la presentazione stessa torna aggiornata, non un messaggio chat che ti dice cosa cambiare.
Abbiamo scoperto che è meglio lavorare con i tuoi sistemi di registrazione, non sostituirli. GitHub mantiene la PR, Salesforce mantiene l'account e Linear mantiene l'issue: l'agente è il livello che li attraversa.
Sostituire quei sistemi significa ricreare decenni di software maturo. Peggio ancora, divide l'azienda in due: persone che lavorano tramite l'agente e persone che lavorano direttamente negli strumenti originali, ognuna con la propria versione della verità. La nostra scommessa è che questi prodotti diventino sempre più come backend nel tempo, con l'agente come interfaccia primaria.
5. Risultati, non solo attività
Dal primo commit di Pinecone a marzo, ha eseguito più di 75.000 sessioni per oltre 600 persone. Oggi, il 70% delle nostre PR vengono aperte tramite esso, mentre centinaia di automazioni gestiscono silenziosamente lavoro che nessuno ha esplicitamente richiesto.
Numeri del genere sono tentanti da mettere in primo piano, e all'inizio sono la cosa giusta da tracciare — sono la prova che qualcosa viene effettivamente usato, non che se ne sta su una slide di roadmap a prendere polvere. Ma sessioni eseguite e chiamate agli strumenti sono attività, non risultati. Un team può tokenmaxare fino a ottenere un grafico di adozione impressionante senza che nulla a valle migliori realmente — lo stesso numero di errori, gli stessi tempi di ciclo, solo più AI coinvolta nel produrli.
Quindi l'uso dei token è un buon punto di partenza. I team devono formare l'abitudine di usare lo strumento prima di poter misurare se funziona. Ma non è lì che risiede il valore, e non vogliamo che sia lì che la storia finisce. La domanda a cui stiamo cercando di dare una risposta migliore non è quanto ha fatto un agente — è cosa è effettivamente cambiato grazie a esso: se un accordo è stato chiuso più velocemente, se il problema di un cliente è stato risolto al primo tentativo, se qualcuno si è ripreso la sua serata invece di finire una revisione a notte fonda.
Non abbiamo ancora un buon modo per misurarlo. Sessioni e chiamate agli strumenti sono solo più facili da contare. Ma quel divario — tra ciò che possiamo misurare oggi e ciò a cui teniamo realmente — è la prossima cosa verso cui stiamo costruendo.
Quello studio del 1968 trovò un divario di 10X tra i migliori e gli altri — e per cinquant'anni l'unica risposta è stata andare a caccia di quelle rare persone. Ora ce n'è una migliore: dare a tutti un agente, in modo che abbiano i vantaggi dei pochi. L'obiettivo non è solo fare di più. È dare alle persone più tempo per il lavoro che solo le persone possono fare: giudizio, gusto, creatività e costruzione di relazioni.
Prossimi passi
Approfondiremo i sistemi che abbiamo costruito:
- Allen Chen su Pinecone, le sue numerose iterazioni e l'architettura tecnica dietro di esso
- Mihai Parparita su MCP Gateway e la raccolta sicura del contesto completo
- Rohith Ravi su Agency, l'infrastruttura sottostante
