Look in this journey.
Some days are more challenging days and some days are more satisfying days.
Today.
Today is both.
Today is a bit of both.
I've got something challenging.
I've got something satisfying.
Today we are integrating 11 labs with Nan.
We're putting them both together and it's going to be fun.
Okay.
So obviously we're going to be using Nan and 11 labs together in order to have voice agents that have
workflows in Nan.
Now there are actually two different ways to do this, two completely different integration patterns.
And we're going to do both.
Uh, one of them is definitely the better.
And I will explain which and why, but we're still going to do both because it's good practice and it's
going to help you really understand what's going on.
So the first of them is where N is the boss, Nan is running the show.
It is orchestrating everything.
The end to end workflow is described in Nan with all the different steps.
And one of those steps is calling out to the 11 labs API to turn text into speech, to text to speech.
That's when we want the thing to talk to us.
And we'll use 11 labs for generating the audio.
And a different step, probably earlier in the process is start speech to text.
This is when we take some audio and turn it into text, which would go into an LLM.
And so these are steps on the workflow which is where Nam would call that to 11 labs.
Hopefully that makes complete sense to you that that's how it can come together.
So what's the other way.
So the other way, as you probably guessed, is where 11 labs is running the show.
It's the boss.
The orchestration is happening driven by 11 labs first and foremost.
You basically build a voice agent in 11 labs, much as we've already done.
And you give that voice agent a tool.
And we we didn't actually use tools, but I showed it to you, and you use that tool to make a call
into nen to carry out some sub workflow.
And basically you have your sort of business logic, your business workflow, be part of an A10.
So, so in this way, the two of them kind of collaborating together.
But 11 labs is the overall end to end process.
It sort of it sort of owns the show.
So what are the reasons for doing it each way?
Well, the benefit of orchestration on the left is obviously that it is simple.
It's clear you get all of your workflow in one place, you've got one canvas, and on it you see everything
that's going on and that's great.
It also gives you a more switchable API.
You've got you've got a link to 11 labs, and you could swap that out for any other API that offers
text to speech and speech to text.
You just have to replace those, those two APIs and bam, you're onto a different vendor.
And that's super convenient.
So those are the benefits of an orchestration.
And with that, you're probably wondering what could possibly be the benefits of 11 labs orchestration
because it's clearly more complex.
It's not really.
It's kind of both orchestration.
You're you're first and foremost starting in 11 labs, but then you've got some workflow and then it
ends.
So it just sounds more complicated all in all.
So why would you pick this ever?
Well, look, here's the thing.
Latency.
It's about latency.
If you're using Nand to orchestrate, then you first have to collect the audio.
And then you have to call out to get that audio turned into text.
If you're using 11 labs, it is a voice agent platform.
And that means it's all built to be real time from the get go.
As you're speaking, it's automatically converting that into text.
That's not it's not a linear process.
And it's designed to be great at this voice agent interaction.
That's what it does.
And from that perspective, it's great to be using it as much as we can.
And in many ways, using them together like this gives us the ability to have the best of both.
We can use all of the features and functions that you get in 11 labs when it comes to voices, and then
also take advantage of ten for the orchestration.
So yes, it's more complex, but it does mean you can use both platforms to the max.
And as part of that, it's worth mentioning that 11 labs has some advanced functions, like like it
has features to to for example, use um, a telephone like have it connect to to a phone and be able
to speak on the phone to one of your voice agents.
And this way you get that.
Otherwise you're you're using n810 to collect the audio, and you don't get the advantage of all of
these pro features in 11 labs.
So there's some pretty big benefits on the right hand side as well.
So which do you think I'm going to recommend as being the right way?
It's definitely the right hand side.
I you know, I like to say simple is always better.
That's one of my mantras.
I'm always trying to push you to be to take things, make things simpler, not more complex.
But this is a clear case where you get you get a lot for the complexity and it's worth it.
Latency is everything when it comes to voice agents, having to wait is agonizing if you're talking
to to an agent.
And so, yes, you need the voice agent from 11 labs.
You need to use the right hand pattern.
We're going to do both so we can experiment with both.
Often, often people start with the left hand pattern because it's the more obvious.
It's the sort of go to uh, but very quickly we'll discover the difference between them and why it is
that the right one is much more compelling.
But but as I say, we'll try both.
Okay, now, don't hate me.
But before we go and build all of this and we've got some juicy building to do today, but before we
do need to do a little bit of refresher, a couple of things, API stuff, but, uh, it's good stuff.
It's good to get through this.
So first of all, just to quickly remind you about this thing webhook that we encountered a couple of
days ago, this is this idea that you could have a node and it can be calling out to an endpoint, making
like a web call to some URL, some web address.
And that's that's one way you can think about making an API request to get information.
And and this is it's like request response.
You're hitting an HTTP route as it's called.
Like a, like a like a web address.
Uh, and then there's this other idea that someone else could call you.
You could make a web endpoint available and say, hey, if someone if someone calls this web endpoint,
which is like saying, if someone asks me if I can give them a web page at this address, I'm going
to treat that like that's them telling me an event.
They're telling me something's happened so I can say, hey, if you if you hit me on this web link,
I'm going to know that you want to give me information.
You want to tell me something?
You want to tell me that?
That a message has arrived.
An email has arrived, a slack message has arrived.
And when you do it that way, it's described as as having a webhook.
And the webhook is being called by the external system, like slack in this case.
So that was the the idea behind a webhook that we met before.
Okay.
And now now I'm gonna before with next.
After this we're going to go and build stuff.
But I want to give you some terminology, some, some technical stuff, which I guess what the usual
story for some of you, this is like yeah, yeah, yeah, come on I know all this, but for some of
you, this is going to be hairy.
And I want to just say you don't need to remember anything I'm about to say.
If it doesn't mean anything to you, just just just listen.
Like, get the gist.
I'm going to repeat this one a few times, you know, so you let it sink in over time.
But just to get you more comfortable with the terminology, let's dig in.
So I've used the expression calling an API a fair bit.
And I'm talking about calling a web API the most standard kind of APIs.
And yeah, the way it's achieved is you're making a web request, you're using this, this protocol,
this, this standard called HTTP, which is basically the way that web pages are exchanged.
So you're using this HTTP standard to make a request over the internet to a web address.
And that's what we're calling calling an API.
And the URL that you use, the web address that you're going to request or hit is called an endpoint.
As you know, you've heard this.
And so the language that you might you might hear if you're saying it properly is I'm calling an API
by making an HTTP request to an endpoint, calling an API by making an HTTP request to an endpoint.
And that should just connect with you.
You should be like, okay, I hear that language.
I know what it means.
If you're on the receiving end of this, if you want someone to call a URL to tell you something, to
give you some information, like an event has happened, I need to trigger something.
Then that endpoint you would describe as a webhook, that's that's what it means.
So you might say, hey, I've set up a webhook make you can make an HTTP request to that webhook to
tell me about X like you've, you've received an email or something like that or the other way I could
say, hey, can you please tell me your webhook and I will call your webhook to to inform you that an
event has happened that you need to know about.
So that's the kind of language you might use the terminology to talk about webhooks.
And then just to give you one more detail, there are in fact different types of these HTTP calls,
different flavors of them.
It's actually known as the method.
Different methods of an HTTP call, sometimes called the verb, are the most common are get and post.
So you sometimes hear people say an http get and an HTTP post.
Two different types of HTTP request and usually a get.
An HTTP get is used when you're trying to retrieve information.
You want to find something you want to get information about it, you're doing an HTTP get, and the
information will come back in the form of JSON as the response to your HTTP get.
And an HTTP post is usually used to send information to the third party, and you send that information
in the form of JSON.
So that is an http get and an http post.
And I say this because we will be selecting get and post in a couple of places.
So this is your first time of hearing about it.
Or maybe you know this stuff back to front.
Anyways that that is the terminology.
We're done with it.
It's time to do some building.