Criamos um agente de suporte com IA que resolve 80% dos tickets — AssemblyAI

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: We Built an AI Support Agent That Resolves 80% of Tickets — AssemblyAI · Canal: AI Engineer · 15:57 · Assistir no YouTube

Tópicos: Agentes de IA, Aplicações empresariais de IA, Engenharia de software com IA, RAG, busca e recuperação de informação

Resumo

Matt Lawler, engenheiro de implantação da AssemblyAI, explica como o alto volume de novos clientes tornou inviável oferecer suporte técnico individual a todos. Depois de testar um bot pronto que resolvia apenas 10% das conversas, a equipe criou Joey, um agente com acesso à documentação, ferramentas e capacidade de buscar informações e ajudar clientes. Na primeira semana, Joey chegou a uma taxa de resolução de 80% dos tickets sem intervenção humana, com cerca de US$ 700 mensais em custos de tokens e infraestrutura. A equipe também adicionou interação por voz e usa a construção do agente para testar o próprio produto e entender melhor as necessidades dos clientes.

Pontos-chave

A AssemblyAI recebe cerca de mil inscrições na API por dia, volume que torna difícil oferecer atendimento individualizado por engenheiros de implantação.
Um bot de suporte pronto, limitado por não permitir ajustes diretos no system prompt, nas ferramentas e na infraestrutura de RAG, resolvia cerca de 10% das conversas.
Joey reúne documentação em arquivos Markdown locais, instruções de operação e acesso a ferramentas para responder e buscar informações.
A equipe atualiza e implanta Joey rapidamente, podendo corrigir problemas observados em conversas em andamento.
Na primeira semana, Joey atingiu 80% de resolução de ponta a ponta, com aproximadamente US$ 700 mensais em custos de tokens e infraestrutura.
Joey atende todos os tickets recebidos e encaminha cerca de 20% a humanos quando são necessárias ações como negociar condições, tratar exclusões de dados ou assinar acordos.
O agente ganhou interação por voz com a API de agentes de voz da AssemblyAI, que combina reconhecimento de fala, LLM e síntese de fala em tempo real.
Construir o mesmo tipo de produto que os clientes usam ajuda os engenheiros de implantação a testar a tecnologia e oferecer orientações mais úteis.

Capítulos

Início	Capítulo	Resumo
00:00	Apresentação e contexto da AssemblyAI	Matt Lawler apresenta seu trabalho e descreve a infraestrutura de voz da AssemblyAI e o crescimento da demanda.
03:33	Limites do suporte manual e do bot pronto	O volume de clientes torna o atendimento individual difícil de escalar, e o bot comprado pela equipe resolve apenas 10% das conversas.
05:07	Como Joey foi construído	A equipe apresenta Joey e explica como ele usa documentação em Markdown, embeddings, busca em arquivos e implantação na Railway.
08:12	Resultados e suporte por voz	Joey alcança 80% de resolução sem intervenção humana, e a equipe adiciona interação por voz para testar o próprio produto.
11:17	Arquitetura e demonstração de Joey	O palestrante mostra as instruções, os documentos e a implantação do agente, e demonstra uma conversa por voz sobre um BAA.
14:25	Construir o produto usado pelos clientes	A conclusão recomenda que engenheiros de implantação usem e construam o mesmo produto que seus clientes para oferecer suporte melhor.

Citações

Você não pode ser o gargalo para oferecer uma boa experiência ao cliente. — 04:04

Fomos de 10% para 80% de resolução de ponta a ponta já na primeira semana. — 08:12

Você precisa testar seu próprio produto o tempo todo. — 14:25

Agora que usei a mesma API, posso dar orientações melhores aos clientes. — 14:55

Conceitos e entidades

AssemblyAI (empresa): Empresa que oferece infraestrutura de IA de voz e modelos de fala para texto, além de uma API de agentes de voz.
Joey (conceito): Agente de suporte da AssemblyAI que responde a clientes por texto e voz e encaminha a humanos os casos que não consegue resolver.
Pylon (ferramenta): Ferramenta usada para acompanhar métricas e gerenciar conversas da equipe de suporte.
Voyage (empresa): Parceira cuja tecnologia de embeddings é usada para recuperar documentos relevantes para as respostas de Joey.
Railway (ferramenta): Plataforma usada para implantar Joey e publicar atualizações rapidamente.
Claude (modelo): Assistente mencionado na recomendação de usar arquivos Markdown para fornecer contexto sobre a empresa.
CLAUDE.md (conceito): Arquivo de instruções usado para fornecer a Joey orientações e salvaguardas para interações com clientes.

Tradução completa (pt-BR)

00:00 Legal. [música] Certo. Todo mundo está me ouvindo? Ok. Todos os níveis estão chegando bem. Certo. Ótimo. Então, como vocês estão? Como vocês estão? Melhor. Ok, agora sim. Legal. Espero que a conferência esteja sendo boa para todo mundo.

00:30 Agradeço a todos por estarem aqui para ouvir uma conversa minha. Para quem ainda não me conheceu no estande, meu nome é Matt Lawler. Sou um engenheiro de implantação na Assembly AI. Meu foco principal é receber clientes que chegam até nós, ajudar a conquistar o negócio deles e garantir que tenham uma boa experiência desenvolvendo com nossa API. Quantos outros engenheiros de implantação estão aqui na plateia agora? Alguém? Ok, alguns. Legal. Ainda está chegando bem. Certo. Então,

