AI Engineer World's Fair 2026

We Built an AI Support Agent That Resolves 80% of Tickets — AssemblyAI

Read the talk

We Built an AI Support Agent That Resolves 80% of Tickets — AssemblyAI

AssemblyAI’s Joey combines local documentation, retrieval, agent tools and rapid deployment to handle inbound support. Adding voice turns the same agent into both a customer service channel and a working example of the product its customers build.

From a talk by Matt Lawler

At a glance

Ideas worth remembering

  • Owning the prompt, tools and retrieval system lets a team turn observed support failures into changes it can deploy, rather than requests on a vendor’s roadmap.

  • Joey combines embedding retrieval for relevant documents up front with agentic filesystem search when an answer needs additional resources.

  • AssemblyAI reports 80% end-to-end resolution across inbound tickets in Joey’s first week; escalations identify both necessary human work and candidates for further automation.

  • Voice mode retains Joey’s existing tools while the Voice Agent API connects speech-to-text, an LLM and text-to-speech over one WebSocket.

  • Building with the same API as customers exposes practical problems in latency and conversational timing, giving FDEs experience that improves their advice.

A thousand signups meet one onboarding engineer

AssemblyAI had around 1,000 API signups every day, and until two days before this talk, Matt Lawler had been its only onboarding engineer. That mismatch is the starting point for Joey, the company’s support agent. Lawler’s job was to help incoming customers build with AssemblyAI and win their business; personally meeting every new developer was already impossible.

Selected presentation frame from We Built an AI Support Agent That Resolves 80% of Tickets — AssemblyAI at 152 secondsOpen full source frame
Matt Lawler presents at the AI Engineer World's Fair.

The product helps explain the demand and the eventual shape of the solution. AssemblyAI supplies speech-to-text models for recorded audio and real-time applications. Its Voice Agent API extends that stack by connecting speech recognition, an LLM and speech synthesis. Customers need help building products whose behavior unfolds during a conversation, rather than simply submitting a recording and receiving a transcript.

A forward-deployed engineer, or FDE, supplies unusually close support: understanding a customer’s use case, committing code to its repository, meeting repeatedly and becoming the contact for technical and commercial questions. That relationship builds trust, but every call and custom implementation consumes human time. Hiring more FDEs in proportion to incoming customers would keep the same constraint in place.

Lawler’s deliberately provocative instruction is to “automate yourself out of a job.” In this setting, that means putting the team’s knowledge into a system that can serve customers without waiting for the person who holds it. Human-led deals still matter. Automation should free the team to work on them while giving other customers a useful path forward.

0:231:54
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:23 · section reference included

Ten percent resolution exposed an iteration problem

The first attempt followed a familiar instinct: buy a support bot, point it at the documentation and deflect simple questions. It resolved about 10% of conversations end to end. Lawler illustrates the remaining workload with a hypothetical 1,000 conversations: 100 answered by the bot still leaves 900 for the team. The signup count establishes the scale of inbound demand; it does not mean every signup created a ticket.

Selected presentation frame from We Built an AI Support Agent That Resolves 80% of Tickets — AssemblyAI at 305 secondsOpen full source frame
A slide titled “A tiny team, drowning in inbound” shows a 10% resolved end-to-end figure.

The more consequential problem was control. AssemblyAI could not change the bot’s system prompt, tools or retrieval-augmented generation infrastructure. A failure therefore became a request to the vendor, followed by the answer that a fix was on the roadmap. The team could see what needed to improve without being able to make that improvement itself.

Joey replaced that arrangement as the first contact across the website chat widget, contact-sales requests and support email. Pylon manages conversations and metrics, and gives Joey access to customer context so it can remember earlier interactions. The Claude Agent SDK supplies the agent foundation: a filesystem, tool calls and the ability to write and debug code. Lawler also describes infrastructure management and adding abilities, though the talk does not explain the permissions governing those capabilities.

1:544:21
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

4:21 · section reference included

Local files support both quick retrieval and deeper search

Joey’s knowledge starts with a local Markdown copy of AssemblyAI’s documentation. Updates to the documentation system also reach the files available to the agent. This makes the public documentation website unnecessary for serving an answer from the local copy: if that website goes down, Joey can still consult the documentation it already has.

Two mechanisms help Joey find information:

  • Embedding retrieval. Voyage embeddings bring relevant documents into view first, reducing the amount of searching needed for a straightforward answer.
  • Agentic file search. When those documents are insufficient, or an answer needs several resources, Joey can search its local filesystem for additional material.

The combination gives the agent a quick starting point and a way to continue investigating. Local documentation alone would provide access; retrieval helps it choose where to look.

