WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=42Bz0TUfeOQ

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/42Bz0TUfeOQ.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:12.360 --> 00:00:15.400
Folks, thanks for coming in out.

s3
00:00:15.400 --> 00:00:18.760
I know it's lunch time, so I know a lot of you folks are trying to eat as well.

s4
00:00:18.760 --> 00:00:22.880
Appreciate you making the time and for everyone listening online, thanks for tuning in as well.

s5
00:00:22.880 --> 00:00:24.320
Uh my name's Fuad.

s6
00:00:24.320 --> 00:00:26.840
I'm a product manager here at Arize.

s7
00:00:26.840 --> 00:00:33.600
Uh I've been leading up kind of the experimentation side of the house and one thing that I've been really interested in is voice agents.

s8
00:00:33.600 --> 00:00:36.520
Uh quick show of hands here, maybe online too.

s9
00:00:36.520 --> 00:00:39.600
Who here is building a voice agent?

s10
00:00:39.600 --> 00:00:40.200
Anyone?

s11
00:00:40.200 --> 00:00:42.000
Got Okay, we got a couple.

s12
00:00:42.000 --> 00:00:43.160
Uh I think it's a really cool space.

s13
00:00:43.160 --> 00:00:52.840
I'll be talking a little bit about voice traces, session views of voices, voice evals, and some of the stuff that's new in Arize.

s14
00:00:52.840 --> 00:00:55.840
But I do want to kind of mention this isn't a product pitch.

s15
00:00:55.840 --> 00:01:01.560
This is, you know, really on why voice agents are invisible and how to see them.

s16
00:01:01.560 --> 00:01:10.920
You can use Arize to do that, you can use another platform, but what I want you guys to take away from this is some of the failure modes and how you can actually start to see that.

s17
00:01:10.920 --> 00:01:15.280
So, we all know voice agents are growing really, really fast.

s18
00:01:15.280 --> 00:01:18.880
Have a few tweets up uh kind of proving this.

s19
00:01:18.880 --> 00:01:20.600
GPT real-time just dropped.

s20
00:01:20.600 --> 00:01:22.520
That was literally May 7th.

s21
00:01:22.520 --> 00:01:27.600
Uh I have a screenshot from a tweet an hour ago from the LiveChat CEO talking about some of this.

s22
00:01:27.600 --> 00:01:34.480
Uh and Vercel on June 29th, which is only a couple days ago, um on voice agents in Vercel.

s23
00:01:34.480 --> 00:01:46.880
So, as you can tell, uh this space is exploding fast and that is going to start to matter because as the space grows really fast, it is also one of the hardest to debug categories.

s24
00:01:46.880 --> 00:01:48.840
So, first off, it's exploding.

s25
00:01:48.840 --> 00:01:51.040
Second off, it's pretty fragile.

s26
00:01:51.040 --> 00:01:54.200
There's a lot of failure modes you can't really see.

s27
00:01:54.200 --> 00:02:00.760
Um and uh things like latency, turn-taking, and transcription drift become really, really important.

s28
00:02:00.760 --> 00:02:01.760
Uh, and the log lies.

s29
00:02:01.760 --> 00:02:06.280
If you're just looking at transcripts, I'll play a little audio file for you guys in a second.

s30
00:02:06.280 --> 00:02:10.479
Uh, it doesn't really capture what's actually going on under the hood.

s31
00:02:10.479 --> 00:02:19.280
And just to give you guys some ideas of use cases, um, there's a lot of them from customer support, I think, which are the more boring ones, down through drive-thru ordering.

s32
00:02:19.280 --> 00:02:23.200
If you've been to White Castle, they have a a bot called Linda now.

s33
00:02:23.200 --> 00:02:26.640
Uh, Bojangles has uh, Bo Linda as well.

s34
00:02:26.640 --> 00:02:30.120
There's McDonald's is doing a lot of these as well, which I think is pretty cool.

s35
00:02:30.120 --> 00:02:35.959
And personally, I'd be pretty pissed off if I was at McDonald's at 2:00 a.m. and I got 600 cheeseburgers.

s36
00:02:35.959 --> 00:02:41.360
So, I think I'll show you a little bit about the failure modes and why it actually matters.

s37
00:02:41.360 --> 00:02:48.120
So, uh, this is an example where the transcript looks fine, but the call wasn't.

s38
00:02:48.120 --> 00:02:53.320
And if you read the text logs, you know, user says, "I need a refund for order 14."

