AI Copilots, Agents, and Workers, Oh My!
There are dozens of terms flying around for AI Workers. Learn from leaders from Copy.ai, Relevance AI, and Tribble as they dive into each term's meaning and its ideal use case.
All right. Thank you, everyone, for joining us here at AI Workforce Summit.
I'm really excited for this session. We're going to be talking about the
differences between
like co-pilots and agents and workers and really digging into the different use
cases.
And we have a great panel of speakers here today, which I'm going to let them
introduce themselves.
And Daniel from Relavance AI, if you would like to go first, that'd be amazing.
Absolutely. Thanks, Sarah. Thanks for having us and looking forward to this
conversation today.
So I'm Daniel. I'm going to go first as a Relavance and we're an AI workforce
platform.
Simply put, we enable customers to build and deploy AI agents that complete end
-to-end tasks
autonomously on autopilot. Our goal is to ensure that teams are only limited by
their ideas,
and we don't want them to be limited by their size. So we give them this extra
lever that they
can pull when they want to do more with less, especially something that's very
top of mind for
people today. We achieve this specifically with a horizontal platform, because
just like hiring
employers, we really believe that every agent needs to be customized and
configured for that
specific organization, for that specific world. And some of our flagship use
cases include a
BDR agent, Bosch, and sales, helping automate the type of funnel, whether it's
outbound,
rimbound, we do stuff on support, we do stuff on marketing as well. But again,
the key piece there
is that being a workforce platform, we want that customization, we want that
configuration,
just like when you hire someone, you don't want to bring them on and then to do
the things from
their old company, you want them to do things at your company. And so that's a
really crucial
aspect of our platform. I really love that analogy of bringing someone on. You
don't want them to
have the old bad habits from your old company. You want them to be doing the
things you want
them to your organization. So I'm super excited to dig into some of your more
agent-specific stuff
here in a minute. Next up, Kyle from CopyAI. I'm so excited you're here. We've
chatted a few
times and really excited to talk about AI workers and agents with you. Always a
pleasure, Sarah.
Thanks again for having me. I'm Kyle. I lead the marketing team here at CopyAI.
And we're a
go-to-market AI platform, very similar in many ways to what Daniel just talked
through, helping
companies codify their best practices in what we call AI workflows and then
extend those workflows
across their entire organization so that you can fully automate some things,
really streamline
other things, and just get tremendous business value out of AI. And we're
specifically focused
on going super deep on AI-forgo-to-market teams. And the way to think about
this is open up your
marketing playbook, SCR, sales, C.S., operations playbook to any page. The
pages in those playbook
search processes and those processes right now are executed by humans. Well,
what if you could
execute those processes in some form partially or fully with AI and the
business value that
you get from that? And that's what we help our customers do. Amazing. And then
last, obviously,
most certainly not least, Sunil is joining us from Tribble. Sunil, thank you so
much for being here.
Thanks for having us, Sarah. And hello, everyone. Sunil Rao and the CEO of Trib
ble.
And similar to the first gentleman, the company we're building really is
focusing in on building
agent, but really going deep into workflows of a specific role within a company
. So even within
go-to-market, specifically looking at roles like sales engineers, proposal
managers,
and really digging into the workflows of those individuals and starting to
automate percentage
of those workloads as an agent, as a digital teammate that you can hit up to
get specific tasks
on the team. So we're really taking a more personified approach, but we really
believe going
deeper into that workflow allows us to be more effective at those specific
tasks.
Amazing. So even in those introductions, we've heard a lot of different
terminology used.
There was workers, there's agents, there's co-pilots. We've heard that term
before. So what I want to
kick this session off with is for everyone here that's listening, where are
there differences in
these terminologies? Is a co-pilot different than an agent? Is different than a
worker?
Or are they synonymous? Are they interchangeable? So I'd love to just get all
of your takes on these
different terms that we're hearing a lot in the market right now and how we
should be thinking
about them. So Sunil, I would love to hear your take first on how you think
about these different
terms that we're hearing a lot in the market right now. Yeah, I'll give you the
perspective that
we as Tribble had, and even our product has evolved quite a bit in the course
of the last year. I
think Sarah will be last spoke. We had a version of the product out. We were
very focused on the
RFP workflow within the role of an SC. Very specifically, you're getting RFP'd
by customers.
Typically, you need to have some deep product knowledge, functional knowledge
to answer those
questions. So the product we first put out in the market was actually a Chrome
extension. It was a
co-pilot. So it's actually assisting the human who's doing the job in a web
browser or within an
application helping them complete that task. And they're kind of ferrying
information over.
It's going out doing some work coming back, getting the information and their
porty.
When we think about co-pilot, we kind of talk about it that way where it's an
assist to the
human. When we talk about agent, we actually look at it as, hey, can we hand
over some of this work
directly to the Tribble agent? And in this exact workflow for the RFP, we
actually allow the users
to send a file over via the conversational platform. And Tribble just takes it
off like an
intern, what it takes a first stab at it, figures out whatever problems it runs
into,
it goes back to the completed file with the answers in the right place. So when
we think agent,
it's more end to end workflows, I would say. We think co-pilot, it's more of an
intercept
into the existing workflow. Very interesting, Kyle. Do you agree with that? Do
you see any
differences within either your own product or sort of like what you're seeing
on the market?
Yeah, it's on the whole, I would say, Sunil, we're more or less on the same
page. I would say we
take a slightly different approach where we think about agents as performing a
multi-step
act. And so for as an example, as part of our account intelligence workflow
that builds a
really comprehensive account plan for sales teams, there is a agent embedded in
that workflow,
who is a research agent who has been trained on how to do all the things that
an intern or an
offshore company or an SDR in house would do to understand what's going on
inside of this company,
run the 50 different Google searches, search these different trade applications
, do all of these
things that a research agent would do. Now that's one step in the workflow.
There are other steps
that are necessary to create a full account plan. So agents, I think, can be
end to end. They could
be a sub component of an entire process, but they're, I think, multi-step is
the right way to think
about it. Co-pilot to me, especially the co-pilot that most people are familiar
with, like the chat
GPT type co-pilot experience is more one off task. And frankly, is a pretty
frustrating experience
for a lot of, I'll speak specifically about go to market because that's why I
spend the most time on
pretty frustrating for go to market teams when their CEO is like, our AI
strategy is everybody gets
a chat GPT license. And they're like, what? I have to go learn how to prompt.
And so I've seen a lot
of people, you know, a lot of folks will say that generative AI right now is in
the quote unquote
trough of disillusionment where we were so excited about the transformational
value that you're going
to get from these companies. And then you went and got a chat GPT enterprise
license. And now you're
in this disillusioned trough where you're like, I don't know how to do this.
And so that kind of
co-pilot experience that's super general and requires everybody inside of a
company to develop
a new set of skills, it ain't going to happen. Like it's just not going to
happen. So I think
everything that Daniel and Sunil have talked about so far is about how can you
go much more
sophisticated than that and develop an experience if it's a co-pilot or agent
or whatever experience
that's much more less general purpose and much more focus on solving something
specific for a
specific person team, department or company. And that to me is what a real
agent or a real
co-pilot will do to deliver real business value. I like that. And you mentioned
the trough of
disillusionment. I think it's crazy. We're in this, we're calling it like the
AI era here
qualified. And it's crazy that I think we're in like different, I've never been
in an era where
they're in like different phases. Like the AI worker one seems like it's at
like peak, but like
some of this AI co-pilots like the trough of disillusionment. Like I feel like
it's like
then all different places, which is wild. Daniel, you guys obviously have
agents. I'm curious to
get your take on this as far as like agents versus co-pilots and that
terminology that's being used.
Yeah, I think what Sunil and Kyle covered is really helpful. The lens we have
is like one step
back a little bit where like we actually look at everything through this notion
of a co-pilot or
an autopilot. I think for most buyers out there in the market right now, if you
start Google in one
of those terms like AI agents, AI workers, employees, you'll get co-pilots, you
'll get them all mixed up.
So I think if you when you're evaluating software, right, you're looking for
solutions in this,
if you can start thinking about them, is this like a co-pilot or an autopilot?
It's a really
helpful way, I think, to distinguish the kinds of products out there. And like
Kyle was mentioning,
we really believe that autopilots are places where you can take these, make
dynamic decisions,
multi-steps, it's not a static workflow. The days of RPA where you have a if
this and that,
that's gone now, right, with agents you can actually have it on autopilot,
which means it can make
dynamic decisions based on the scenario, it has in front of it. And we have a
bit of a controversial
opinion on this at relevance. We actually think that for co-pilots, it's a bit
of a short term
trend. I think for every single vertical or functional role that autopilot gets
good enough,
people are going to prefer that because simply it lifts more of the effort from
your team
to the autopilot, unless your team actually not being encumbered by an
assistant and actually
have something they can delegate to. You don't see people in companies having
teams just full of
assistants, they have people they can delegate to. And I think the AI workforce
is a very similar
pattern, so you want to delegate to an autopilot, which can go do work,
obviously come back and
escalate to you. For us, one of the flagship features that we really focus on
is our approval
and escalation process. How can we make sure that these autopilots can come
back, raise their hand,
and ask for help when they need it, just like a person delegates. And so I
think for us,
it's a co-pilot of this autopilot we really are building for the autopilot. We
think that's going
to come faster than we think. And Coach, you did a really good report on this
in November. I
think you want to see the state of the AI report where they look to past
examples of what co-pilots
we know, chess was one example they actually used. People thought humans plus
machine will
be the machine for a very, very long time. It was actually in a couple of years
before the machine
became better than the human plus machine. So the certain use cases where those
autopilots are
really critical, I think when you're evaluating, just bucketing them up in
those two categories
is a really helpful way. If you're a little bit confused right now about the
terminology,
because it's probably going to take a couple of years before this terminology
becomes
better defined and better adhered here to my companies out there.
I think that's fantastic advice. And it's a really good segue for the next
question that I have
for you, Daniel. You mentioned when you did your introduction of relevance, you
guys have some
predefined agents within your organization, but then there's also you kind of
said, "Sky's the
limit. We want people to be able to build their own agents for whatever their
company or their
use cases are." If someone here is listening to this and they're like, "I'm not
sure if I want to buy
one of those personified agents that we're seeing on the market or I feel like
I have a very unique
use case that I need to build something for," when is the right time to use one
or the other? When
is the right time to get one that's fully built out and baked? The company's
done it for you versus
when's the right time for me to go in and put in the work to build something
custom to myself?
Yeah, so out relevance, we kind of broadly define those supersonas as recruit
ers and builders.
So ultimately, we think every single company is going to have these builders in
the company,
which are going to be able to manage and deploy the AI workforce for their
organization. I think
that's as maturity grows, that's going to become the de facto way of doing
business. It's going to be
a critical role part of the business that people are going to be builders. But
given where we are
today, it's a very new concept. It's quite hard to do. We're really on the...
We look at what we
can achieve with relevance for agents. We always think to ourselves, we're very
much in the cutting
edge of what's possible. This will get easier every month. They'll become more
capable.
And while we're in this phase, I think it's extremely useful for people to have
a starting
point. That's a great place for them to kind of see the benefit, see the value
you get buying
from the organization. I think the biggest question we get does it work. And so
being able to show
the organization it works for a specific functional role or use case, a
specific workflow like
Carl's mentioning, a specific process, that's a really powerful thing. That
gets you a lot of buying,
it lets you achieve a lot of things. And then you can invest to do this in more
areas of the business.
So how do the viewpoint we take on that, a relevance, we do believe everyone's
going to be a builder,
but we want to serve the recruiters today. And the best way to serve those
recruiters is give
them a flagship template that can be a starting point for them to build on. Now
as part of our DNA, we want to customize, we want to configure every customer's
bush or BDR agent is going to be different. People do research in different
places. We don't
want a black box thing that just goes to LinkedIn, pulls some, you know, your
new title analysis,
congratulations, and your new role, right? If you're looking for those
solutions, I think that's a
lot of what personified agents are doing today. That's not to me not a true
autopilot, a true autopilot
is what, you know, is being mentioned before about having those multi-steps,
being able to make
dynamic decisions, but those decisions and actions being made based on your
process. Are you checking
X for real research about your business, how are you using your CRM, how are
you using the other tools?
And so that's really mimicking what your employees do. They sit down, they've
got a plethora of tools,
they've got a bunch of decisions they make us pilot a job. Let's define one of
those jobs to be
done. Let's start with a kind of a template for an agent that's customized it
so that,
and then let's go from there. And once you have that buy-in, it feels very easy
to build on two
cases. And we see that expanding very rapidly throughout the organization. So
our customers who
start with a single use case very, very quickly start moving into others,
whether that's going to
market, going from outbound to inbound to database farming, whether that's
going to another team
lifecycle marketing, that's a big one, speaking up right now. So I think for
most people out there,
think of your starting point, and then build up from there, find something that
's operation
expensive right now, but has a clear repeatable job to be done. And that's a
great entryway.
But ultimately, we obviously want you to be a builder. And I think that's what
you should be
thinking about. How are you not locking yourself into the day to make sure that
in a year or two,
when you need to have a much broader set of agents that you have that ability
to expand.
That's super helpful. And Kyle, I'm curious, you've talked before about
templates,
like I know something copy is really good at its templates. Is that something
that you,
like if you've seen that, I feel like you guys have built out a lot of those.
Is that something
you agree with? Or do you have like a different take there? Very similar take.
I would say the
way that we think about the the templatization of these workloads is that there
are some processes
from company A to B to C that are more or less the same. So Daniel mentioned
the account research.
Let's just keep going down that route. Because I'm sure a lot of listeners here
are familiar
with that BDR work or that sales team work more similar than it is different
from company one to
two. And so you can have a really nice templated workflow that gets you 70 or
80% of the way there.
But then to Daniel's point, you need some sort of means of customization to
make sure that you
can get as close to 100% as possible. So that when you are deploying that agent
or when you
are deploying that workflow inside your CRM, it's delivering the full set of
value that's
bespoke for your business. So the templatization of these workloads is really
critical. It just
depends on how similar the processes are from company A to B. Things get a lot
more complicated
on the marketing side. And of course, there are other sales use cases that are
more complicated.
But like the marketing side is really hard. The way that company A approaches
thought leadership
totally different than the way company B approaches thought leadership to so to
some extent,
we can provide some sort of templatized workflow. But there's a lot more
customization that's
required there. So when Daniel talks about the builders, I totally agree. Like
these are going to
be super high leverage people that every company is going to hire. The way that
we think about it,
the similar to Daniel is a go to market AI architect. You need to have the
domain expertise
of what makes for an effective process. And you need to have the AI expertise
to be able to design
and deploy the prompts correctly so that you can put all of these processes
together into a workflow
that is then deployed across your company. And I think that combination of
human strategy,
outsourced to AI to get a lot done is extremely important. But I think it
almost always requires
human on the back at least right now, human on the back end to sense check and
do the last mile
fit and finish and polish types up to make sure that the work product is as
perfect as it needs
to be for prospecting or marketing content or whatever it may be. Absolutely.
Sunil, I have a
question for you that I've been really excited to chat about, which is I've
heard a lot of different
things on the market. And this is funny. I feel like the session is just for my
own edification
of the questions that I've had. And I'm hoping that people listening here also
get the fine value
in this, which is we hear a lot about agents that can do like multiple parts of
a role. Like you
guys have a digital engineer that you've talked about at Triple that can
obviously do you talk
about like step by step, they're doing multiple things versus I know there's
also agents on the
market that like hone in on one specific part of a role or one specific part of
a job description.
Can you just give me your take on like when is the right time to have one that
does that full
end to end versus like when's the right time to have an agent that focuses on
one particular task
within an organization? Are there pros to cons to either that that you've seen?
Yeah, I think I'll sure how we're looking at it. And you know, by all means, I
think the space is
evolving so fast and the other folks in Tannawal agree that even you know, the
level of capability
of some of the foundation models that are coming out and what they can do is
changing at such a
rapid pace that our best thesis at this point is I look back even in my own
experience of you know,
my previous roles building vertical specific software. And there was a need to
build software
very focused on specific industries going deep into the business process of
specific subverticals.
And that always in contrast to the horizontal off the shelf more configurable
software,
there's always this build versus buy discussion. I think now what's changed is
the build part of
the equation is becoming far more easier for most people and broadly applicable
with it.
So this tooling becomes something a lot more people within the enterprise can
use to build
applications, i.e. agents, so pilots, the next generation of software, whereas
it was restricted
before. So for us that the trade off has always been, you know, when we when we
homemade our
specific persona, a specific role in the company, how much more of that task
can we complete,
you know, to cows point, multi step end to end with a level of efficacy that it
can actually
displace a unit of human work in that role. So if we hold in on a specific
person within a company
in a specific role, then can we do one task really, really, really well and do
it out of the box as
consistently as possible within a specific subvertical. So it's almost once
again, it's the
horizontal applicability versus really going deep within one vertical one
business process
and just nailing that consistently and then trying to grow that out. So we've
definitely
taken that approach. And you know, when we think about where to think, you know
, which rules,
it makes sense to take that approach. Well, when when it's a really high
leverage task,
where there's a huge operational cost associated with it, like for us, we
picked sales engineering,
one, because I used to be an SE at Salesforce before I started this and my co-
founder as well.
And two, we know that there's always never enough of them in any go-to market
team and they're a
high leverage role. So it seemed to make sense that if we free up a very
specific unit of time
for them, you know, that has an impact on the org. And it also is a business
process that
these companies are used to buying software for that's the other thing. It's
really hard
to have conversations where we're coming in and talking about this new
transformative platform,
the longer sales cycle, because you're also educating your customer on what
this is and how
to roll it out. Whereas what we found success with is really nailing in
specific area where
they're buying legacy software and one to one displacing it and having a TEDx
still
on just that one business process. So it really matters what you're selling in
the capability.
I gave it from the perspective of what Tribble's doing, but I'm sure when you
go on more general
purpose, there's different ways to work. Absolutely. Now, Kyle, I've got a
question for you. I know
kind of what CopyAI is really focused on is like streamlining parts of the go-
to-market process.
But what's interesting about it is, as we're talking about AI agents and AI
workers, obviously,
this is very AI focused, but humans have to be involved. Like, I think that's
something that
no one is everyone is agreeing that humans have to stay involved in this
process.
I would love to get your take on where that is in the process. As we bring on
AI agents or AI
workers to help streamline things, what do they take on and what do we leave
for humans to still
manage? Yeah, that's a great question, Sarah. And I think it's a continuation
of what Sunil and
Daniel were just talking about. And let's use Sunil's example. Like Sunil has
the domain expertise
from being a sales engineer at Salesforce to know what is required to complete
an RFP response.
If you just go to chat GPT right now and you ask it to try and complete an RFP,
no chance are you going to get anything of value there? No chance. Like, it's
probably
going to create more headaches than it's going to solve. And so what in this,
where we are right
now in this era of AI, and probably this will be the case for a long time, is
you need some sort of
domain expert defining what the workflow is. So what are the steps in
responding to that RFP?
Where do you go to find that information? How do you distill that information
and then complete
that in a way that makes sense for teams? And the same is true for content
creation.
If you are an SEO expert, you need to have a codification of your process in
order to scale it
via AI. You can't just go to chat GPT and say, write me an SEO optimized blog
post. It's not going
to work. It's way more complicated than that. And the landscape of SEO
optimized content is always
changing. And so you need somebody who is able to codify what their process is.
When I write a
long form piece of SEO content, here's what I do. I Google it. I look at the
top three search
results. I read all the H2s. I brainstorm people also ask questions. I do this,
this, this, this,
I create a content brief, I then take that brief and turn it into long form
content. Here's how
I layer in my value prop. Like it's many steps. And this is why it takes days
or weeks to turn around
a piece of SEO content. Because it's, it's a lot of work. But if the SEO expert
takes the time to
codify their process in AI, then you can go reuse that over and over and over
again. So human strategy
on the front end. And like I mentioned before, even if the SEO expert goes and
codifies all
that process really beautifully, the output still isn't good. Like it's not
good enough.
We typically see that our rule of thumb is for every thousand words that AI
writes,
you need to spend about 30 minutes editing rule of thumb. So if it's at 3000
word piece on SEO
content, you're looking at an hour, hour and a half of editing to get it across
a line. And why is
that? Because these models are probabilistic. They're not perfect. They can't
follow instructions
perfectly, especially for long form content. And so there always has to be
right now, at least
human on the back end to do the last mile work. The AI is going to get you into
the red zone.
You need the human to get your cross a cool line. Absolutely. And speaking of
humans,
I'm going to go back to this is like a larger group question here that I would
love to hear
from each of you on, which is as we're talking more about agents and workers,
it's only a matter
of time if not, it's already happening that people are going to bring these
onto their team.
How are we managing those workers? Like you talked about humans there, Kyle. So
maybe this is
just a continuation of your question that I can go to Daniel and Sunil, but who
is managing
these agents or workers? Is there one person that's managing them? Is it
someone that we're
going to like, is it a new role that's hiring these people and like managing
these people? Or
how are you guys thinking about that internally or seeing your customers manage
these agents?
Yeah, I'll defer probably more so to Daniel on this because I think he's given
this more thought.
But my general take is what we've already mentioned before, which is there is
going to be what we call
a go-to-market architect with Daniel, call us a builder. There is going to be
those people
that are probably functionally oriented because they have to have that
combination. I know it's
something like a broken record, but I believe they have to have the combination
of the domain
expertise and the AI expertise. I don't want somebody who is a software
engineer managing
my workflows for my go-to-market team. They don't have the domain expert enough
. Most of them
don't have enough domain expertise to do that effectively. So I think it needs
to be a combination
and I see these AI architects embedded across different functions inside of the
organization.
I'm really curious to hear Daniel's take on this. You too.
Yeah, we spend a lot of time thinking about this actually because it kind of
defines how we
build our product. For a lot of what we do, the decisions we make are actually
very
closely aligned to what Kyle was just saying there by the software engineer.
If we think about software typically, you have domain experts with a bunch of
engineers,
we're building a great product to serve a market. When we talk about agents
that are
functionally doing a lot of the work that humans do, which is very dynamic and
very flexible,
very different. It's really difficult to codify that in terms of a specific
kind of an RPA style
code of codification where it's like, if this and that, which is what software
is, software is
deterministic. And therefore, if you are set up to have engineers building this
, you're kind of
going to fail because engineers are not going to be able to handle those
nuances and not going
able to handle all these different little pieces and points for every single
team, every single
personal organization, which becomes exponentially more difficult when you have
a larger organization.
So what we've done is in order to try to combat that is make sure that the
agent building experience
is designed for the subject matter experts. We want to bring that expertise
down as much as
possible so that the people who have the skills can distill them down into the
agents.
And the people who know how to evaluate it can also evaluate the output in the
same way that
a manager is evaluating their junior employees work in the same way that a
sales enable person is
coaching their sales team and how to do something. We want to distill those
expertise into the
agent and we want to have those same people managing. That being said, we're
seeing this
really interesting trend with our customers right now. The ones who are
starting to think
out, what does the next 12, 24 months look like for us, are starting to think
of this almost like
an AI workforce manager role. We've already got one customer actually who's
just basically promoted
the they were initially in RevOps. They started out the project on the go-to
market side. They've
now promoted them into a more of a AI workforce manager role. And their role is
actually to work
with the other kind of in their business RevOps equivalent in other teams,
personas, to help
educate them on how they should be deploying this for their teams. So we're
kind of having these
leaders within each team within this AI workforce manager, which is like a go-
to who can help
cross the gap on some of the knowledge pieces that they're missing for those
other teams.
And so we're seeing this really interesting trend where I think a lot of these
companies are going to
have this expertise internally that can help disseminate the first organization
, but ultimately
it has to remain within those teams. You don't have engineers hiring your STS.
You don't have
engineers hiring your new marketing person. Why would they be building the
agent? Which does that
role? You have to have the same teams function on that. And so for us, it feels
very much like
it's going to stay in those places. And so you're going to need people in those
teams to
are a little bit more comfortable with a more technical side. Sales engineers,
RevOps people,
like these tiny personas tends to be really good in sales. You have a lot of
these similar pieces
in other functions who can take the flag and push the team forward, but it has
to be deployed
throughout those organizations. Because as Kyle said, if you don't have the
domain expertise,
what are you doing later? Can you engineer go and sell to someone new? Like if
they can't do
that, then why are they building it? I think that's a really important thing to
keep in mind.
Absolutely. Sunil, are you seeing the same thing with your sales engineer? Is
it like a sales team
that's managing that? Or have you seen any like different management type
things within your
either your company or your customers? Yeah, I think, you know, in most cases,
what's been interesting
to see is a lot of companies have also stood up, essentially these, they're
calling it. Yeah,
I counsels like, how do I procure the software and starting to rationalize
across use cases and
then also to terminate who are the owners of the software? What's its current
procure? How do you
continue to maintain management? And I keep coming back to this build versus
buy, because I think
when you have more of a horizontal platform, like what Deidion and Kyle are
talking about in some
cases, you might have a broader function that needs to manage multiple
processes. Or when you're
purchasing something like triple, you know, we're specifically going in and
saying, hey,
it's mimicking the role of the sales editor, the proposal manager. So it's
augmenting the existing
team and it becomes part of that team. So you continue to manage it as you
would a team member
on that team, because we try to minimize the workload on the team to actually
build part of the product.
So we are more out of the box, if you will, as opposed to it being a little bit
more general
purpose to make it fit where use cases. So in that case, for us, the
implementation of rollout
really is, hey, how do we get the team to understand how to use the product,
how to put it in their
hands, drive adoption that way, and roll it out. So it's a little bit, you know
, once again,
I keep coming back to words, auto vertical, right? Because I think there is
this, when it's
much more purpose-filled, the way you get into the hands of folks and roll it
out is different.
Now, I will say the idea of actually measuring what the thing is doing, however
, is relevant,
right? And I think, you know, one of the things Daniel was talking about is
really interesting,
because sometimes multi-step agent is a black box. So it's like, you want to
ask, you know, if you
give a task to an employee and you say, hey, get this done, they come back and
they get it done,
you're like, wait, what did you do? What is that debug log of exactly how you
executed the steps
you needed to do in order to get that task done? Where do you learn how to do
that? You shouldn't
have done step number seven. So, you know, how do you make that relevant or
available to the users
that are managing this process? For us, it's a really important piece. So we
launched this
capability called tribalytic, which is essentially like opening the hood on why
did I make the
decisions I made to get to what I need to. And I think there's a flavor of that
that needs to
exist in any tool, especially when it gets into multi-step systems that are
going off and doing
make some people very uneasy. Yeah, absolutely. Well, we are almost out of time
. This has been
such an incredible session. I appreciate you guys so much coming on and talking
about this with us.
For anyone who's listening, if you want to learn more about triple or copy AI
or relevance AI and
the agents that they have, we actually have an AI worker job figure here, which
you mentioned in
the beginning, go check them out. They have booths. You can learn a little bit
more about what they do
and go visit their websites to learn more. So guys, thank you so much for
joining us today. This has
been fantastic.