What happens when the first retrieved documents do not answer the whole question? The diagram separates the initial retrieval from the conditional search that follows. Both routes consult the same local documentation, so a more involved question can widen the search without depending on the public site.

Selected presentation frame from We Built an AI Support Agent That Resolves 80% of Tickets — AssemblyAI at 427 secondsOpen full source frame
A slide titled “Show-the-work: the architecture” presents four numbered steps.

Deployment speed closes the gap that the vendor bot left open. The team chose Railway to avoid managing an EC2 instance and changing instance types. A bad conversation visible in Slack can lead to a pull request and a new live version in about 30 seconds. Lawler describes catching and fixing a bug while a customer conversation was still underway, with the correction helping the rest of that session. Owning the application makes a support failure something the team can act on immediately.

How it fits togetherA quick retrieval can expand into a filesystem search

Changes to the documentation system reach Joey’s local files.

Embedding retrieval supplies an initial set of documents. Joey can search further when it needs additional resources to compose the answer.

6:146:44
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:14 · section reference included

The unresolved tickets become the next capabilities

In the first week, AssemblyAI’s reported end-to-end resolution rate rose from 10% to 80%, with about $700 per month in model usage and infrastructure costs. Lawler defines the scope explicitly: Joey receives all inbound tickets, resolves 80% without a human and escalates the remaining 20%. These are first-week operational results; the recording does not specify the ticket count or how successful resolution was verified, and the cost figure does not include a stated engineering-labor budget.

Selected presentation frame from We Built an AI Support Agent That Resolves 80% of Tickets — AssemblyAI at 488 secondsOpen full source frame
A results slide shows 80% resolved end to end, 100% first-touch, about 20% escalated, and approximately $700 per month.

Escalation remains part of the service. Customers cannot reach a human directly without going through Joey and requesting escalation. Rate changes, data opt-outs, agreements and questions requiring an FDE or legal involvement are examples of work that can still need a person. An 80% resolution rate therefore describes how much work finishes inside the agent, while the remaining requests still have a human path.

Each recurring escalation also suggests a concrete improvement:

  • Agreement access. If a customer needs a BAA and Joey cannot provide it, giving the agent a resource link may remove the need for a person to send the same information.
  • Pricing conversations. Joey can already accept a customer’s expected number of hours, quote a rate and negotiate. This extends support into a commercial task that otherwise consumes team time.

The roadmap comes from what customers are actually trying to finish. Some gaps need better information; others need a new capability.

8:018:32
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

8:01 · section reference included

Give the existing agent a voice, then keep its knowledge current

The next change serves two purposes: let customers speak to Joey, and make AssemblyAI build with the same voice infrastructure it sells. Voice mode had been integrated during the week of the talk. The agent keeps the tools it already uses in text conversations; the new interface changes how customers communicate with it.

The Voice Agent API exposes speech-in, speech-out interaction through one WebSocket connection. Behind that connection, speech-to-text feeds an LLM, and text-to-speech produces the spoken response. The API also handles pauses, interruptions and barge-in—when the customer starts speaking while the agent is talking—and supplies voices. Lawler describes the service as real-time and low latency without giving a latency measurement. Telephone access was a planned next step, rather than a capability demonstrated here.

Where does voice processing sit relative to the support tools? The diagram shows the speech pipeline around the LLM, with the existing tools still available to the agent. That relationship explains why adding voice does not require rebuilding Joey’s documentation and support capabilities as a separate bot.

The code walkthrough returns to how those capabilities stay informed. Documentation, changelog and pricing pages are converted to local Markdown as the source pages change. The files retain their URLs, letting Joey point customers to the material behind an answer. Retrieval gives the agent information to use; preserving the source URL gives the customer a way to investigate it.

Customer-facing behavior is also shaped by a large CLAUDE.md containing guardrails and operating advice. Lawler estimates it at roughly 30,000 lines. When Joey gives a wrong answer or creates a bad experience, this instruction file is a principal place the team makes corrections for future conversations. A Dockerfile packages the application for Railway, and repository updates trigger deployment without someone manually monitoring each release.

How it fits togetherVoice surrounds the agent’s existing capabilities

Speak to Joey through voice mode.

One WebSocket carries the speech interaction. The API connects recognition, the LLM and speech synthesis, while Joey retains its text-mode tools.

9:3110:01
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

9:31 · section reference included

A medical-scribe question becomes a self-service next step

The live example tests the agreement-access problem introduced earlier. Lawler runs a local simulation so the demonstration will not add work to the actual support queue. After Joey’s greeting, he asks about building an ambient medical scribe: before testing, he needs to sign a BAA. Can Joey help?

Joey first says it will check, then returns a specific path forward: complete AssemblyAI’s standard HIPAA business associate agreement. Its answer includes two consequential conditions—a paid account with a card on file is required, and signing the BAA automatically opts the customer out of model training. Joey also says the relevant documentation is linked in the chat. The demonstration supplies guidance and prerequisites; it does not show an agreement being signed or an account being changed.