s39
00:02:53.320 --> 00:02:54.680
Agent says, "Sure.

s40
00:02:54.680 --> 00:02:56.600
Started a refund for order 40."

s41
00:02:56.600 --> 00:02:58.600
User says, "No, 14."

s42
00:02:58.600 --> 00:03:00.760
And it looks like the agent corrected itself.

s43
00:03:00.760 --> 00:03:04.480
But, this wasn't actually the case, and I'm going to I'm going to play the call.

s44
00:03:04.480 --> 00:03:05.280
It's AI-generated.

s45
00:03:05.280 --> 00:03:06.440
Let's see if it works.

s46
00:03:06.440 --> 00:03:09.640
I need a refund for order 14.

s47
00:03:10.920 --> 00:03:11.640
Sure.

s48
00:03:11.640 --> 00:03:13.959
I've started a refund for order 40.

s49
00:03:13.959 --> 00:03:15.360
No, 14.

s50
00:03:15.360 --> 00:03:17.800
Your refund is confirmed.

s51
00:03:17.800 --> 00:03:28.840
So, if you notice in the transcript, if you could hear the audio there, uh, it wasn't, you know, the the the confirm- confirmation on the on the 40 wasn't actually done by the agent.

s52
00:03:28.840 --> 00:03:30.360
It kind of interrupted.

s53
00:03:30.360 --> 00:03:35.959
Uh, and there was a big, uh, kind of latency spike, uh, after the user asked for the initial refund.

s54
00:03:35.959 --> 00:03:43.280
Um, so, we what actually happened was that two 2.4 seconds of dead air before the agent actually responded.

s55
00:03:43.280 --> 00:03:46.120
The agent talking over the caller.

s56
00:03:46.120 --> 00:03:51.320
14 misheard, and obviously, the flat robotic tone is is not a a look, either.

s57
00:03:51.320 --> 00:03:53.360
Um, so, these are all audio specific issues.

s58
00:03:53.360 --> 00:03:58.720
If you just read this from an LM output, you would have no idea anything is going on.

s59
00:03:58.720 --> 00:04:04.080
So, what you need to do is you need to see the conversation beyond just the transcript.

s60
00:04:04.080 --> 00:04:09.240
Um, so that means the audio, the transcript, and the trace all in one place.

s61
00:04:09.240 --> 00:04:16.040
The session as a whole, so multiple turns from the user back and forth in the same in the same trace view.

s62
00:04:16.040 --> 00:04:19.600
And then metrics on those, so what was the latency like?

s63
00:04:19.600 --> 00:04:21.320
What was the time to first audio like?

s64
00:04:21.320 --> 00:04:22.520
Were there any interruptions?

s65
00:04:22.520 --> 00:04:24.400
Sentiment analysis, et cetera.

s66
00:04:24.400 --> 00:04:29.840
And these are some of the features we've just released at the beginning of this month in Arize AIX.

s67
00:04:29.840 --> 00:04:39.360
Uh, and really the point of this is the same workflows that you're running now to help your coding agents, uh, which are, you know, pretty complex processes now with harnesses,

s68
00:04:39.360 --> 00:04:47.520
evals, uh, handoffs, and subagents, tool calls, you want to start to bring some of those best practices into your voice agents as well.

s69
00:04:47.520 --> 00:04:49.600
So, first off, you got to trace it.

s70
00:04:49.600 --> 00:04:51.880
You got to see each individual span.

s71
00:04:51.880 --> 00:04:56.919
Um, you got to see the live audio and play it inline from your trace.

s72
00:04:56.919 --> 00:05:00.720
Really matters to have all this data in the same place so you can start to debug things.

s73
00:05:00.720 --> 00:05:02.320
Uh, you want to see inputs and outputs.

s74
00:05:02.320 --> 00:05:11.600
You want to see the transcript, obviously, but you also want to see, you know, specific metrics like I mentioned, like time to first token, uh, audio token cost, interruption events.

s75
00:05:11.600 --> 00:05:14.000
And then finally, you want to see linkage between these.

s76
00:05:14.000 --> 00:05:15.840
You don't want to just see these as a list.

s77
00:05:15.840 --> 00:05:20.200
You actually want to see some of the linkage between things, right?

s78
00:05:20.480 --> 00:05:33.040
So, Arize gives you that one trace view where you can actually play the audio inline, view the transcript, view latency inline, see the conversation turn between the user, uh, and the assistant,