01:00 sim. Queria dar uma visão geral de algumas das iniciativas de engenharia voltadas para go-to-market que temos feito na Assembly AI e que talvez vocês possam aplicar à própria equipe de FTE ou à empresa de vocês como uma vitória fácil para seus clientes. Para dar um pouco de contexto sobre a Assembly AI, caso ainda não tenham ouvido falar de nós, oferecemos infraestrutura de IA de voz. Treinamos nossos próprios modelos de base, principalmente para converter fala em texto. Mas estamos começando a expandir para outras áreas do espaço de agentes de voz. Se vocês já tiveram um anotador de reuniões como o Fireflies entrando em uma reunião ou algo assim, vocês já viram uma transcrição da Assembly AI. Também treinamos nossos próprios modelos de base não só para casos de uso assíncronos, como gravações de reuniões e coisas do tipo, mas também para agentes de voz em tempo real. Se vocês já usaram um agente de atendimento ao cliente por telefone ao ligar para algum lugar, e não era uma pessoa, ou um sistema de pedidos em drive-thru, é bem provável que tenham sido desenvolvidos com os modelos da Assembly AI. E, para quem está desenvolvendo um agente de voz agora, vocês podem nos usar para toda a stack, não apenas para converter fala em texto. Assim, podem usar nossa API de agente de voz, e nós conectamos a conversão de fala em texto,

01:31 o LLM e também a conversão de texto em fala. Como nossos concorrentes sabem, como nós sabemos e como qualquer pessoa no espaço de IA de voz sabe, a demanda por IA de voz está absolutamente insana agora. No momento, na Assembly, vemos cerca de mil inscrições para API todos os dias. Isso explica, em parte, por que estávamos focados em automação e queríamos criar um novo bot de suporte para nossa equipe, porque, pelo menos até dois dias atrás, eu era o único engenheiro de integração de clientes na Assembly AI. Então dá para imaginar que, por mais que eu quisesse conversar com mil novas pessoas inscritas todos os dias, isso simplesmente não é viável.

02:02 Então, tivemos que criar algo para resolver esse problema. E, para quem não sabe o que é um engenheiro de implantação, é um título bastante abrangente. Varia muito de uma empresa para outra, mas, na prática, queremos trabalhar junto aos clientes finais. Queremos entender o caso de uso deles. Queremos garantir que estamos criando exatamente o que precisam. Por isso, frequentemente fazemos commit de código diretamente nos repositórios deles. Geralmente nos reunimos com eles várias vezes por mês, se não por semana. E nos esforçamos muito para entender o caso de uso e conhecê-los bem pessoalmente. Então, pelo menos

02:33 do lado dos clientes que chegam até nós, quem procura a Assembly para desenvolver conosco tem em nós o principal ponto de contato para qualquer coisa de que precise na parte técnica e comercial. Qualquer coisa de que precisem, recebem de nós, seus FTEs. E somos responsáveis por conquistar o negócio deles e construir essa relação de confiança. É um ótimo modelo de serviços. É ótimo se conseguirmos estabelecer esse tipo de relação com todos os clientes, mas, de novo, com cerca de mil inscrições para API por dia, não consigo atender tantos clientes ao mesmo tempo e participar de tantas chamadas. Então,

03:03 no fim das contas, isso não escala muito bem. Queremos garantir que estamos nos liberando para conduzir o máximo possível de negociações lideradas por pessoas, mas não podemos fazer isso com todas as negociações. Não podemos construir cada solução vencedora para um cliente manualmente. E não podemos simplesmente continuar contratando cada vez mais FTEs se quisermos atender cada vez mais clientes. Então, para quem aqui é FTE, quer se tornar FTE ou já tem uma equipe de FTE na empresa, eu recomendaria usar o conhecimento que vocês têm como FTE e tentar automatizar o próprio trabalho até não serem mais necessários. Acho que esse deveria ser o papel de vocês todos os dias. Se quiserem atender melhor

03:33 seus clientes, trabalhar mais com eles e oferecer uma experiência melhor em escala, vocês não podem ser o gargalo para uma boa experiência do cliente. E aprendemos isso na prática. Mais uma vez, estávamos afogados no volume de solicitações recebidas. Dá para ver que, mais cedo, tínhamos cerca de mil inscrições para API. E tivemos o instinto natural que muitas equipes têm: pensamos que só precisávamos desviar mais conversas. Eu só queria conversar com menos pessoas. Queria me liberar para trabalhar em coisas mais importantes. Então, basicamente, compramos um bot de suporte pronto e pensamos: “Vamos apontá-lo para a documentação. Ele vai responder a todas as perguntas sobre a documentação. Vai ser ótimo. Nunca mais precisaremos responder a uma pergunta simples de um cliente.” Mas ele só resolveu cerca de 10% das conversas. Ajudou. Dá para imaginar que, se tivéssemos mil conversas por dia, cem delas agora eram atendidas por um bot. Mas nossa equipe ainda precisava lidar com 900 tickets por dia. Então, não era exatamente muito escalável. Uma taxa de resolução de ponta a ponta de 10% não era suficiente. E, no fim das contas, não conseguíamos iterar rápido o bastante para corrigir isso. Não tínhamos acesso ao system prompt. Não tínhamos acesso às ferramentas. Não tínhamos