Selected presentation frame from We Built an AI Support Agent That Resolves 80% of Tickets — AssemblyAI at 794 secondsOpen full source frame
A chat panel displays Joey’s reply about completing a HIPAA business associate agreement.

The observable change is that the customer leaves with an actionable answer instead of waiting for a support engineer to send a canned response. Lawler recalls that this question required human handling when he joined the support team two years earlier. Making the agreement information available to the agent allows it to explain the next step and the conditions together, through voice, with documentation available in chat.

“Isn’t he so nice?” is Lawler’s reaction after Joey’s friendly farewell. The interaction is also a product demonstration embedded in customer support. Someone asking how to build with voice infrastructure is already experiencing the speech-based interface that infrastructure can produce. Answering the question and showing the product happen in the same conversation.

9:0112:18
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

12:18 · section reference included

Shipping the customer’s kind of product changes the advice

The ending pushes beyond support automation. Building Joey with voice made Lawler confront latency, turn-taking, barge-in and interruption handling himself. Those are the same problems customers face. Using the same API to ship an application gives an FDE practical experience to draw on when helping someone else make it work.

The recommendation is to build the kind of product customers are building before waiting for them to report blockers. A working internal application can improve the customer experience directly, as Joey does, while also teaching the team where integration becomes difficult. Lawler closes by inviting reports of strange Joey conversations so the team can keep fixing the newly shipped voice experience. “Go build” is both the customer-support strategy and the way to learn what the product asks of its users.

Selected presentation frame from We Built an AI Support Agent That Resolves 80% of Tickets — AssemblyAI at 885 secondsOpen full source frame
A slide reads “Dogfooding made me a better FDE” and highlights “Same walls” and “Real empathy.”
14:2514:55
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

14:25 · section reference included

Resources