s79
00:05:33.040 --> 00:05:35.560
uh, and see your evals inline as well.

s80
00:05:35.560 --> 00:05:39.440
And this gives you a really, really powerful tool to debug.

s81
00:05:40.280 --> 00:05:47.240
Under the hood, what this looks like is we've actually mapped, uh, the semantic conventions for audio onto open inference.

s82
00:05:47.240 --> 00:05:52.240
So, if you guys aren't familiar, Arize is first to market with open inference in 2023.

s83
00:05:52.240 --> 00:06:03.400
It is the first set of semantic conventions that is completely open source that maps kind of what is happening with GenAI to an OTel-compliant set of conventions.

s84
00:06:03.400 --> 00:06:11.480
And I say this to say it's open source, it's free, and it maps pretty much any of the major foundational models or model providers.

s85
00:06:11.480 --> 00:06:14.200
You guys can go rip this and send it to a Grafana back end.

s86
00:06:14.200 --> 00:06:15.600
Completely free to use.

s87
00:06:15.600 --> 00:06:25.800
Not pitching the product here, just explaining some of the real engineering work it takes to map things like web socket events to an easily understandable set of semantic conventions.

s88
00:06:25.800 --> 00:06:36.280
So, you can start see things like the session life cycle, the audio input, the transcript, conversation items, the output, and then the response life cycle and token counts as well.

s89
00:06:36.280 --> 00:06:38.640
And so, yeah, real engineering work went behind this.

s90
00:06:38.640 --> 00:06:40.200
It's all open source.

s91
00:06:40.200 --> 00:06:43.840
We've mapped all the foundational models for you.

s92
00:06:43.840 --> 00:06:51.440
What this allows you to do is you can now be provider agnostic and have one queryable schema.

s93
00:06:51.440 --> 00:07:04.120
So, those semantic conventions normalize sort of these disparate model providers, whether it's OpenAI, real-time, or Google with Gemini Live into a set of schema that you can query.

s94
00:07:04.120 --> 00:07:15.360
And if you've ever tried to debug at 2:00 a.m. off of a customer call, you know how important it is to be able to query across thousands, millions, even billions of traces that are coming in.

s95
00:07:15.360 --> 00:07:21.040
You know how important it is to actually get to the part that you need to see, to filter that, to sort by that.

s96
00:07:21.040 --> 00:07:23.440
All that becomes incredibly important.

s97
00:07:23.440 --> 00:07:31.280
And, you know, as new models drop, you also want to be able to swap in new providers and make sure that your systems are still functioning.

s98
00:07:31.280 --> 00:07:33.800
So, no bespoke parsing per vendor.

s99
00:07:33.800 --> 00:07:35.520
It's one auto instrumenter.

s100
00:07:35.520 --> 00:07:39.320
It captures every single thing that I just mentioned.

s101
00:07:40.720 --> 00:07:43.200
And then finally, you want to be able to replay the whole conversation.

s102
00:07:43.200 --> 00:07:54.160
So I play I played the audio for you guys in the beginning of this, but the session ID is essentially what stitches every turn into the timeline, the full call with every websocket event that's submitted

s103
00:07:54.160 --> 00:07:57.680
with some tags on whether it's the user or the assistant.

s104
00:07:57.680 --> 00:08:01.520
You can actually play the audio in the UI directly from the trace.

s105
00:08:01.520 --> 00:08:03.440
No external tooling.

s106
00:08:03.440 --> 00:08:04.720
No exports.

s107
00:08:04.720 --> 00:08:06.640
Just play it straight from the trace.

s108
00:08:06.640 --> 00:08:09.360
That allows you to see who spoke when.

s109
00:08:09.360 --> 00:08:17.120
When the agent paused, where it got cut off, where the user got cut off, what tools the agent actually went and called when it did this.

s110
00:08:17.120 --> 00:08:28.720
And so this really starts the paradigm shift, which is you're not just reading transcripts, you're listening to audio, you're really understanding the failure cases from there with the trace open right next to it.

s111
00:08:28.720 --> 00:08:34.640
And um I'll just show you kind of quick quick sneak preview of what this looks like in Arise.

s112
00:08:34.640 --> 00:08:41.840
As you can see here, this is an example of like you know an agent that can call to get a specific weather event.

s113
00:08:41.840 --> 00:08:46.680
You can actually see when the agent kicks off that tool call in line with the rest of the audio.