04:04 acesso à infraestrutura de RAG. Então, sempre que precisávamos mudar alguma coisa, procurávamos esse fornecedor, e ele dizia: “Bom, está no roadmap.” Isso não funcionava muito bem para nós. Então, queríamos criar o nosso próprio. Criamos outro membro para a equipe, em vez de contratar alguém, e demos a ele o nome de Joey. Agora, quem entra em contato conosco, seja pelo widget de chat no site, pelo contato com a equipe de vendas ou pelo nosso endereço de suporte, vai conhecer o Joey em vez de uma pessoa. Ele agora é a primeira linha de defesa para todas as conversas que acontecem na Assembly. E foi criado para ser

04:35 o FTE mais escalável possível da nossa equipe. Ele se lembra de conversas anteriores com você. Acompanhamos todas as métricas dele pelo Pylon, porque ele ainda é membro da nossa equipe de suporte e tem acesso ao Pylon para gerenciar conversas e lembrar quem você é. Ele foi criado com base no cloud agent SDK. E o legal é que ele consegue gerenciar a própria infraestrutura. Tem um sistema de arquivos. Pode escrever e depurar código para você. Pode chamar ferramentas. Pode adquirir novas habilidades. Então, ele consegue agir mais como um FTE e menos como um chatbot padrão com quem você

05:07 conversaria, sabe, na maioria dos grandes sites hoje em dia. Então, se quiserem saber um pouco sobre como criar seu próprio Joey, a arquitetura tem quatro partes principais. Como todos talvez saibam por trabalhar com o Claude, Markdown é seu amigo. Vocês devem fornecer arquivos Markdown ao Claude para que ele entenda tudo sobre a empresa. Queríamos que o Joey tivesse acesso a toda a nossa documentação e estivesse sempre atualizado sobre ela. Então, exportamos toda a nossa documentação como arquivos Markdown locais e a fornecemos ao Joey. Assim, sempre que publicamos uma atualização na nossa

05:38 o FTE mais infinitamente escalável da nossa equipe. Ele se lembra das conversas anteriores com você. Acompanhamos todas as métricas dele pelo Pylon, porque ele ainda é membro da nossa equipe de suporte e, por isso, tem acesso ao Pylon para gerenciar conversas e se lembrar de quem você é. E ele foi desenvolvido sobre o cloud agent SDK. O mais legal do que ele consegue fazer é gerenciar a própria infraestrutura. Ele tem um sistema de arquivos. Pode escrever e depurar código para você. Pode chamar ferramentas. Pode adquirir novas habilidades. E, assim, ele realmente consegue operar mais como um FTE e menos como um chatbot padrão com quem você

06:09 conversaria, sabe, na maioria dos grandes sites hoje em dia. Então, se você quiser saber um pouco sobre como criar seu próprio Joey, a arquitetura tem, por assim dizer, quatro partes principais. Como todos talvez saibam por trabalhar com Claude, Markdown é seu amigo. Você deve fornecer arquivos Markdown ao Claude para que ele entenda tudo sobre o seu negócio. Queríamos que ele tivesse acesso a toda a nossa documentação e estivesse sempre atualizado sobre ela. Então, exportamos toda a nossa documentação como arquivos Markdown locais e a entregamos ao Joey. E, sempre que enviamos uma atualização para o nosso

06:39 sistema de documentação, ele consegue obter todos esses arquivos e tê-los localmente no sistema de arquivos. Então, na verdade, o mais legal é que, se todo o nosso site de documentação estivesse fora do ar agora, você poderia falar com o Joey e ainda receber respostas atualizadas sobre tudo o que lançamos, sem que nossa equipe precisasse se envolver. Para a recuperação, assim podemos dar uma boa resposta. Temos uma parceria com a Voyage, então usamos os embeddings deles para que ele encontre logo de início os documentos mais relevantes, sem precisar passar muito tempo pesquisando, e consiga responder mais rápido. E, como ele tem todos esses documentos em arquivos locais, se ficar confuso ou precisar combinar vários recursos para criar uma resposta, ele consegue pesquisar de forma autônoma no sistema de arquivos onde está instalado, para encontrar esses recursos para você.

07:09 Assim, ele pode entrar nesse modo de reflexão profunda, no qual consegue pesquisar em todos esses recursos. Depois, lançamos tudo na Railway. Não queríamos lidar com infraestrutura. Não queríamos iniciar uma instância EC2. Não queríamos ter que mudar os tipos de instância. Então, implantamos tudo na Railway. O serviço deles é incrível. Basicamente, podemos verificar se ele teve uma conversa ruim com alguém no Slack. Podemos criar um PR rapidinho e fazer o deploy; em 30 segundos, há uma nova versão do Joey no ar. Então, conseguimos

