Voice was the unlock to many of the operations that are really needed to move the world if we talk about supply chain. >> Humans are great, of course,
but they have a lot of limitations. Like they cannot be in two places [music] at the same time. They drop a lot of freight. They're not very diligent.
If we were to create a voice AI that could pick up the phone and sell these loads and track
[music] these shipments, would you buy it? And it's like, "Dude, of course. Like this is a no-brainer." Product market fit made sense from the
beginning. It was more so like, "Can we prove ourselves we can build this technology?" >> Today we actually serve nine of the top 10 freight brokers
in the US, seven of the top 10 tracking companies, two of that are just ocean carriers, those big boats we
see in the bay. With DHL, we've deployed over 40 agents across 80 countries. Agents that are sharing context across regions and functions. [music] >>
The real economic leverage and value for the enterprise is really list at the top of the pyramid, but you cannot start at the top. The only way to get
to the top and make those decisions is by actually capturing all the context underneath. [music]
And that's where everyone is getting stuck at. >> Olivia and I are here with the two incredibly talented founders of Happy Robot, Pablo and Luis.
Welcome, guys. >> Thank you, guys. Super excited. >> Very excited to have you. We're overdue to have this conversation. Well, look, we're we're here
to kind of talk about the company and the incredible journey that you've been on. You know, I know um
when we first met you, there'd been a lot of buzz amongst YC founders and other folks about how you guys were sort of at the edge of the technology
and then really getting a lot of pull from a go-to-market perspective. So, maybe take us back in time to, you know, the little office that had four or
five people on 20th Street and what the origins of the company and the product were. >> 100%. So,
Luis and I met on our second day of college just to set the scene. Uh ever since we've been building stuff together. Our other co-founder, Favi, he
happens to be my brother, so I've known him for a little while. Uh we always wanted to build something together, right? So, when we got into YC, we
were looking for complex problems we could solve um Keep in mind that Luis and I had been literally
building submarines for robotics competitions in under like to find underwater mannequins to find mannequins underwater. That that is the sort of
problems we were looking for. So, when we decided on solving for that complexity, we looked at what Javi was doing as CFO of the largest olive oil
distributor in the world. He was literally moving bottles of olive oil or tons of olive oil across the
ocean. And that was that complexity that drew us into logistics and supply chain. He literally had to hire insurance to call drivers to see where they
were to see where the shipment was because Walmart was asking him like, "Where the hell is my shipment of olive oil?" So, that was the sort of
problems that we wanted to tackle. And maybe you can talk about why we actually started with voice there.
You know, I guess we took it from a very tech-driven approach. Like, really the limiting factor back then was you know, having an agent that could
speak on the phone realistically. Like, we were in conferences, Javi was like traveling all around like asking people, "Hey, if we were to create a
voice agent that could pick up the phone and sell these loads and track these shipments, would you
buy?" And he's like, "Dude, of course. Like, this is a no-brainer. I just don't think you can do it." So, it was more so like the idea market fit or
like product market fit made sense from the beginning. It was more so like, "Can we prove ourselves we can build this technology?" And you know, LLMs
were picking up. We're talking about like late 2023 probably. Like, LLMs were like decent enough. Um
11 Labs was picking up with the with the text-to-speech and everything was kind of working together, but we had to build something that could actually
like connect all the dots and actually make something work, no? So, we that kind of shaped our company where we really had technology innovation as
the as the core of our company and always pushing this frontier, no? And solving problems like
firsthand. So, that's how we got started in the voice space. >> Amazing. One of my favorite memories of working with you guys is actually when we
first met outside a very crowded coffee shop and you called one of the live voice agents and it was seamless and it did an incredible job in a very
non-ideal environment. I feel like a lot of people might know Happy Robot from your amazing demo videos of
the voice agent, and that's definitely not all the product is, but it's an important part of it. So, maybe walk us through like why voice to start,
and then what voice has maybe unlocked for you more broadly? >> Yeah. What Luis was saying is very important. Voice was the unlock to many of the
operations that are really needed to move the world if we talk about supply chain. Uh so, when we were
going to these conferences and people were like, "No, you're going to build these things that talk on the phone." Um negotiating rates on shipments
was actually a a big one. Um so, we actually fine-tuned LLMs back then. Like, we fine-tuned Mistral and Llama to actually make those voice agents
faster because otherwise, using some GPT-4 at the time was like extremely slow, and GPT-3.5 at the time
was like terrible at reasoning and actually negotiating. So, we had to do a lot of tricks uh behind the scenes, build our own agent infrastructure, if
you will, but also build our own voice agent capabilities so that we could innovate faster than competition. And that actually gave us a really good
edge in logistics and transportation in the early beginnings. So, we started working with these
freight brokers. Uh then we expanded to these freight forwarders. Then ocean carriers, then trucking companies. And today, we actually serve many of
the largest uh companies in the space of supply chain we were discussing before, now. Um nine of the top 10 freight brokers in the US. Um seven of the
top 10 um uh trucking companies. Like, some of the like the largest fleets that actually move our
goods everywhere in the US, which is crazy. Two of the largest ocean carriers, those big boats we see in the bay. That is sort of customers that we
needed to build for, and where voice was the unlock for many of the operations. >> So, it sounds like it wasn't just voice. It was also voice plus
negotiation. So perhaps, you know, tracking trace which is customer support and sales which is sort of
this negotiation is where we started. And I think that forced us to build a deeper set of technology than we otherwise would have built. Maybe Luis,
take us on the technology journey a little bit. >> Yeah. Um so before I tackle that, I guess one of the things that we had very clear from the
beginning when you're working on the frontier of technology is really what you have to reinvent versus what
already exists, you know? And I think people like taking an approach where they just reinvent everything just for the sake of it. Some people would
just like wrap around anything else and be like more of a go-to-market thing. We started like tackling the limiting factor always and again, back then
GPT Paulo mentioned, you know, like 3.5 was very relatively fast and not so good. So we had to
fine-tune the LLM. Soon enough we realized that prompting and, you know, all these good models came out. Prompting was good enough. Scratch that,
let's do that. And always like focusing on that limiting factor then voices like the background noises like supply chain is extremely messy. You're
talking with drivers in their trucks uh with the radio on and background music and noises and accents. So
always focusing on those limiting factors. On the negotiation part, something we got very often was how do you prevent the bot from hallucinating a
rate or like max buy? Like, "Dude, I'm building this thing and it's just hallucinating max buy and it doesn't know how to negotiate. How are you guys
able to do that?" And I think it's because you don't need to show the AI what it doesn't need to see.
And I think we're very opinionated about this from the beginning where we're building these proxy servers and actually exposing to the agent only the
things they need to see. Actually max buy, like the max amount of money the bot can actually see or actually negotiate is not even exposed to the bot.
Like we were not exposing that. We were doing external negotiation algorithms so that the bot would
just ask for permission literally like the same way a human would like, "Hey, let me ask my boss." And it was really just calling a tool and asking
for permission to do more and we would inject back the rate, you know? So those sort of things instead of like just putting in the context when I'm
having the LLM just freestyle it, um we do it in a more deterministic approach. So, it's always that mix
of probabilistic plus deterministic where you need to like let everything to the AI, no? >> It's building for the real world. Like, the real world is
messy, those things are going to happen where someone tries to jailbreak the agent and get that um max amount of money that they can get, but we
needed to build those guardrails very early on uh so that we could actually go to the likes of C.H.
Robinson or Uber Freight and all of these big players that would only trust us if we actually were building real technology. That was pretty clear for
us. We knew that we didn't want to focus on the long tail of logistics and transportation because it's it's a very tricky space, but we knew we needed
to serve the enterprise in transportation and supply chain and logistics. So, that was very clear.
That that shaped the type of products that we had to build the type of primitives that we had to build. >> It's so interesting because Happy Robot was
very early to both voice AI and enterprise agents more broadly, which is great, and also it's like the ground has been shifting under our feet because
the models are themselves are kind of changing and evolving so rapidly to your point about
fine-tuning versus prompting versus kind of what to do next. Maybe we can talk through a few of the use cases you have where it's very clear that like
a smarter model by itself doesn't just do it, and like why you need to buy a platform. >> I I can bring up the Kuehne + Nagel use case. We recently
announced our partnership with like the marquee like freight forwarder, uh great partners. I was um
having a personal uh lunch with uh with their head of uh air. Uh shout-out to uh to our friend Inve at Kuehne + Nagel at his house in in Spain. And
what I learned from their operations is that this is not a a simple customer service type of create a ticket in Zendesk and you know, you're done or
you reply based on a knowledge base. Customer support for these real economy industries like logistics,
transportation, freight forwarders, broader supply chain, even other industries like the Telco space or the utility space, it's not as easy as just
replying based off of a knowledge base again. There's a lot that happens afterwards that really has to get done to provide that update to the
customer. So example, freight forwarding, Kuehne + Nagel, they're serving customers uh very large customers. I
cannot name who, but uh imagine that you are a big customer of Kuehne + Nagel and you ask, "Hey, where is my shipment?" What happens now is an agent
has to turn around and go find it. That go find it is very complex. You need that coordination. You need basically an orchestration agent that is,
"Okay, this is an air shipment, so obviously relates to airlines. Who is the airline on this on this
shipment? Okay, let me go to the airline's website." So we have browsing agents that go and scrape the website of the airline. "Oh, bummer. It's not
there. There's no update. Damn, I need to go send them an email. Okay, I'm sending an email to the airline." 2 hours later, no reply. "Okay, I need to
reason that if they don't reply now, I'm going to miss my SLA with my customer. So now I need to
call them. I'm going to keep calling them until someone picks up at the airline and tell me where the hell is my shipment." So that is the sort of
coordination that we need to make happen um for for transportation and and logistics really um and how and that has shaped the type of product that we
had to build at Einride. >> Yeah, no, I just described everything. I I guess another example on like
the negotiation, which is always like how we started and all these demos when pre-Einride all and I guess one point of how raw intelligence really
wasn't enough is when you're negotiating for example loads and there's like 10 carriers or 10 like buyers calling at the same time. You cannot have
all those agents like doing work independently, which is what happens to a certain degree with like
humans. They're on a floor and sure they shout to each other and they're like, "Hey, this is a very hot load. Please negotiate hard. I have someone
interested, you know?" All this information is really not in the model. So, what we started doing is when you have inbound calls for the same load,
you can start like sharing context across them. Like, "Hey, I have someone. They're very interested.
Please push harder. Like, this is a hot load. Please also all this information sharing is literally what you put in the context window at any point in
time." Like, general intelligence or the raw intelligence doesn't really know if someone else is calling on that load. So, it's all that about like
what do you know about the business? What do you know about that negotiation strategies? Maybe you
know that pushing harder on this load because it's like um cross-border is going to be better or whatnot. Like, that's not general intelligence.
That's very specific and different enterprises operate differently. Like, you cannot just build an agent, fine-tune it, and have it work at any type
of company. All those nuances is outside of the model. It's that context layer that we're trying to
create, you know? And that actually like we can talk about how actually doing the work and executing the work is what gets you that. It's like
learning by experience. It's you do something and you learn and you explore that space of the context layer so that you can keep learning, you know?
Really interesting. So, you talked about two different things there, Pablo. You just been talked about a
very cross-functional workflow. Luis, you talked about the complexity of really mastering sales, you know? You guys started as sales and support. And
so, what are some of the other surprises that you've had having started with more complexity, I think, than some of your competitors. >> So, one thing
that we heard from one of the largest trucking companies recently was typically when we buy
technology we see where we can apply that. With you guys, we actually have a problem and we come to you guys with that problem because we know that as
a platform that you've built, we can pretty much build any type of agent for our operations, from sales to customer service, back office support and
operations and even collections. So, some of the use cases our customers came to us were, "Hey, we
have a huge collections problem. Can you build an agent to reach out to customers via email or voice and collect money?" We're like, "Of course." Uh
we talked about these use cases with one of our largest um supply chain companies and customers um where we need to call customers to recover duties
on parcels. And today we're running campaigns of 20 to 50,000 daily um outreach to customers
collecting duties on parcels that otherwise they would not get if they don't pay the duty on the parcel. So, that's sort of um surprises, if you will,
we've gotten from customers. They're like, "Hey, I also need to recruit drivers. Can you do that?" And we obviously can build an agent that not only
just recruits drivers, actually connects to the operations so that now they know they can service a
truck with a with a customer earlier because now they have a driver to move that. So, there's all sorts of interesting connections between the
functions. Maybe I'll give you another example. We build an agent to reach out to maintenance shops to see where a truck or when a truck was ready.
You could just leave that agent in a silo and just have an agent that is proactively reaching out to those
repair shops to see where the truck when the truck is ready. Well, it turns out that the sooner you know when the truck is ready, the sooner you can
put it in the market to sell it as capacity for your customers to actually move things. So, that was a very interesting realization of how sales in
this case and maintenance were tightly connected. So, that is the context that we talk about. There's
there has to be an underlying context sharing across the different functions in a business so that the whole business optimizes its optimizes for uh
um a global maxima, if you will, or a global minima depending on what optimization problem you're trying to run versus just minimizing the problem in
one function, if that makes sense. >> Yeah. And then maybe can you talk about like what how do you
discover these workflows? Who discovers them? Who builds them? How do they get built? I mean, maybe Luis talk a bit about that. >> Yeah. So, we're
very forward deployed. Um so, we very early on understood [clears throat] that really to solve the customer's pain point, we had to build software
that adapts to their operations and not the other way around, which is like the old era before AI was you
build something and ask people to like run their business however you think they should be run. But, we uh think it should be the other way around.
So, from the very beginning we started like um hiring and building this forward deployed motion with the FDs, forward deployed engineers. Like,
everyone is talking about them now, but I think it's about like really being customer obsessed and really
focusing on like the value at and their problem and really sitting down with them and going to their offices and learning what they need. So, sure
there's a lot of like uh synergies in the industry and what you learn from a customer might be relevant to another, but very soon we realized that
there's not a one-size-fits-all even within I in market sales even like within this workflow in the
enterprise, maybe like there's like a long tail where this might apply, but enterprises operate very differently. And that's why we built a platform
that um is flexible enough to adapt to anyone's operation. And it's because we were trying to like plug and play what we build somehow with a customer
to another one, it didn't really work. Like, they want something different. They want to change the
procedure. They want to call these tools. They want to escalate whenever the carrier is not vetted, and someone else wants to do it automated. So, we
really had to build up almost like horizontal technology because of the variety of all the nuances in this industry, you know? And that's how we
create a platform that is not optimized for like specific tasks, but more so optimized for like doing
work. So, our primitives are around workflows and data and integrations and, you know, um SOPs, prompts. You don't see like particular task being
modeled because that's almost too opinionated and customers don't want like opinionated like their vendors forming opinions on how to run their
operations. Like they've been running it for a long time. Um I they don't know more about their business than
I do. I just come with the technology and I just want come to like solve their problems, you know? >> Yeah, I understand. I feel like the forward
deployed motion has been crucial for AI application layer businesses and also it's prompted a lot of questions about what are margins? What is like a
service versus a product? Kind of where is the long-term alpha and moat? Um maybe walk us through how
you think about productizing the work that your FDEs do, which I think is kind of a unique strength of Happy Robot. Where does the forward deployed
motion start and end? Do you do custom work for one customer? Would love to understand how that works. >> Maybe let's start uh with in the beginning.
I was the first forward deployed engineer without knowing it, I guess. >> Yeah. >> Uh which is pretty
much what any founder would do, you know? Like you just go to your customers, spend a week there, and just chase down the people that are actually
doing thing that you want to help them automate, right? So, I did that and I would be like pinging these guys like do it. You need to build this thing
because it's going to make my life a lot easier and it's actually going to be replicable across
customers because I've seen it. So, please build it and he would be like mm really? Do I need to build that? So, there was that good tension between
um kind of that forward deployed motion and the product team. Uh so, we kept going with these like separate worlds for a little bit where I would be
like leading the FDE team and the deployment strategist that we realized at some point we actually
needed. Uh that was a bit of a realization a bit of a parenthesis here. Uh we started just with four deployment engineers and then they're like the
customer's like hey wait, you have these people building but like who is managing? I'm like hmm, I guess that's like the deployment strategist some
degree. So the deployment strategist is a figure that scopes the problem so that the four deployment
engineer can spend more time on building. Although now what we see is that the right FDE or deployment strategist they have to be very
cross-functional. Close parenthesis on the type of profile. So what ended up happening is >> [snorts] >> we were too disconnected from like the before
deployment world and the product team. So we realized that needed to be part of Luis's world so that the FDE team
would actually be an extension of product which is what they should always be. It's an extension of product so that we can implement product faster.
We can gather the feedback faster from the customers and hence capture that context faster than anyone else. So it's a bit of these iterate the
iterative loop uh that we let that Luis really realize we needed. >> Yeah, I'll add to that. I mean if we
go like first principles, what are we doing? We're deploying agents uh across different functions and channels in the enterprise. So our product is
built for the deployment of an agent. Like we really understand the deployment life cycle because we work very closely with our with our customers and
we are actually deploying these agents, no? And and something cool that happens is that you have to a
certain degree your user in your house cuz we're building for the FDEs for the most part. And it's not entirely true. Some of course some enterprises
they really appreciate having a platform and we can talk about that later about how interesting the mix of coming with a platform they can also use
and an FDE that they can trust is actually something very rare and they mention that. But I guess to
the point of like the deployment life cycle, we really understand what it takes to like deploy an agent, no? There's a scoping phase, there's a
building, there's testing, there's monitoring, there's like a self-learning loop. So, I guess the point is we're every feature we're building in the
product is optimized for that deployment life cycle, and the only way to know if that works is being very
close to the deployment, no? And if FDs are doing these deployments or they're getting feedback from the other team. So, actually more than the FDs
very being very close to the product, I think it's more so like our product is a combination of a platform and a forward deployed motion, and it would
really not exist. And there's like this conversation about like services and stuff. The difference is
that the forward deployed engineer are like catalyst or accelerators to value, but what we're leaving in the customer are like agents running. There's
a platform. Once the FDs are have done their work, they leave a working thing. So, it's almost like you spend that time, you deploy a thing, but the
what you're not delivering like an output that the FD has done, you're literally delivering the
agent working on a platform, no? So, it's a very different distinction of pure services versus like a forward deployed implementation plus the
platform running the value uh forever, hopefully. >> Awesome. I feel like another thing that uh has been a topic of discussion is kind of what is the
value of systems of record in the AI era? Do does every application company need to become one of those?
And I know you at Happy Robot have a view on kind of systems of record versus maybe systems of action or systems of execution. So, would love to talk
through kind of your view on that topic. >> Maybe I'll start quickly. Uh we see ourselves as that layer of execution, really. Like that's where the
magic happens. You have to start doing the work to capture that context. So, it's very important that
we start with executing work, with getting the thing done, implementing one agent, implementing the second agent, connecting them through that context
layer. But the context layer happens after you're actually doing the work. There, more than ever, um the importance is on the execution layer. So, for
us, and Luis can comment on that more, uh that data piece is a very important piece, but it's it
happens after the agent. So, what we've built is Twin. Twin for us is really that data layer where we connect systems of record of the customer, your
CRM, your ERP, your transportation management system, whatever it is, your Snowflake instance, and where agents can also populate their own or re-
like store their own context. It's almost Hyper-automation data points. So, we've basically created
these data layer that holds both customer records and Hyper-automation agent created records, if you will. >> Yeah, I think there's an interesting
tension in um how much you need how much time you need to spend ahead of deploying the agents on clean the data versus just deploying the agents and
clean the data through doing the execution. And I think it's a mix. I think what we realized is these
agents are creating a lot of information that really hasn't been captured before, and it really doesn't fit in any of these systems, because it's more
like um high-dimensional semantic uh almost like memory intelligence. Um so, I guess the point is many enterprises, I guess, are waiting to clean
their data sources so that they can power this uh workforce of agents. And I think by doing the work
and by actually having agents execute the work, you're going to clean the data as you go. Cuz humans are great, of course, but they have a lot of
limitations. Like, they cannot be in the same place at uh in two places at the same time. They drop a lot of threads. They're not very diligent uh and
putting the data in the right system. Like, sometimes you forget, sometimes you write it down. So,
actually, you can clean all your data sources, and then you can still run with humans, and it's actually going to probably get dirty very, very soon.
The good thing about AI is it's very diligent with its data, you know? So, it's through the process of executing work, you're going to progressively
start cleaning all your data sources because you're going to get visibility into all these things,
you know? So, not only are you connecting the data like the systems of record like rows and columns and different entities, it's more so creating
relationships across them. So, again, the shipment in the TMS is just a record. Like, that's really not the IPs. How that record might exist in many
different enterprises. Like, it's latitude, longitude, rate, whatever it is. Like, that really doesn't
mean anything. What means something is how an enterprise is going to What the enterprise is going to do with that. Like, once it gets into the system,
how their processes are built, how their humans are going to deal with that. So, all that is really not in the system. It's more so like in people's
brains. A lot of this context is like tribal knowledge the operators hold. And to a certain degree,
they It's not It's super fragmented, you know? So, actually by doing the work, we're going to learn a lot about this more conversational record or
intelligence. But, also we're going to start like cleaning the end systems of record just by doing the work very consistently, you know? >> You know,
Luis, that's such an interesting topic cuz it's sort of like my intuition my naive intuition is that
information about execution is maybe ephemeral or the value of it decays over time. But, I think what you're describing is how the value actually
compounds over time. And maybe that actually enriches the information in the system of record. Which one is true and why? >> Yeah, I mean, I think
you're So, what you're doing by doing the execution, as I said, is one, creating a better understanding
about the relationships of all these different entities. >> Mhm. >> Um so, you're starting to connect the TMS, the CRM, the ERP, the Snowflake, the
Notion page you have, the docs. Everything is so disconnected. You're going to start connecting it. But, you're also going to start enriching the
relationships of how to deal with those particular records, you know? So, I guess the compounding comes
from like two angles. One is having clearer or cleaner data sources, like literally the data points, is going to make everyone's life easier, but also
understanding how to relate those different entities across the business, no? So, I think it compounds from multiple angles. >> And then, how much are
you Initially, I imagine you're capturing the way work is done on day zero, but over time you're
changing the way that work is done. What is that interaction like? >> Yeah, and I think if you think about it from a context perspective, the FDs are
really just seeding this state graph. Like, if you if you try to model like the the business as a as some world model or a model of the business, you
need to seed it somehow. Like, you can just put the agent to work from day zero, but then there's a
point where there's a like a flywheel where like the second and third and fifth deployment takes less time, but I think the FDs are the ones like
going to the business and starting to seed all this context layer and actually leaving it there for like learning and the second and third one, no?
So, there's always this cold start problem, and we talk about like fine-tuning SLMs in the future like
reinforcement learning and all that stuff. I think that really doesn't make sense if you don't have the basics and you don't have the first and second
agent in production, and that's why FDs are so important to like actually start this flywheel. Like, they they would go there go there um interview
the operators, get all the specs, and actually put those first agents to work, and from there the
system is going to start learning and getting all this context and sharing it across functions and across channels, no? >> I feel like if I was trying
to train someone to do my job, um the context that they need does not live in Salesforce or any traditional software system. It probably would live in
meeting transcripts and emails and casual conversations and even things that software can't
capture hasn't captured. Um I know you guys have this concept of the pyramid of complexity and how starting with some of these primitives allows you
to get into more and more complex work over time. Maybe could walk through some examples of the type of work that happy robot agents can do. >> Can I
talk to them? So the pyramid of work as we define it is essentially the easy, repeatable, low-hanging
fruits type of work at the bottom. Think about an easy B2B sales call, an easy customer service type of operation, some payment collection type of
work, kind of the the highly repeatable um easily automatable type of type of work. One thing that we've already talked about here is how those
actually interconnect, which is very important. Like you might have like these disconnected or siloed
functions today in a company, but very important to keep in mind that those are actually very connected. And going back to the pyramid of work, what
you have at the top is the deep complex work that is highly strategic, that is almost the information that the CEO of that company needs to make
decisions. So when we think about the work that we that we're doing with our customers, we might start at
some we might start somewhere in the bottom of the pyramid, but very fast we're going up the pyramid by combining those agents from sales and customer
service and collections, combining the context as we Louise was saying, so that you build on top and you build on top of every layer, so that every
decision you make is based off of more context across the board. When you're talking to that customer
that has a complaint, you might want to remember that you already upsold them last month, and sometimes human agents might not even remember that.
When we are talking to a driver that had an issue at his delivery 2 weeks ago, you might want to remember that from the operations team, because maybe
now you're more lenient with the rate that you are giving them. Those things are highly
interconnected, and you need to build on top of them so that you grow into the strategic type of decisions. >> Um yeah, and I would add that the real
in my opinion, the real economic leverage and value for the enterprise is really list at the top of the pyramid. Like those are the decisions that are
less volume. Like if you think about it, at the base you have much more volume. At the top you have
fewer decisions that are actually going to drive the outcomes of the enterprises. And we keep talking and hearing about like outcome-based pricing or
consumption-based pricing and whatnot. I think really if you reach the top of the pyramid is where you really make decisions that drive the revenue of
the company. But you cannot start at the top. Like those decisions are highly contextualized. The
same way you can probably not be the CEO of a company if you don't understand anything what's happening below. Uh so actually the only way to get to
the top and make those decisions is by actually capturing all the context underneath. And that's where everyone is getting stuck at. Like everyone is
focusing at that base. It makes sense. It's already to a certain point being commoditized. Like those
are similar tasks keep talking about like, you know, the gen like AGI and general models being able to like automate that work. Maybe, but the point
is if you get stuck at a corner of that base, you're never going to climb that pyramid of complexity because in able to in order to like climb you
need to actually capture context across channels and across functions. Now, we've mentioned this a lot
of bunch of times now. When I was explaining the example about negotiation, I was talking about like phone calls, but what if you get an email from
another carrier actually putting an option? Like all of a sudden, what if the voice agents don't know that there's an email coming through for the
same load? Like it's the same information. Doesn't matter the channel, no? And also what you learn from
that carrier is the same like the same customer you have with the same carrier you have when you're tracking a load or doing all these things, no? So
if you focus on like automating this part of the base, that one corner for everyone, you're probably not going to be able to like climb this pyramid
of complexity, no? So it's it's about creating a unified understanding of the business in able to
like in order to like start climbing that pyramid of complexity and going to like the deeper complex decisions that actually drive economic value for
the enterprises. >> Really interesting. Maybe you guys talk about how that opportunity has set you up to be pulled into other markets. Like now we're
starting to see pull in financial services, utilities, telecommunications. So, why is the work that
we've done in supply chain applicable to these other markets? >> With DHL, we've deployed over 40 agents across 80 countries. Um agents that are
sharing context across regions and functions. What I realized what the team realized when working with DHL and many others like Kuehne + Nagel or uh
CMA CGM, second largest ocean carrier in the world, was wow, this is not a supply chain specific problem
what that we are solving it's actually an enterprise coordination problem. When we think about ourselves as a startup, we're like 120 people, you
know, we might have like some like miscommunications here and there, but really we don't have a coordination problem in the in the company. You can
easily reach out to the people involved and you just ask questions. That doesn't happen in a company as
big as DHL or FedEx or Deutsche Telekom or T-Mobile or Telefonica. These massive enterprises that have hundreds of thousands of people just
coordinating work. We recently um started working with one of the largest uh utility companies in LatAm and Europe. They have over 10 million
customers, dozens of thousands of employees across the world. How on earth are they going to know real time how to
best serve their customers when they themselves don't even have the tools to interconnect quickly and to share context across them quickly. So, what
we realized is we were not really solving for a supply chain uh problem. We were solving for the coordination problem of the enterprise. Think about a
utility receiving a customer call with someone complaining about a leaky boiler. First of all, you
should already know that customer already had the problem 10 days ago. That's for sure. Second of all, you should also know that the technician you
send was not the right technician. So now in this second attempt to fix that boiler, you need to send the right technician. And the technician that is
best suited for that particular boiler type. So that is now on the operations side potentially. Or
you could frame that as an operation type of problem, no? Versus when I started with the customer calling in, that's more of a customer service type
of problem, right? Again to the point of how these functions are interconnected. But what happens after that technician is being dispatched to the to
the customer's house? Well, now you have an additional layer of coordination between a customer and
the technician. And um the company that is lending the trucks to send that technician. That is that coordination problem that we saw in these
industries in the real economy. Operationally complex businesses like utilities, oil and gas, telcos. So we're now seeing this pull from the market.
We're already working with um in POCs with three of the largest telcos in the world. We're being pulled into
home and auto insurance because the sort of coordination problem of dispatching a tow truck to help you when you when your car breaks down is very
similar to when a trucking company has a a broken truck. That sort of problems are repeatable across the real economy, if you will, when there's these
coordination problem across customers, partners, and your own employees. >> I think this market too
has, you know, broad-based voice first customer support agents. There's the models themselves in voice trying to move into being a gen deck. And then
um there's more verticalized solutions that can move more horizontally. How do you think about like what is a happy robot shaped problem? And where
does that expand into over time versus what are problems that are maybe less interesting for you to
tackle longer term? >> Yeah, I would say highly communicational like and actually more than communication like interface of work to like interface to
the external world meaning also like browsing a website to like retrieve the ETA of a shipment is some sort of like interaction with the outside
world. Voice to a certain point is a soft API as we were talking about same as an email is a soft API or
a website is a soft API like when you're exchanging information between systems of course an API programmatically makes more sense but sometimes that
doesn't really is not the case. So however we can help move the flow of information between systems be a voice email browsing a website or whatever it
takes. Um and also when there's this high complexity in the in the when the decisions are like
contextualized and it's not like the SOPs are not super clear no. I think that's the bigger point where sometimes the enterprise doesn't really know
themselves like people don't know what they know. You can ask them what they're doing and it's like well I'm I'm doing this but they really don't know
that the specific the specificity of what they're doing. So it's actually through doing this
execution of work they're were learning a lot about how these companies operate no. So when the SOPs are not clear and it's like super communication
driven I think that's where we shine. >> Really cool. Luis I want to actually pick your brain a little bit about the voice models themselves because
like many of the other you know companies that we may overlap with rely on 11 labs which is a fabulous
technology where of course investors in 11. You guys have done a bunch of your own model work. Um why what are the kind of trade-offs of you know a
vertical model versus a horizontal model maybe take us through a bit of that. >> Yeah. Um no 11 is great we actually use them for a long time and
they're they're they're great of course. Uh I guess to the point before I were always focusing on like the
limiting factor and seeing what do we need to do to solve the current problems of the market? Um I guess we started very soon realizing how there was
a problem in like in like turn-taking detection. Like end of turn is probably the biggest problem in voice AI and we realized that very early on
because everyone was focusing on like making the latency lower and making the voices more realistic and
that's fine, but I don't really think that's the problem like right now to deployment of these agents, not even the intelligence. Like model
capability is high enough. Like we're using models from in certain use cases that were released like 2 years ago. >> Right. >> Like sure, like
everyone is like pushing the frontier and increasing context windows and making more reasoning budget. >> customer
support now. >> Exactly. Like everyone is waiting for someone to release like a 10 trillion talking context window to like do whatever. Like we were
using models from 1 year and a half ago to call drivers and ask if they're going to make it on time. You don't need PhD level intelligence for that.
Right. >> I guess the point is as we make models faster, we realize how important the conversation
handling and the flow of the conversation is. Like if you think about it, the faster the models get, uh the more you're going to interrupt and the
harder it's going to be to like have a normal conversation. And actually, if you think about it, the bigger problem in the coming years for like voice
AI is really knowing when to talk and when not to talk. And sometimes you need to speak fast,
sometimes you need to wait because the other person has not done talking. Sometimes you might need to like stop and think. And that's something that
the models are not today very good at, like really stopping and knowing when a question is hard and when they need to like probably trigger a
reasoning thread that is more async and just think about it and say something like um and really be thinking,
not something you put in the prompt because it's cool, but just literally have them think, no? So, it's all about understanding the conversation. When
when is it my time to talk and why what should I say, you know? So, I we invest a lot in this end of turn interruption handling, filler detections,
background noises. Like if my mom is speaking at the back of the car, uh the bot doesn't need to know
or interrupt, you know? So, it's understanding all these nuances in the work more than making the latency faster, which is of course we can be
improved, or making the voices more realistic, which again I don't think that's a limiting factor today. >> Yeah, it's interesting. It feels like
we're at the point where the models are so good that as they get better, especially with voice, it actually
takes us further away from human-ness in some cases. Like the latency is too fast, or um the interruption handling is too sensitive. Like if someone
says a filler word, you don't necessarily want the model to react. You want it to keep talking. Um I feel like Happy Robot has always been at the
forefront of kind of human-ness. How do you think about how that shapes product development? How do you
think about um where what that looks like 5 years from now? Do you want the customers the end customer to know they're talking to an AI? Do you want
it to feel like a perfectly human experience? Where does that go? >> I think it's super important that the experience remains as human as possible,
even if you say that it's an AI. We're now live with hundreds of thousands of end customers or end
users talking to our agents, not only via email or voi- or chatbot or website, whatever it is, uh but mostly through voice. Like voice is one of our
um more like one of our primary channels. And one thing we saw is even if you say it's an AI, even if you disclose at the beginning, "Hey, Mr. Driver,
I'm an AI agent. I'm calling you because I need to know where you are." At the beginning, they might
be like "What did you just say? But then very soon they forget. And they forget in a in a good way because they are now just having a normal
conversation with a system that is smart enough to not make their life or their day even harder than it was already before. Um so I I think the
conversationalist the conversationalness the human like capabilities are very important to make technology work. Uh
so for us the the the product is shaped around that experience. Some people um were telling us at the beginning like no you don't need these agents to
sound super human. Why are you investing so much on the on the text speech? Uh why do you care if the agent just mispronounces a a load number a
shipment numbers? Like what do you mean? That's the whole point. You want the experience to be as good
as possible. So it's very important that we continue building towards a really human-like experience. Again voice is obviously a primary channel for
us but even across the board like everything should feel human. Everything should feel just a very natural exchange of information as we were
discussing before. We're just trying to build an AI workforce that is almost colleagues to the employees in
these companies so that they almost collaborate together. That is very important to the DNA that we're building in in Haberal. It almost goes with the
name if you will. Like there's that there's there's that um human-like uh sense in in the products we build for our customers. >> Yeah. >> Well you
know probably to build on that it also strikes me that you make the employees the human employees of
many of your customers also more human. In so far as you know I think it was Kaylee was telling me a story about DHL and Home Depot and the folks that
had previously spent all week on a phone trying to just schedule uh deliveries with Home Depot were now taking folks out for dinner and building
deeper relationships. Maybe talk a bit about what is the future of sort of humans and agents um working
together in these enterprises. >> Is it my future? >> It's a it's a it's a very cool future because a lot of the work that we're helping our customers
automate is work that no one really wants to do. Think about collecting payments from customers. Would you really want to be calling your customer to
be like, "Hey, like you know, like this invoice is past due, man. Like are you going to pay?" >>
Yeah. >> Who wants to be doing that, right? Who wants to be calling a list of dormant accounts to see who would want to ship with us or who would want
to be picking up a call from an angry customer that whose delivery was late or whose technician broke the boiler or whose technician didn't fix the
router. That is the sort of problems that agents can help your human teams alleviate so that again
your humans can actually take that steak dinner with your customer and work on building up the relationship not on fixing the operational problems.
That's the this the problem space we're looking at. The operational complexity that these businesses have that no one really wants to do but that has
to get done. >> Thanks so much for joining us today, guys. We know you are very busy serving a lot of
very happy customers and there's so many more exciting things to come for Happy Robot. >> Thank you so much, guys. >> Thank you for supporting us all the way.