s114
00:08:46.680 --> 00:08:50.760
And this allows you to debug failures of that tool call while you're looking at the session audio.

s115
00:08:50.760 --> 00:09:00.360
So you're no longer looking at disparate events from distant systems, but you're actually looking at the entire trace tree for everything that happened in that session.

s116
00:09:00.480 --> 00:09:04.480
So that real session, few issues that we saw, right?

s117
00:09:04.480 --> 00:09:08.600
Turn one, "Hi, need help with the order, a refund for order 14."

s118
00:09:08.600 --> 00:09:15.640
We saw you know kind of that time to first audio of 2.4 seconds of dead air, which really impacts the user experience.

s119
00:09:15.640 --> 00:09:25.120
We saw in turn three that the agent actually spoke over the caller's interaction, which is not a good look for any assistant, especially one that's trying to be helpful.

s120
00:09:25.120 --> 00:09:33.960
And then ultimately if you look at the tool call, you'll be able to also understand that the refund was processed for order 40 and not 14.

s121
00:09:33.960 --> 00:09:41.440
Um which is a huge huge mistake and actually seeing that live in the tool call is really really important.

s122
00:09:41.440 --> 00:09:44.840
And every single one of these things would be invisible in a text log.

s123
00:09:44.840 --> 00:09:53.640
But with the session view you can actually scrub the audio and find those failure surfaces within the tools, within what the agent is doing as well.

s124
00:09:53.640 --> 00:09:58.360
The next thing I want to talk about real quick is evals that are specific to audio.

s125
00:09:58.360 --> 00:10:00.400
So I kind of mentioned a few of them.

s126
00:10:00.400 --> 00:10:03.600
I think tonality and sentiment analysis is really important.

s127
00:10:03.600 --> 00:10:08.800
You want to be able to classify user emotion based on the actual audio.

s128
00:10:08.800 --> 00:10:10.360
Transcript can't do this for you.

s129
00:10:10.360 --> 00:10:18.680
It's very very easy to look at a transcript and see that it it, you know, looks fine, but tonality really matters.

s130
00:10:18.680 --> 00:10:21.640
Positive, neutral, negative, not just a guess.

s131
00:10:21.640 --> 00:10:25.760
Latency is really really important in audio and it's important in a few use cases.

s132
00:10:25.760 --> 00:10:26.720
Models are getting better.

s133
00:10:26.720 --> 00:10:34.920
There's, you know, jet bar architectures, etc. But time to first audio SLAs are still really important for customer service use cases.

s134
00:10:34.920 --> 00:10:38.160
And you want to be able to flag things that are breaking that.

s135
00:10:38.160 --> 00:10:45.480
You also want to flag things like I mentioned like interruptions, inaccuracy, transcription drift, and the task success.

s136
00:10:45.480 --> 00:10:53.200
Um And you want to be able to run these evals directly against the audio with evals that are based on audio models.

s137
00:10:53.200 --> 00:10:56.680
So, you know, LLM as a judge evals on a transcript are only so good.

s138
00:10:56.680 --> 00:10:59.120
But actually evaling the underlying audio is really important.

s139
00:10:59.120 --> 00:11:09.280
And so, um we have kind of the tooling available in Arise to be able to do that and we're supporting all the major audio platforms as well as they come out with new models.

s140
00:11:09.280 --> 00:11:12.160
So again, evals specific to audio really matter.

s141
00:11:12.160 --> 00:11:15.200
They're not just transcription based evals.

s142
00:11:15.200 --> 00:11:23.560
And as you start to scale up your LLM as a judge evals or even move to agent as a judge that are doing like complex tasks like, for example,

s143
00:11:23.560 --> 00:11:29.839
doing our back checks to making sure the agent actually access the system it was supposed to have access to.

s144
00:11:29.839 --> 00:11:39.280
Being able to run these agent as a judge workflows in Arise, starts to become really important and we're kind of seeing the industry move away from, you know, just an LM as a judge

s145
00:11:39.280 --> 00:11:50.400
analyzing a transcript or even analyzing audio, but actually accessing tools, accessing third-party systems, and hydrating some of that evaluation information inside of it.

s146
00:11:50.400 --> 00:11:54.640
So, really easy to get started with evals in Arise through skills.

s147
00:11:54.640 --> 00:12:05.600
It is literally as simple as, "Hey Claude, create an audio eval for me for sentiment analysis using GPT audio and catch frustrated user tone on those audio spans."