07:40 iterar muito, muito rápido. Já aconteceu de acompanharmos uma conversa ao vivo, encontrarmos um bug, implantarmos uma correção e ela já estar valendo no restante da sessão, sem que o cliente sequer precise saber que fizemos essa correção nos bastidores. Assim, o Joey pode ser atualizado sempre que quisermos. Temos controle total sobre tudo o que ele faz. E os resultados da nossa construção foram impressionantes. Esse é outro motivo pelo qual eu queria incentivar todos aqui a tentarem criar seu próprio Joey. Na primeira semana após implantarmos essa versão, passamos de uma taxa de resolução de ponta a ponta de 10% para 80%, com uma implementação bem básica.

08:12 E fizemos tudo isso por cerca de US$ 700 por mês em custos de token, inference e infraestrutura. Resolvemos 80% dos nossos tickets de ponta a ponta, sem uma pessoa no processo. Algumas pessoas gostam de manipular essas métricas. Dizem: “Ah, resolvemos 80%, mas só em um subconjunto de tipos de ticket”. Não é o caso aqui. Você não consegue falar diretamente com uma pessoa, a menos que passe pelo Joey e peça para ele encaminhar o caso. Então, agora ele realmente cuida de 100% desses tickets recebidos. E só encaminha 20%

08:44 deles para uma pessoa, pelos motivos certos. Talvez seja uma mudança de tarifa. Talvez seja uma solicitação para não usar os dados. Talvez você precise assinar um contrato conosco ou tenha necessidades que exijam o envolvimento de um funcionário em tempo integral ou de alguém do jurídico. Essas são coisas que ainda precisam de uma pessoa, mas que eventualmente podemos automatizar. E o melhor é que tudo o que o Joey ainda não consegue fazer nos dá uma lista bem clara do que precisamos fazer para continuar expandindo nossa equipe. Se ele não consegue enviar um BAA, tudo bem, talvez devêssemos dar a ele um link que possa consultar como recurso. Se ele não consegue conversar com clientes sobre preços, você pode negociar com o Joey. Se você acessar

09:14 o site e testá-lo depois, pode dizer exatamente quantas horas tem. E ele vai informar uma tarifa, que você poderá negociar com ele. Tentamos automatizar muitas dessas outras coisas que ele ainda encaminhava para uma pessoa, e ainda há bastante coisa por vir. Mas, na verdade, o que queríamos testar ao criar o Joey era também usar nosso próprio produto. Não queríamos simplesmente criar algo que desviasse mais solicitações dos nossos clientes. Não queríamos criar algo que fosse apenas um bot de suporte genérico que qualquer pessoa pode criar. Trabalhamos com voz, e nossos

09:45 clientes criam agentes de voz. Então, eu queria criar um agente de voz e dar uma voz ao Joey. Agora, em vez de conversar com ele apenas por texto, você também pode conversar com ele usando a sua voz. Como mencionei antes, temos uma API de agente de voz. E a integramos ao Joey esta semana. Agora, se você acessar nosso site, pode mudar para o modo de voz e conversar com o Joey usando apenas a sua voz. No fim das contas, acredito que, para qualquer funcionário em tempo integral, não importa há quanto tempo você esteja implantado junto aos clientes nem o quanto esteja integrado às operações deles: a melhor maneira de entender o que seus clientes estão criando é criar você mesmo o mesmo produto. E foi exatamente isso

10:16 que queríamos fazer com isso. Então, incluímos nossa API de agente de voz no Joey. É tudo entrada e saída de áudio, em uma única conexão WebSocket, que combina nosso modelo de speech-to-text, um LLM e text-to-speech, tudo otimizado para voz. É em tempo real e tem baixa latência. Ele cuida de todas as pausas, do gerenciamento de interrupções, de entrar falando por cima e de todo esse tipo de coisa para você. Usamos nossas próprias vozes, então você não precisa encontrar outro provedor. E são as mesmas ferramentas que ele já tinha quando você conversava com ele por texto. A diferença é que agora você pode falar com ele como se ele fosse uma pessoa. E, com sorte, ainda esta semana poderemos conectá-lo a um

10:47 número de telefone. Assim, teremos um número de telefone da AssemblyAI para que você possa receber suporte em tempo real do Joey sempre que precisar. Vamos conversar um pouco com o Joey e mostrar ao vivo um pouco da arquitetura. Para quem quiser saber um pouco mais sobre como isso foi construído, temos basicamente toda a documentação clonada localmente em Markdown. Sempre que alguém atualiza nossa documentação, esses arquivos também são clonados localmente neste repo. Assim, ficam perfeitamente sincronizados com todos os novos recursos que lançamos, nosso changelog, nossos preços e todas essas páginas importantes do nosso site, que são convertidas para Markdown e fornecidas ao Joey.

11:17 Assim, ele vê tudo isso no formato Markdown e consegue ver qual é a URL para citar suas fontes ao cliente, caso ele queira conferir o trabalho do Joey ou simplesmente obter mais informações. Ao mesmo tempo, tudo é fornecido como instruções em CLAUDE.md. Acho que são umas 30 mil linhas de CLAUDE.md com todas essas diretrizes e recomendações sobre como ele deve interagir com os clientes. E é isso que atualizamos principalmente quando percebemos que ele teve uma experiência ruim com um cliente ou