Read the complete timestamped transcript
  1. 0:13

    Cool. All righty. Can everyone hear me okay? All, all levels coming through good? All right. Sweet. Well, uh, how's everyone doing?

  2. 0:23

    How's everyone doing? Better? Okay, there we go. Cool. Well, I hope, uh, the conference has been good for everybody. Um, 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's Matt Lawler. I'm a forward-deployed engineer at AssemblyAI, uh, mostly focused on bringing in inbound customers, um, helping win their business, um, 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?

  3. 0:54

    Okay, a couple. Cool. Well, um, still coming through okay? All right. Um, yeah, so I wanted to make sure I, I gave you guys an overview of kinda some of the go-to-market engineering stuff that we've been doing at AssemblyAI that maybe you can apply to your own FDE team, uh, or maybe you can apply to your company, um, as something that you can do as a, an easy win for your customers. Um, so for a little bit of overview of, like, AssemblyAI, 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

  4. 1:24

    starting to branch into other parts of the voice agent space. Um, so if anyone's ever had, like, a Fireflies notetaker join your meeting or something like that, you've also-- you've already seen a transcript from AssemblyAI. 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 AssemblyAI's models. Um, and for anyone

  5. 1:54

    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 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, a new support bot for our team.

  6. 2:23

    Because at least until, like, two days ago, I was the only, uh, onboarding engineer at AssemblyAI, and so you can imagine, as much as I'd wanna talk to a thousand new signups every single day, it'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 wanna get deployed with our end customers. We wanna understand their use case. We wanna make sure that we are building exactly what they need. Um, so we, we

  7. 2:53

    frequently commit code directly to their repositories. We usually meet with them several times a, 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 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 FDE. Um, and we're responsible for winning their business, um, and building that trust with them.

  8. 3:21

    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 ultimately, this doesn't really scale super well. Um, we wanna make sure that we're freeing ourselves up to be leading h- uh, human-led deals as much as possible, but we can't do that with every deal. Not every customer win can be, like, hand-built by us. Um, and we can't just continue to hire more and more FDEs if we're gonna try and serve more and more customers.

  9. 3:51

    Um, so ultimately, like, for anyone who's an FDE in here, if you're looking to become an FDE, if you already have an FDE team at your company, I would encourage you to take that knowledge that you have as an FDE and try to automate yourself out of a job. I think that should be your role every single day. If you wanna serve your customers better, if you wanna work with them more, um, and if you wanna 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

  10. 4:21

    a, 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 wanna talk to fewer people. I wanna 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 it at the docs. It'll answer all the docs questions for us. It's gonna be great. We'll never have to answer a simple question from customers again." And it only resolved about ten percent 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 answered by a bot. But then our

  11. 4:50

    team still had to field nine hundred tickets a day. So it wasn't exactly very scalable. Um, so ten percent, ten percent, 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 access to the RAG infrastructure. So any time we needed to change something, we'd go to this vendor, and they'd say, "Well, it's on the roadmap." 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

  12. 5:21

    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 gonna meet Joey instead of a human. Um, he's the first line of defense now for every single conversation that happens inbound at Assembly, and he's built to be the most infinitely scalable FDE 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

  13. 5:50

    remember who you are. Um, and he's built on top of the Claude 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 FDE and less like just a standard chatbot that you'd be talking with, you know, on, on most major sites nowadays.

  14. 6:14

    So, um, if you wanna know a little bit of, like, how to build your own Joey, um, the architecture kinda 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 any time that we push an update to our documentation system, he's able to get all of those files, and he has them locally in his file system.

  15. 6:44

    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 lotta 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 multiple resources to create a response, he can agentically search the file system that he lives on so that

  16. 7:14

    he can go and find those resources for you. Um, so he can kinda 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 wanna deal with infrastructure. We didn't wanna spin up an EC2. We didn't wanna have to change instance types, so we deployed it all on Railway. Um, 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 able to iterate really, really quickly. Um, we've actually had times where we've actually monitored a live

  17. 7:44

    conversation, caught a bug, deployed a fix, and then it's been approved 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.

  18. 8:01

    Um, and so the results were pretty remarkable from us building this, and it's another reason why I want... and wanted to encourage everyone who's here to try and build your own Joey. So we went from 10% to 80% end-to-end resolution rate in 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 e- 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,

  19. 8:32

    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 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 FDE 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

  20. 9:01

    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 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

  21. 9:31

    test out by building Joey was we wanted to dog food our own product too. We didn't wanna just, like, build something that deflects more stuff from our customers. We didn't wanna build something that just, um, is kinda this general support bot that anyone can build. We work in voice, and our 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, we integrated this into Joey this week, so now if you go onto our site, you can switch

  22. 10:01

    to voice mode, and you can talk to Joey using just your voice. Um, 'cause I ultimately think for any FDE 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 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 speech-to-text model, an LLM, and text-to-speech, all optimized for voice. It's real-time and low latency.

  23. 10:31

    It handles all the pauses, interruption handling, barge in, all of that kinda stuff for you. Um, 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 are a human. Um, and hopefully later this week we can hook him up to a phone number, so now we'll have an AssemblyAI phone number so you can get real-time support from Joey whenever you need it.

  24. 10:54

    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 changelog, our pricing. All of these major, uh, pages from our website get converted to Markdown and get given to Joey. Um, so he

  25. 11:24

    sees all of these in Markdown format, and he's able to see what the URL is so he can cite his sources to the customer in case they wanna 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 guardrails 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 gave a wrong answer. We ship an update to this CLAUDE.md, and now for every conversation that he has going forward, he's able to be better.

  26. 11:54

    Um, and it's all contained as a Dockerfile, um, and so it's really easy to go and just containerize and deploy him on Railway. Um, and so again, every time we, 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

  27. 12:18

    So I'm gonna simulate this locally 'cause I, I know probably many of you are gonna test Joey after this, and I don't wanna 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 wanna have a typical question. You might talk to him via text, but let's go ahead and talk to him with voice.

  28. 12:37

    Hi, this is Joey at AssemblyAI. How can I help you today?

  29. 12:41

    Hey, Joey. Uh, I'm looking to build an ambient medical scribe with AssemblyAI, but before I can test, I need to sign a BAA. Is that something that you can do?

  30. 12:51

    One sec. Let me check that for you.

  31. 13:06

    Yes. You can execute the BAA yourself right away. Just complete our standard HIPAA 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 linked in the chat.

  32. 13:23

    Cool. Thanks, Joey. Well, I gotta, I gotta get back to my demo. Uh, I'd love to chat more, but uh, thanks for all the help.

  33. 13:32

    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.

  34. 13:39

    Isn't he so nice? I enjoy talking to Joey. Um, I think our customers will enjoy talking to Joey. Um, 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 that if you reached out in, in chat and a, 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 twenty-four/seven for these basic questions. Um, and you can do

  35. 14:09

    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 where if you're talking to Joey 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.

  36. 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 dogfooding 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, or barging or interruption handling.

  37. 14:55

    Um, and I think I have a lot better empathy of how to, like, work with customers that you wanna 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.

  38. 15:10

    So go build. Go build something. Go build whether it's a, an, your own Joey. Go build whether it's a, a voice agent, especially if it's a voice agent, build it on AssemblyAI. 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 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 wanna check him out at the booth

  39. 15:40

    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. Uh, but overall, really excited to, uh, be here at the conference and talk to more people about voice agents. So thanks for, uh, coming and listening to this talk.