s148
00:12:05.600 --> 00:12:08.200
And Arise will kind of take care of all the rest for you.

s149
00:12:08.200 --> 00:12:22.520
The CLI under the hood is able to query spans, do some trace analysis, filter for the spans that are audio specific, actually create that eval, deploy it, and put it against traces and spans in your actual system.

s150
00:12:22.520 --> 00:12:24.200
And this is part of why Arise exists.

s151
00:12:24.200 --> 00:12:35.640
Yes, of course, you can do this yourself, but when you're trying to query, you know, billions of spans with sub-second query latency, it becomes really hard and also deploying these live evals

s152
00:12:35.640 --> 00:12:36.800
as they come in.

s153
00:12:36.800 --> 00:12:42.240
So, you're scoring them while users are actually interacting with your platform is really important.

s154
00:12:42.240 --> 00:12:52.160
And then the final thing I'll mention is you also want these evals on the spans themselves because then you start to be able to do really complex querying and filtering across

s155
00:12:52.160 --> 00:12:53.080
your data.

s156
00:12:53.080 --> 00:12:56.080
So, you're not just looking at a failure and looking up in an external system.

s157
00:12:56.080 --> 00:13:01.000
You actually have the eval scores in line with the exact audio that you're looking at.

s158
00:13:01.000 --> 00:13:04.440
And that's why some of this is really powerful in Arise.

s159
00:13:04.440 --> 00:13:15.080
Being able to see those eval outputs directly on the spans that are relevant helps you kind of get a full understanding of what is going wrong with the user interaction.

s160
00:13:15.080 --> 00:13:16.839
And then you can kick off workflows from that.

s161
00:13:16.839 --> 00:13:29.520
So, evals and monitors attached to those evals can kick off investigation agents that automatically start to dive into, you know, what tool calls and misrepresenting, Um, where is my agent failing?

s162
00:13:29.520 --> 00:13:34.840
Is it capturing, you know, maybe a product surface area that I didn't code it for?

s163
00:13:34.840 --> 00:13:37.680
Is there a new edge case I need to code for in my agent?

s164
00:13:37.680 --> 00:13:39.640
Maybe I need to expose a new tool.

s165
00:13:39.640 --> 00:13:47.280
All those become um, possible once you have the results directly on the spans.

s166
00:13:47.280 --> 00:13:51.400
And so, I'll I'll just kind of flag and and end with this thought.

s167
00:13:51.400 --> 00:13:57.520
The same loop that you're doing to improve some of these tools like coding agents, we now need to do for voice.

s168
00:13:57.520 --> 00:14:01.880
And the loop really follows observe, evaluate, and improve.

s169
00:14:01.880 --> 00:14:11.680
And then from that loop, you can start to get some really really cool continuous improvement loops within the Arize platform or within another platform if you choose to use it as well.

s170
00:14:11.680 --> 00:14:20.680
Um, and the idea is once you observe and you have the data available to you, then you evaluate and you have the scores in line with your observations.

s171
00:14:20.680 --> 00:14:28.800
Then you can start to kick off fixes, whether they're fixes that you make or whether they're fixes that an agent is automatically making on behalf of you.

s172
00:14:28.800 --> 00:14:31.680
And then you can start to verify and validate those fixes.

s173
00:14:31.680 --> 00:14:34.600
So, we just released agent experiments as well in Arize.

s174
00:14:34.600 --> 00:14:38.800
Agent experiments, you could think of it kind of like Postman with tracing.

s175
00:14:38.800 --> 00:14:49.760
So, imagine a world where you have audio streaming in from your users, it's automatically traced, you have live evaluations in the platform that are automatically scoring those interactions.

s176
00:14:49.760 --> 00:15:00.839
And then you have SRE agents, so not an actual engineer that you hire, but an SRE agent that's looking through the traces, understanding the failure modes, hypothesizing a fix,

s177
00:15:00.839 --> 00:15:11.920
and then actually standing up a fix for you in dev, replaying those failed traces for you against that fixed endpoint, tracing that to validate that the latency actually decreases.

s178
00:15:11.920 --> 00:15:16.880
And you wake up in the morning, you look at a PR, the PR has a description of a problem.

s179
00:15:16.880 --> 00:15:19.760
Hey, I found out why the latency was high.