11:48 deu uma resposta errada. Lançamos uma atualização para esse CLAUDE.md e, a partir daí, ele consegue se sair melhor em todas as conversas seguintes. E tudo isso está contido em um arquivo Docker. É muito fácil simplesmente empacotá-lo em um contêiner e fazer o deploy na Railway. Então, de novo, sempre que lançamos uma atualização para esse repo, uma nova versão já está no ar na Railway, sem que ninguém precise monitorar o deploy manualmente. Vamos iniciar o Joey aqui. Podemos fazer uma pergunta bem comum para você ver como é nossa API de agente de voz.

12:18 Então, vou simular isso localmente, porque sei que provavelmente muitos de vocês vão testar o Joey depois desta apresentação, e não quero aumentar a fila da nossa equipe de suporte de verdade. Então, vou fazer uma simulação local. Mas, normalmente, vocês entrariam aqui, conheceriam o Joey e fariam uma pergunta comum. Talvez conversassem com ele por texto, mas vamos falar com ele por voz. Oi, aqui é o Joey, da Assembly AI. Como posso ajudar você hoje? >> Oi, Joey. Quero criar um escriba médico ambiente com a Assembly AI, mas, antes de testar, preciso assinar um BAA. Você consegue fazer isso?

12:51 >> Um instante. Deixe-me verificar isso para você. Sim, você pode assinar o BAA por conta própria agora mesmo. Basta preencher nosso contrato padrão de associado comercial da HIPAA, mas lembre-se de que você precisará ter uma conta paga e um cartão cadastrado. E, ao assinar o BAA, você opta automaticamente por não participar do treinamento de modelos. Os documentos relevantes estão

13:22 com o link no chat. >> Legal. Obrigado, Joey. Bem, preciso voltar à minha demonstração. Adoraria conversar mais, mas obrigado por toda a ajuda. Por nada. Boa sorte com a sua demonstração e fique à vontade para entrar em contato se precisar de mais alguma coisa depois. Tenha um ótimo dia. >> Ele não é tão simpático? [risos] Gosto de conversar com o Joey. Acho que nossos clientes vão gostar de conversar com o Joey. Mas este é um ótimo exemplo de como, há dois anos, quando entrei para a equipe de suporte da Assembly, esta conversa teria que ser atendida por uma pessoa. Isso é algo

13:52 que, se você entrasse em contato pelo chat e um cliente ou engenheiro de suporte não conseguisse responder imediatamente, teria que esperar. Teria que receber uma resposta nossa. Era uma resposta pronta. Simplesmente não era uma ótima experiência para o cliente. Agora, você tem um funcionário em tempo integral com quem pode conversar 24 horas por dia, 7 dias por semana, para tirar essas dúvidas básicas. E pode fazer isso por voz. Assim, você pode testar nosso produto ao mesmo tempo. Então, há uma espécie de camada meta aí: se você está conversando com o Joey sobre como criar um agente de voz com nossa API, já está usando o produto. E já está vendo exatamente como poderia ser a experiência com o seu produto.

14:25 Então, se há algo que vocês devem levar desta palestra, não é só que deveriam criar seu próprio Joey. Acho que, se você é um funcionário em tempo integral na sua empresa, precisa usar o próprio produto o tempo todo. Não basta ensinar seus clientes a começar a usá-lo. Para cada novo recurso que lançar, para cada novo produto que oferecer, você precisa ensinar seus clientes com todo o conhecimento que adquiriu usando, criando e tentando lançar o mesmo produto. Então, tive que enfrentar os mesmos obstáculos. Tive que descobrir como lidar com latência. Tive que descobrir como lidar com a alternância de turnos, barganha ou tratamento de interrupções.

14:55 E acho que agora tenho muito mais empatia para trabalhar com os clientes que querem usar nossa API de agente de voz. Porque agora eu mesmo a usei. Usei a mesma API, exatamente aquela em que meus clientes desenvolvem, e posso dar conselhos melhores porque lancei algo com ela. Então, vão lá e criem alguma coisa. Criem seu próprio Joey, criem um agente de voz — especialmente se for um agente de voz, criem-no com a Assembly AI. Mas, se vocês trabalham em tempo integral, tentem criar exatamente o produto que seus clientes estão criando e façam isso por conta própria. Não esperem simplesmente que eles peçam ajuda

15:26 ou que vocês removam todos os obstáculos deles. Vocês deveriam ir lá e criar exatamente a mesma coisa. E, ao mesmo tempo, talvez consigam melhorar a experiência dos clientes também. Então, se alguém tiver dúvidas sobre como criar o Joey ou quiser conhecê-lo no estande depois, nosso estande fica logo ali. Se alguém tiver comentários sobre o Joey, já que ele foi lançado esta semana, ou se tiver uma conversa estranha com ele, eu adoraria saber, para que possamos continuar fazendo correções e eu possa mostrar como fazemos o deploy ao vivo. Mas, no geral, estou muito animado por estar aqui na conferência e conversar com mais pessoas sobre agentes de voz. Então, obrigado

15:57 por virem e ouvirem esta palestra. >> [aplausos] [música]

Transcrição original

[00:00] Cool. [music] All righty. Can everyone hear me? Okay. All All levels coming through good. All right. Sweet. Well, uh, how’s everyone doing? How’s everyone doing? Better. Okay, there we go. Cool. Well, I hope uh the conference has been good for everybody.

[00:30] Appreciate you all being here to to listen to a chat from uh from me. Um for anyone who hasn’t met me at the at the booth yet, uh my name is Matt Lawler. I’m a forward deployed engineer at Assembly AI. Uh mostly focused on bringing in inbound customers, um helping win their business, u making sure that they have a good time building with our API. Um so, how how many other like forward deployed engineers are out in the audience right now? Any of us? Okay, a couple. Cool. Well, um, still coming through. Okay. All right. Um,

[01:00] yeah. So, I wanted to make sure I I gave you guys an overview of kind of some of the go to market engineering stuff that we’ve been doing at Assembly AI that maybe you can apply to your own FTE team or maybe you can apply to your company um, as something that you can do as an easy win for your customers. Um, so for a little bit of overview of like assembly AI in case you haven’t heard of us, um, we provide voice AI infrastructure. Um, so we train our own foundation models for speech to text primarily. Um, but we’re starting to branch into other parts of the voice agent space. Um, so if anyone’s ever had like a Fireflies note-taker join your meeting or something like that, you’ve

[01:31] also you’ve already seen a transcript from Assembly AI. Um, so we train our own foundational models not only for like async use cases like meeting recordings and things like that, but also for real time uh real-time like voice agents. Um, so if you’ve ever used like a a phone customer support agent when you called in somewhere and it wasn’t a human or like drive-through ordering, they’re more than likely building with Assembly AI’s models. Um, and for anyone who’s building a voice agent now, you can use us for the entire stack, not just speech to text. Um, so you can use our voice agent API and we’ll string together the speech to

[02:02] text, the LLM, and the text to speech as well. Um, as our competitors know, as we know, as anyone in the voice AI space knows, demand is absolutely insane um, for voice AI right now. Um, so assembly at our current moment, we see around a thousand API signups every single day. Um, which is somewhat of the theme of why we were focusing on automation and wanting to build kind of a new support bot for our team because at least until like two days ago, I was the only uh onboarding engineer at Assembly AI. And so you can imagine, as much as I’d want to talk to a thousand new signups every

[02:33] single day, that’s just not feasible. Um, so we had to build something to to solve that problem. And then for anyone here who doesn’t know like what a forward deployed engineer is, it’s a very catch-all title. It varies a lot at every different company, but effectively we want to get deployed with our end customers. We want to understand their use case. We want to make sure that we are building exactly what they need. Um, so we frequently commit code directly to their repositories. We usually meet with them several times a month, if not a week. Um, and we really try to understand their use case and get to know them very personally. Um so like at

[03:03] least on the inbound side for anyone who comes into assembly who wants to build with us we are the people um that are their main point of contact for anything they need on the technical commercial side anything that they might need they get from us their FTE um and we’re responsible for winning their business um and building that trust with them. So it’s a great services model. It’s great uh if we can actually get that kind of relationship with every customer, but again with like a thousand API signups every day, I I can’t be one to many serving that many customers and getting on that many calls. Um and so

[03:33] ultimately this doesn’t really scale super well. Uh we want to make sure that we’re freeing ourselves up to be leading uh humanled deals as much as possible, but we can’t do that with every deal. Not every customer win can be like handbuilt by us. Um and we can’t just continue to hire more and more FTEEs if we’re going to try and serve more and more customers. Um, so ultimately like for anyone who’s an FTE in here, if you’re looking to become an FTE, if you already have an FTE team at your company, I would encourage you to take that knowledge that you have as an FTE and try to automate yourself out of a job. I think that should be your role every single day. If you want to serve

[04:04] your customers better, if you want to work with them more, um, and if you want to deliver a better customer experience at scale, you can’t be the bottleneck to having a good customer experience. And we learned that firsthand. So again, we were drowning in like inbound um, volume. Um, you can see like we basically had a thousand API signups up there earlier. Um, and we had the natural instinct that a lot of teams do where we were like, we just need to deflect more conversations. I just want to talk to fewer people. I want to make sure I’m freeing myself up to work on more important stuff. Um, so we basically bought this off-the-shelf support bot and we’re like, let’s point

[04:35] it at the docs. It’ll answer all the docs questions for us. It’s going to be great. We’ll never have to answer a simple question from customers again. And it only resolved about 10% of the conversations. Um, so it helped. Um, you can imagine if we had like a thousand conversations a day, a hundred of those were now entered by a bot. But then our team still had to field 900 tickets a day. So it wasn’t exactly very scalable. Um, so 10 10% uh end to end resolution rate wasn’t good enough. And ultimately we couldn’t iterate fast enough to be able to fix this. We didn’t have access to the system prompt. We didn’t have access to the tools. We didn’t have