s180
00:15:19.760 --> 00:15:25.640
Turns out we were not truncating our tool results, and so we were passing in way too much information to the agent.

s181
00:15:25.640 --> 00:15:27.240
Context got overloaded.

s182
00:15:27.240 --> 00:15:29.400
I introduced the truncation algorithm.

s183
00:15:29.400 --> 00:15:30.240
I shipped it.

s184
00:15:30.240 --> 00:15:32.640
I actually stood it up in dev.

s185
00:15:32.640 --> 00:15:34.960
I tested against the traces that failed.

s186
00:15:34.960 --> 00:15:36.560
Here's the report card.

s187
00:15:36.560 --> 00:15:38.360
Here's how latency decreased.

s188
00:15:38.360 --> 00:15:43.400
And you wake up in the morning and all of this is ready for you, and you just click approve or deny on the PR.

s189
00:15:43.400 --> 00:15:52.720
That is the future that I think we want to see at Arize, where self-healing software and continuous improvement are realities for everyone who's building agents.

s190
00:15:52.720 --> 00:15:57.040
And I think making that possible for voice is really, really important.

s191
00:15:57.040 --> 00:15:59.200
So, start seeing your agents.

s192
00:15:59.200 --> 00:16:01.520
Add the Open Inference Instrumenter.

s193
00:16:01.520 --> 00:16:03.920
Open source, free to use, OTEL compliant.

s194
00:16:03.920 --> 00:16:05.760
You can send it to any back end.

s195
00:16:05.760 --> 00:16:09.840
Um so, use Arize, don't use Arize, start tracing your audio.

s196
00:16:09.840 --> 00:16:14.160
The second part of this is actually starting to do that analysis, and we would recommend Arize to do that.

s197
00:16:14.160 --> 00:16:15.680
Sign up for a free account.

s198
00:16:15.680 --> 00:16:21.840
Uh I'll have a code up at the end of my presentation for you guys to sign up for a a free year of pro.

s199
00:16:21.840 --> 00:16:24.120
Um but start checking time to first audio.

s200
00:16:24.120 --> 00:16:25.880
Start checking your interruptions.

s201
00:16:25.880 --> 00:16:32.320
And start evaluating um how these interactions are actually going and whether they're accomplishing your use cases.

s202
00:16:32.320 --> 00:16:38.200
Whether it's a tone or latency eval, um try using the Arize skills to actually create that eval.

s203
00:16:38.200 --> 00:16:40.960
Uh we have some docs set up for you if you want to follow along.

s204
00:16:40.960 --> 00:16:43.280
Bunch of examples and cookbooks ready.

s205
00:16:43.280 --> 00:16:47.120
Uh and bring voice into the same rigor as the rest of your stack.

s206
00:16:47.120 --> 00:16:50.360
You wouldn't be okay with this happening at the coding agent level.

s207
00:16:50.360 --> 00:16:55.440
You wouldn't be okay with it happening uh for an agent that's able to execute stocks on Robinhood.

s208
00:16:55.440 --> 00:17:01.839
You shouldn't be okay with it, uh though the stakes might seem a little lower, for a McDonald's agent that's ordering your cheeseburger, either.

s209
00:17:01.839 --> 00:17:04.720
Um and so I'll end with that.

s210
00:17:04.720 --> 00:17:06.640
Please, please keep building.

s211
00:17:06.640 --> 00:17:09.280
Please connect with me also on Twitter.

s212
00:17:09.280 --> 00:17:12.839
I still call it Twitter, not X. Uh on Twitter or LinkedIn.

s213
00:17:12.839 --> 00:17:20.319
Would love to kind of talk and hear about some of the use cases you guys are building towards so we can add more echos to our library and make sure this is useful for you.

s214
00:17:20.319 --> 00:17:25.640
And if you found this talk useful and you want to start investigating your voice agents, there is a free code up on the screen.

s215
00:17:25.640 --> 00:17:28.560
It gives you a year of Voice Pro for free.

s216
00:17:28.560 --> 00:17:35.480
It's a i w f 2026 and you can get started and start tracing your voice agents.

s217
00:17:35.480 --> 00:17:36.720
So thank you very much.

s218
00:17:36.720 --> 00:17:37.600
My name is Ali.

s219
00:17:37.600 --> 00:17:42.160
I'll be available for questions for a couple minutes after but really appreciate you guys listening.

s220
00:17:42.160 --> 00:17:44.160
Cheers.