[05:07] access to the rag infrastructure. So anytime we needed to change something, we’d go to this vendor and they’d say, “Well, it’s on the road map.” and that didn’t quite work for us. So, we wanted to build our own. So, we built uh another member of our team rather than hiring one and we named him Joey. Um so, anyone now who reaches out to us, whether it’s on our chat widget on our site, whether you reach out to contact sales, whether you reach out to our support alias, you’re going to meet Joey instead of a human. Um he’s the first line of defense now for every single conversation that happens in bounded assembly. And he’s built to be

[05:38] the most infinitely scalable FTE on our team. Um, so he remembers past conversations with you. Um, we track all of his metrics via Pylon because he’s still a member of our support team and so he has access to Pylon to manage conversations and remember who you are. Um, and he’s built on top of the cloud agent SDK. And so the cool things that he’s able to do is he can manage his own infrastructure. He has a file system. He can write and debug code for you. He can call tools. He can give himself new abilities. Um, and so he’s actually able to operate more like an FTE and less like just a standard chatbot that you’d

[06:09] be talking with, you know, on on most major sites nowadays. So, um, if you want to know a little bit of like how to build your own Joey, um, the architecture kind of has like four major parts. Um, so as everyone might know from working with Claude, Markdown is your friend. You should be giving Markdown files to Claude so that he understands everything about your business. And so we wanted him to have access to all of our documentation and be trained up on it all the time. So, we checked all of our docs out as local markdown and gave it to Joey. Um, and so anytime that we push an update to our

[06:39] documentation system, he’s able to get all of those files and he has them locally in his file system. So, actually what’s really cool is if our entire doc site was down right now, you could go to Joey and still get live answers on all the newest stuff that we’ve shipped without our team having to actually get involved. um for retrieval so we can give you a good answer. We partner with Voyage so we use their embeddings um so that he gets the most relevant documents up front so he doesn’t have to spend a lot of time searching and he can get you a faster answer. And then since he has all these docs as local files if he gets confused or he needs to string together

[07:09] multiple resources to create a response he can agentically search the file system that he lives on so that he can go and find those resources for you. Um so he can kind of go into this like deep thinking mode where he’s able to search across all these resources and then we shipped it on railway. We didn’t want to deal with infrastructure. We didn’t want to spin up an EC2. We didn’t want to have to change instance types. So, we deployed it all on Railway. Their service is pretty incredible. Basically, we can just go ahead and see if he has a bad conversation with someone in Slack. We can write a PR real quick and we can deploy it and within 30 seconds there’s a new live version of Joey. So, we’re

[07:40] able to iterate really, really quickly. Uh we’ve actually had times where we’ve actually monitored a live conversation, caught a bug, deployed a fix, and then it’s been proof for the rest of the session, and that customer doesn’t even have to know that we we shipped that fix behind the scenes. Um so Joey is able to to basically get updated whenever we want. Um so we actually have full control over everything that that he does. Um and so the results were pretty remarkable from us building this. And it’s another reason why and wanted to encourage everyone who’s here to try and build your own Joey. So, we went from 10% to 80% endto-end resolution rate in

[08:12] just the first week of deploying this this build with a pretty naive implementation. And we did that all for around $700 a month in both token and inference uh or infrastructure costs. So, we resolved 80 80% of our our tickets end to end with no human in the loop. And some people like to game these metrics. They’ll say like, oh, we resolved 80% but only on like a subset of types of tickets. Not the case here. you cannot reach a human directly unless you go through Joey and you tell him to escalate. So he actually does handle 100% of these inbound tickets for us now. Um and he only escalates 20% of

[08:44] them to a human for the right reasons. Maybe it’s a rate change. Maybe it’s a data opt out. Maybe you need to sign an agreement with us or you have needs that only an FTE or someone from legal needs to be involved in. These are things that actually still need a human but eventually we can automate. Um and so the best part is whatever Joey can’t do yet gives us a very clear list of what we need to do to continue to scale our team. Um, if he’s not able to send them a BAA, well, okay, maybe we should give him a link that he can reference as a resource. Um, if he’s not able to talk to customers about pricing, well, you can negotiate with Joey. Um, if you go

[09:14] on the site and you test him out afterwards, you can tell him exactly how many hours you have. Um, and he’ll actually quote you a rate and then you can negotiate with him. Um, so we tried to automate a lot of these other things that he was still escalating and there’s still there’s still plenty more to come. But the real thing that, you know, we wanted to test out by building Joey was we wanted to dog food our own product, too. We didn’t want to just like build something that deflects more stuff from our customers. We didn’t want to build something that just um is kind of this general support bot that anyone can build. We work in voice and our

[09:45] customers build voice agents. So, I wanted to build a voice agent and so I wanted to give a voice to Joey. So, now rather than just chatting with him via text, you can actually chat with him using your voice as well. Um, so we have a voice agent API as I mentioned earlier. Um, and we integrated this into Joey this week. So now if you go onto our site, you can switch to voice mode and you can talk to Joey using just your voice. Um, because I ultimately think for any FTE here, no matter how much you’ve been deployed with your customers, no matter how embedded you are with them, the best way to understand what your customers are building is to actually build their same product yourself. And that’s exactly

[10:16] what we wanted to do with this. So we put our voice agent API into Joey. Um, it’s all speech in, speech out, one websocket connection where we string together our speechto text model, an LLM and text to speech, all optimized for voice. It’s real-time and low latency. It handles all the pauses, interruption handling, barge, all of that kind of stuff for you. U, we bring our own voices, so you don’t have to find another provider. And it’s all the same tools that he already had if you were communicating with him via text. It’s just now you can actually talk to him like you were a human. Um, and hopefully later this week we can hook them up to a

[10:47] phone number. So now we’ll have an Assembly AI phone number so you can get real-time support from Joey whenever you need it. So let’s go ahead and talk to Joey a little bit and we can walk through some of the architecture live. Um so for anyone who wants to know a little bit more about how this was actually built um we basically have all of the the docs checked out locally in Markdown. Um so every single time someone puts an update out to our docs, these files also get locally checked out into this repo. So they stay perfectly in sync with any new features that we’re shipping, our change

[11:17] log, our pricing, all of these major uh pages from our website get converted to markdown and get given to Joey. Um so he sees all of these in markdown format and he’s able to see what the URL is so he can site his sources to the customer in case they want to double check his work or if they just want more information. Um at the same time, um all of it is provided as like Claude MD instructions. I think it’s like a 30,000 line Claude MD of all these guard rails and and advice on how he should be operating with customers. Um, and this is what we majorly update whenever we see that he had a bad experience with a customer or

[11:48] gave a wrong answer, we ship an update to this cloud MD and now for every conversation that he has going forward, he’s able to be better. Um, and it’s all contained as a Docker file. Um, and so it’s really easy to go and just containerize and deploy him on Railway. Um, and so again, every time we ship an update to this repo, a new version’s already live on Railway and no one had to manually monitor the deployment. Um, so let’s go ahead and uh I’ll fire up Joey here. we can ask him a pretty typical question so you can see what our voice agent API is like.

[12:18] So I’m going to simulate this locally because I I know probably many of you are going to test Joey after this and I don’t want to add to the queue for our actual support team. Um so I’ll I’ll go ahead and just do a local simulation of it. But typically, yeah, you would go into here, you’d meet Joey, you’d want to have a typical question. You might talk to him via text, but let’s go ahead and talk to him with voice. Hi, this is Joey at Assembly AI. How can I help you today? >> Hey Joey, I’m looking to build an ambient medical scribe with Assembly AI, but before I can test, I need to assign a BAA. Is that something that you can do?

[12:51] >> One sec. Let me check that for you. Yes, you can execute the BAA yourself right away. Just complete our standard HIPPA business associate agreement, but note that you’ll need a paid account with a card on file first. And signing the BAA automatically opts you out of model training. The relevant docs are

[13:22] linked in the chat. >> Cool. Thanks, Joey. Well, I got to I got to get back to my demo. I’d love to chat more, but uh thanks for all the help. You are very welcome. Good luck with your demo and feel free to reach out if you need anything else later. Have a great day. >> Isn’t he so nice? [laughter] I enjoy talking to Joey. I think our customers will enjoy talking to Joey. But this is a great example of like two years ago when I first joined assembly on our support team. This is a conversation that would have to be handled by a human. This is something

[13:52] that if you roached out in in chat and a customer uh or a support engineer wasn’t able to uh answer you immediately. They’d have to wait. They’d have to get a response from us. It was a canned response. Um it was just not a great customer experience. And now you have an FTE that you can talk to 24/7 for these basic questions. Um and you can do it through voice. So you can actually test our product at the same time. Um so there’s there’s kind of a meta layer there of where if you’re talking to Joy about how to build a voice agent API, you’re already using it. Um, and you’re already seeing exactly what your product experience could look like.

[14:25] So, if there’s anything that you should get out of this talk, it’s not just that you should build your own Joey. Um, but I think that it’s like if you’re if you’re an FTE at your company, you need to be dog fooding your own product all the time. It’s not enough to just be teaching your customers how to get started with it. any new feature that you launch, any new product that you offer, you need to be teaching your customers, um, with all the knowledge that you’ve built from actually using and building and trying to ship the same product. Um, so I had to run through all the same walls. I had to figure out how to deal with latency. I had to figure out how to deal with turn taking or bargain or interruption handling. Um,

[14:55] and I think I have a lot better empathy of how to like work with customers that you want to use our voice agent API. Um, because now I’ve actually used it. I’ve used the same API. It’s the exact one that my customers build on and I can give them better advice because I’ve actually shipped something with it. So go build go build something. Go build whether it’s a your own Joey, go build whether it’s a voice agent, especially if it’s a voice agent, build it on Assembly AI. Um, but if you’re if you’re actually working in an FTE capacity, try to build the exact product that your customers are building and do it on your own. Don’t just wait for them to ask you

[15:26] for help. Don’t just wait to remove all their blockers. You should be going out and building the exact same thing. And at the same time, you might actually be able to make your customer experience better simultaneously. So, um, if anyone has like questions on how to build Joey, if you want to check them out at the booth afterwards, our booth is just right over here. Um, if anyone has feedback on Joey since this just shipped this week, if you have a weird conversation with him, I’d love to know about it so we can keep making fixes and I can show you how we deploy that live. U, but overall, really excited to uh, be here at the conference and talk to more people about voice agents. So, thanks

[15:57] for uh, coming and listen to this talk. >> [applause] [music]