How Decagon Runs 90% of Its Agents on Open-Source Models

An AI agent should just be the front door of your business. Every interaction, whether reactive or proactive with a customer, should be handled by AI.

This narrative dominated the first half of 2026: Anthropic and OpenAI are the last startups. They're going to take over everything.

Even once you have AGI, agents are going to need somewhere to store work, pull information from, and reason about things. I don't think software as a whole, in any meaningful way, is going away.

Unfortunately, the frontier labs do have small models, but you can't really control them in the way that you want. So, today, 90% of our workflow is on open source.

On the specific task we want them to do, they actually outperform the large, smart, state-of-the-art model.

The thing that we built was not an agent that does customer support well, but rather an agent that follows business processes. Instead of us having to write these SOPs, it just does all of that.

Let's say we hit AGI and the models can do all sorts of things we can't even imagine today. What's Decagon's moat, and why does Decagon, 10 years from now, still have a right to exist?

Hey, guys. Welcome back to the studio.

Thanks for having us.

Yeah, good to see you.

Thank you for being here. Before we get into customer support, I actually wanted to widen out a bit. Jesse, I'm going to mention a piece that you wrote recently that went pretty viral because it's right in the middle of the zeitgeist of the conversation around open-source versus closed-source models. Then Thinking Machines and Kimi K3 came out, along with some very interesting open-source models, and there's this really interesting debate going on around what it means to own your destiny when it comes to AI, especially in the enterprise, and what that evolution looks like by use case. Since that's a pretty live topic right now, why don't we start there?

Sounds good. I'm going to talk about our journey first, just to make it very concrete for people. When we started Decagon, the goal was just to get something working, right? When your goal is to get something working, of course you're just going to use the frontier models because you want to get something out there and actually deliver value.

We were using OpenAI and Anthropic at that time. They were kind of one-upping each other in terms of how the models performed. Then, at some point, as we got to larger scale and started working with larger and larger companies that had millions of customers, we also launched our voice agent. A big factor became latency. It wasn't just, “Can you deliver good responses?” You had to deliver them really fast.

The only way to get latency down, but also to make our agent operate the way we wanted it to, was to use smaller models. When you want to go to smaller models, unfortunately, the frontier labs do have small models, but you can't really control them in the way that you want. Most small models out of the box are not going to be good enough at the tasks that we want them to do. So, you have to fine-tune them and change them.

That's when we started looking at open source. This was more than a year ago, and it worked really well. If you think about it, in our agent, our agent's job is to have conversations. It needs to do a lot of things at once. One of the first steps it might take is figuring out what topic this person is talking about. Another thing it might do is determine whether this person is a bad actor who's coming in and trying to mess things up.

There are all these tasks it has to do. Each individual task doesn't need all of the intelligence of a big model. All the frontier models are obviously very smart, but they can do a bunch of different things. They can do math and coding. You just need a model to be good at that one task, and so you can use a smaller model. If you fine-tune it to be really good at that task, it can be just as good as or better than the big models.

That was step 1 for us. About a year ago, we were like, “Okay, let's start using these open-source models.” We took the small ones, and that's why we now have a research team. It's a very expensive team, but we have it because we need people who are really good at taking these open-source models, tuning them, and so on.

Today, 90% of our workflow is on open source. Again, the main reason was latency, to really optimize our voice agents. Over the last year, we've seen tremendous improvement in how it sounds and how it feels, while still keeping the accuracy high.

The remaining 10%, of course, still uses the closed-source and frontier models for many new projects or new products. I think that's just where the industry is moving. If you were to generalize this, you can evaluate every model along 3 dimensions: cost, intelligence, and latency. Depending on what you need, you want to be at the limit of those 3, and sometimes you can trade them off.

In our case, we knew that we could pull back on intelligence because all we had to do was that one task. We got the latency advantages.

I want to push a tiny bit on that point because, often, when you see these debates being had on Twitter, the trade-off tends to be, “Do we want the smartest model that's very expensive, or can we dumb it down a little bit and get it cheaper?” I actually think that is a false trade-off, right?

What we've seen in practice is that even if you have a “dumber” model, you can get it to higher performance on that specific task. When we fine-tune smaller, dumber models, it's not that they're just not as general-purpose; on the specific task we want them to do, they actually outperform the large, smart, state-of-the-art models, right?

We end up getting all 3 things. It is better at the task, it is cheaper, and it is faster.

Do you feel like, today, you need the most frontier models for really anything at Decagon, because your performance is already very good?

We do, and we often end up needing them for auxiliary tasks. When you have auxiliary models alongside our primary conversational flow, you have an agent helping a customer with rebooking or helping them with a process in healthcare. These are well-defined paths, so we have small base models to do that.

But we've recently launched Decagon Autopilot, which is our agent that improves the core conversational agent. Autopilot is doing a very complicated job. It's saying, “I'm going to review a million conversations that just happened. I'm going to try to find trends. I'm going to create variants of the primary model and see which of those variants does better.”

This is a much broader, open-ended, exploratory task. We think that for jobs like that, frontier models that are very smart and can try out a lot of things make a lot of sense.

Do you think that enterprises will get there as well on post-training open-source models? What's the timeline?

I think they'll get there, but it'll probably take longer than people think. Even with our team, fine-tuning these models is nontrivial. It's not just, “Oh, we made the decision to use open source. Let's just use open source.” You have to get the data, and, more importantly, you have to have good evaluations.

If you think about our evaluations, they're very specific to us. You can't just use some public eval set and have that do the job. We're testing the models on our tasks, so we have to generate our own benchmarks and evaluations.

At a certain point, it's strictly better to use open-source models. When your use case is solidified, you're in production at scale, and you're pretty sure this is the sort of shape of the agent, there's no reason not to use open source. You get the latency benefits and, at the same time, the cost benefits. Again, we didn't do this for the cost benefits, but that's a nice side effect.

Once you're there, why use frontier models for that? But for everything that's new and experimental, or for products where you really need the intelligence, you're still going to use frontier models. It's just so much easier to use frontier models. You don't have to worry about the infrastructure; you just use the APIs.

I think that's why, in enterprises right now, even though there's a lot of hype for open source, the share of open-source inference is actually going down. People are spinning up all these new use cases, and if you're spinning up a new use case, of course you're going to use the frontier models until they're working.

Yeah. But of those use cases, some might die off, but some might have enterprises saying, “Okay, great. We want to keep shipping this and roll it out.”

Once it's at that point, they're heavily incentivized to use open source. It's way cheaper and faster. At that point, maybe they can do it in-house, or maybe they'll need help from people to help them fine-tune it. But that will eventually happen. I just think it'll be kind of slow.

Even right now, in our experience, enterprises have a lot of desire to move, but they can only do so many use cases at once. There's inertia there, and they have to go through all the model risk governance and security processes. I think it'll take time, but it will get there.

The other reason I think it makes a lot of sense for enterprises to build their own bundle of models is that the shape of these models is changing constantly, right? We don't just build our set of open-source models, and then it's done—we can move on to our next thing and maybe revisit this in 2 years. You often need to train new models all the time because, as the frontier changes and the capability of the models changes, you come up with new use cases for them.

You find new places where you're like, “Oh, this task seems to be getting repeated a lot because now I have this totally new frontier model or open-source model that has this capability it didn't have before,” right? We find ourselves constantly training net-new models and deprecating old ones that are no longer relevant because maybe the frontier has advanced a lot. The open-source frontier has advanced a lot, and the model out of the box can do many things that it couldn't do before.

Because the model landscape is changing so quickly, Decagon Labs is, in a way, a model factory of sorts, right? We really built it to compress the time between a new model coming out and a useful, fine-tuned-to-our-task model popping out the other end. Yeah, just because it happens all the time.

How do you guys think about what to bring in-house from a talent perspective versus the fairly broad ecosystem right now, which includes RL as a service, evals, and so on? What's your framework for saying, “Hey, this is mission-critical, and we need to do this best,” versus, “Yes, it would be great to outsource this”?

In practice, we've seen that so many things relevant to model training are so tightly coupled to the use case that we find ourselves needing to build a lot of tooling internally. When we have open-source models that we want to fine-tune, we find that if we can clearly tailor our eval to customer outcomes, it's way better than just looking at loss curves over time.

We're not just saying, “Can I do this 1 specific task?” We're measuring the entire system end-to-end. We're not just saying, “Is this model good at this task?” We're saying, “Is this model working in concert with all these other models and delivering the end-customer outcome that we care about?”

Because that is so unique to our setup, we've found that, in practice, we've needed to build a lot of the infrastructure that we need to train and evaluate these models. For other things, like getting labeled data and measuring the diversity of our data sets, we're like, “Yep, these are tasks that are common across companies.”

In that case, we want to buy things from other vendors because that'll help us get those models to production faster. Ultimately, the only thing that we care about is how we can get the best model to production as quickly as we can.

And so, it sounds like there's a lot of talk right now about tokenomics and how expensive it is to actually run a lot of these models. Based on this conversation, it doesn't sound like you guys spend that much time thinking about the cost of these models. Is that correct? It's really about performance for you?

Performance, latency, and accuracy are definitely the driving factors for most of this, right? Cost is a nice benefit in that, surprisingly, this is one of the few tasks where you kind of get all the things for free. We don't actually have to trade off cost, latency, and performance, so just by optimizing for the drivers, which are actually latency and performance, we get cost as a nice side benefit.

Do you think that's something unique to the way Decagon is run, or do you think there's something about this conversation around tokenomics that, for some reason, just doesn't affect you guys in the same way?

No, I think if you're a growth-stage company, then obviously we have to be responsible with our costs, but that's not the highest priority, right? The highest priority is just growing. When you're talking to a customer, they don't really care what your costs are. They just care about how well your agent performs.

That's the main thing. If you look at our unit of output of our agent, which in our case is a conversation, that's really what our customers care about. They don't really care how much that conversation costs us or how many tokens are in it. Over time, the number of tokens we're using per conversation has gone up because we're doing more model calls to make the quality better, do more checks, and parallelize more things.

That's just the stage we're in right now. Eventually, if we've won the market, then that's when it's like, “Okay, yeah, now it's time to look at our costs and see if we can optimize further.” But it's just not the top priority.

I also think we, as a company, are at a different stage than a lot of people who are talking about tokenomics on X, right? The tokenomics debate really is around, “Hey, I'm on a frontier model today. How do I analyze my cost, and should I move to open source?”

There, I actually think it makes complete sense. If we ran our entire business exclusively on frontier models, I would care a lot about cost and think a lot about that. But once you've already made the jump to saying, “Okay, now we know how to think about open-source models, and we know how to decompose a problem, and we know how to build, train, and deploy these models very, very quickly,” all of a sudden, the cost aspect becomes a lot less pressing.

But if you're still in the world where you're using frontier models for everything, then I do think thinking about tokenomics makes a lot of sense.

I just want to make this meta-observation that a lot of the conversation, even just now, has been about things like training models, right? We're talking about reinforcement learning, and it really does blow away what I think is a lingering misperception about what an AI application is.

I want to get into that debate a little bit because I think it's sort of this narrative that dominated the first half of 2026: Anthropic and OpenAI are the last startups; they're going to take over everything. Applications are thin UIs with FTEs, with implementation attached to them.

We talked a little bit about Decagon Labs, but can you guys just share how you think about this potentially false dichotomy of app versus infrastructure company? Clearly, you guys are so much more than the UI or the implementation. And does “agent lab,” the popular description floating around the last couple of weeks, describe it? How do you guys think of Decagon?

I'll give a quick perspective from the POV of an enterprise, and then maybe we can talk about the broader industry. Let's say I'm a Fortune 100 company, right? I'm looking out there at all my use cases, and I have a choice of partnering with an application company or using the labs and building from scratch.

I think there's a lot of merit to partnering with the labs in certain cases. If you look at our case, we just talked about all this fine-tuning stuff. I think a common misconception that people have is that fine-tuning is a way to customize it for that customer. In fact, most of the fine-tuning we do is customizing it for our use case, like the customer-service use case.

Yeah.

It's worth it for us to do it because that's all we do, right? We do these agents across all of these different customers. It's worth it for us to put in a ton of time and research into how to tune this 1 model to be good at selecting customer-service topics. But if you're the enterprise, is it really worth your valuable research resources to tune a model for these customer-service behaviors? Probably not, right?

That's 1 reason why people partner with applications. Another reason is, let's say I do put in the engineering effort to build some agent myself using frontier models. To my earlier point, I'm not fine-tuning for behavior; I'm sort of teaching the AI my own procedures.

Again, that doesn't happen through fine-tuning; that happens in context, because if you were to fine-tune on that, you would have to reverse it every single time you changed your procedures, which doesn't make sense. And so you build out your logic and your business logic. Then you launch the agent, and on day 2, you look at your conversations and you're like, “Oh, well, actually, I need to change these 3 things,” and now it's more engineering effort to do that. It's like a constant engineering effort.

I think people will partner with applications when the use case calls for a broader platform where there's a lot of value in using the stuff that we've fine-tuned and using the software stack we've built on top of the models to capture business logic. That stuff has nothing to do with the models, right? How the business logic gets captured by this AI—how do you handle someone calling in because their flight was canceled and they need to rebook 3 people at once? That is business logic that the AI needs to handle, and you're encoding that, but it has nothing to do with the models themselves.

That has to exist in the application layer. I think that's where applications will still shine, because you still need the application there, and it's not so much the models. The labs themselves will have more application capabilities, but those will be fairly general. You can maybe build general agents that can do this thing or that thing.

But for a lot of these core verticals like ours, our thesis is that you're going to need something that's very deep and has all the integrations, has all the ability to capture business logic, has the ability to run tests and experiments and then review the conversations and run QA, and have tooling for your compliance team to monitor what's happening. That's our thesis on it. It's not black and white: there will be some use cases where it does make sense to use the frontier models, but there will be these core verticals where going super deep makes sense.

Yeah. I also think everyone is bleeding into everybody else's space a little bit, right? That's a convergence. All the labs are building applications on top of it because, rightly so, they're saying, “This is how enterprises do more with us, and this is how enterprises see ROI from using our products.” We on the application layer are realizing, “Hey, we can squeeze out a lot more performance, latency, and cost for the use cases that we care about by building our own models,” right? I think this split, this kind of bleed-over, makes sense, and I think it'll continue.

I'm not as bought into the “labs are less startups” view of the world, though, and I think this is true both for SaaS companies and for the new AI startups. In a way, we human beings are kind of AGI, right? Human beings have needed to use software for lots of things. You need databases to put stuff in; you need CRM to track things. And I think even once you have AGI, all our AGI agents are going to need somewhere to store work and pull information from and reason about things.

So I think a certain class of SaaS companies that were solely built for people to do work might face a bit of heat, but I don't think software as a whole, in any meaningful way, is going away. I still think on the application layer there are so many different kinds of work that need to be done and that can be done faster, more efficiently, and more cheaply. So I think there will always be a space for application-layer companies.

Maybe in the long term, application-layer companies just become labs for specific verticals, because your primary product ends up being the models that are really good at doing those specific tasks. But I think the application layer is probably here to stay.

I also want to pick on another thing that you said in passing.

Yeah, please.

Maybe this is a spicier take: Are application-layer companies just forward-deployed companies that are doing the last mile of work?

Yes. Right. Well, I was saying that's a misperception, but I think it is a common one.

I think it's a really hot thing. Also, again, not to pick on Tech Twitter, but there's this idea that we need to bring back the forward-deployed engineer, and every company is hiring tons of forward-deployed engineers. I think this is a trap.

Actually.

Oh, say more.

Okay. My view on this is that forward-deployed engineers are necessary, or newly necessary, for early-stage AI companies because the workflows are new, right? If you're building a SaaS company 5 years ago, most SaaS products are pretty well explored. You roughly know what the user is trying to do, and your job is maybe to come up with slightly cleaner workflows. But broadly, you know what the user is trying to do with a design app or a CRM or something like that, because those workflows have been explored.

With AI products, nobody knows what the workflows are because nobody's used these things before. So a forward-deployed engineer in this case is honestly just embedding with the customer to learn the workflow for the first time as the customer learns the workflow for the first time. They're kind of paving the road, laying out the track as they see which way the train is going.

But long term, I think they should just be building product, right? Once you know what the workflow is, you should not be relying on forward-deployed engineers anymore. If you can productize it, you should productize it and then become a typical company with these scaling properties of a tech company.

Yeah. And if you can't do that, then you're just building a glorified consulting shop.

Well, I'd love to dig into this more, because I know when we started working together, probably almost exactly 3 years ago, and you guys landed on this idea, there were 2 things that were relatively contrarian that now feel kind of standard. The first was when you started an AI customer service company, a lot of people were like, “That's a GPT wrapper,” and we talked a lot about why that's not the case.

The second thing you did was say, “Hey, we actually want to do the work ourselves. We don't want to just be a software platform.” And now we have the term for that. That's AI agents and everything. You've popularized agent PMs and forward-deployed as a new type of role, or a more common type of role, in Silicon Valley.

But your agent PM and forward-deployed team has actually evolved a lot since you first got started to now. I'd love to talk about that. In the early days, what did it actually look like? And then, as you started to learn about these workflows and were able to productize them better, how has that function actually evolved for you guys?

Yeah. If you look at a lot of our forward-deployed teams, they are building product in one way or another, right? All of our forward-deployed engineers, for instance, build core product. Their job is to go in and understand, as we're working with an enterprise, what are the things that they need that the product does not do today? But the output of that is not a one-off thing that's just built for that customer. It is something that's contributed to the core product in a way that the next 10 customers that ask about the same thing get it for free.

Right? Similarly, our agent PMs are working with our customers to understand: How is the product broken today? How can this actually be deployable within an enterprise? What are the new things that we need to build into our core product to make it deployable within an enterprise?

At the end of the day, all of this boils down to product improvements, either through actual product improvements or through process improvements. We work with very, very large enterprises, and we help them through the journey to go from, “Okay, this is what your org looks like today,” to “Here is how we can take you through changing your processes and implementing new technology into this world where AI agents are doing a lot of work for you.”

A lot of their product work is also productizing how we help a company through that transition.

And you also used to be a deployment strategist at Palantir, so you're very familiar with the forward-deployed model that Palantir popularized. How different is that from what you did at Palantir versus the way you conceptualize this role at Decagon?

Yeah. I think it's dangerous to mix the 2: free consulting work versus actually doing product. Shyam, who's the CTO today, had a phrase internally—I think now it's been written about a ton. He would say, “Forward-deployed engineers eat pain and excrete product.”

Yeah, I think it's a massive misconception, because people are like, “Oh, Palantir is such a hot company, and they're doing so well, and this is a cool take on how to implement stuff.” But first of all, very few companies, if any, can do what Palantir does, which is close massive deals off the bat. It's kind of worth it to spend all that effort.

So I think a lot of the people that are doing this super-forward-deployed strategy—“Hey, we'll do any AI use case for you”—will eventually have to reckon with, “Okay, can we find a product that's scalable?” Otherwise, you are just building a modern Accenture or something, which could be good if that's what you want to do. But I think people conflate the 2. It's like, “Hey, I'm building a hot software company, and we also have FDEs, and that's our big strategy.”

That's something that we've generally been very mindful about from the beginning. We really view ourselves, at our core, as a product-led company, in the sense that we're building a core product that everyone can use. We're not just here to build whatever use case pops up, because ultimately everything has to go into the core product. Otherwise, you can't scale, essentially.

At the same time, of course, I should say we're also kind of sales-led, in the sense that the product is informed by sales.

So we're not sitting there and just coming up with product to build. You have this system where, as I was saying, we have all these people who are forward-deployed in the sense that they work very closely with our customers, but their job isn't just to spin up random new use cases here and there and do whatever the customer wants. In the short term, that could actually lead to larger contracts—you can hunt for wherever the pain is—but in the long term, it's very difficult to scale.

So their job is to compile all of those learnings from sales into a core product. The goal at the end of the day is that we should have the best product out there and be able to iterate on it faster than anyone else. That's, in our space at least, our vision: the winner in this space is going to be very product-driven.

I actually want to pull on this thread of what you talked about, where your FDs are actually improving the product. Decagon is a very product-driven company.

To kick off with a very small, seemingly unrelated anecdote, I was just trying to convince someone on the broader team not to leave a16z for a frontier lab. One of my arguments was that there was a good long-term career here. The response this person gave me was, “We'll have AGI; we don't need careers in the long term.”

It really hit me because I thought I was AGI-pilled, but I had not thought about it from that perspective. I'm curious: We talk about the product improving—can you make that concrete for us? What are some of the “oh” moments as you improve your product for your customer, either from your end or your customer's end, if you can share? Moments where it's, “Oh my God, I didn't realize AI could do that.”

And then, of course, I'm going to ask you your thoughts on AGI and what that timeline looks like, because you're in the nitty-gritty trenches of enterprises using AI, so you may have a different perspective than we do.

The first thing I want to say is I'm certain there will be careers after AGI. [laughter] The reason for that is—

Most of our jobs—

For sure, are jobs that are kind of made up to begin with. Most jobs are made-up jobs. A very real job—

Unless you're building infrastructure or growing food or something. Most jobs are layers of abstraction built on top of other stuff, right? That isn't to say the jobs aren't valuable; it's just that they're kind of made up.

So when AGI is here, it'll change people's jobs, but people will still have jobs, because you're still going to do things for other humans and whatever. I don't really believe that careers will be gone after AGI. I don't think people are just going to be sitting around.

I'll say one observation: for me, it was definitely Duo. So, early on, when we were building the product, the core problem we were solving—again, going back to being sales-led—was that we talked to a bunch of customers and they said, “The value we want to get out of what you're building for us is that we can put it in front of customers, they can have conversations, and it's giving them a much better experience. It's also way easier for us operationally. You're saving costs and making customers happier.”

That was the first agent that we built, and that was the core agent we worked on for the first 1–2 years. The agent on our end, when we were building it, consisted of a ton of stuff. We would have to write these procedures, and we created our own format of procedures called Agent Operating Procedures that teach the AI how to do things. We had to write the tools that the procedures could use to access systems, pull APIs, and whatever. Then we needed to create all these tests to make sure that this thing was working well and that we could simulate all these different situations.

Afterward, once they were in production, we would manually read conversations. There was a ton of work that went into it, even though the core product we were building was itself an agent. What Duo is is a separate agent—a second agent that's much bigger and much slower, but its job is to do all the tasks I just described.

So now, instead of us having to write these AOPs, write these integrations and tools into their systems, write these tests, and monitor the conversations, Duo does all of that. It's a second agent that's smart enough to do all these things, and it just feels very magical because you can literally tell it, “I have nothing built yet, but here's a bunch of transcripts I have and here's some documentation. You go figure out the best way to do all these procedures I want.”

And it'll go do it. Of its own accord, it'll also write the tests and simulations that go along with those. Once you're done with that and you actually put it in front of customers, it'll be the one monitoring all the conversations. It'll flag things where things are going well or poorly, and it'll say, “I read these 1,000 conversations, and actually, there's this one topic that we do really poorly on.”

It'll say, “I've noticed that, and I've also drafted these improvements for you.” So it's like—wow. It's one agent that can do all of that.

That's very magical because, first of all, it wasn't possible when we first started the company. It only became possible when all the reasoning models got better. Of course, Anthropic and OpenAI are making these reasoning models mostly for the Claude Code–type products, but they're also really good for Duo, for example. That was a moment where it was like, “Oh, wow.” You can just see the improvement in the models over time.

And two, it can do all these tasks where we would not have expected AI to be able to do all these tasks at once, but it can do them very well. I think that was a very visceral moment of, “Okay, wow, the models are getting a lot better and they're becoming very generalized.” They can do all these things.

Clearly, the models were not trained on our specific task—writing these procedures and writing these tests—but they're still good at it. Also, to your other question of how we came up with all of this and how the product improved, every single thing that Jesse just talked about was the result of forward-deployed people doing things and us figuring out how to productize it.

For instance, we realized that when we go into a new customer, we need to spend all this time writing up the AOPs manually. We thought, “Wow, this is quite a lot of time. How do we productize this?” We built that into Duo.

The second part, which we called Duo Autopilot, was that once we built Duo, people were using it to write things up, and then we realized there was still a lot of time that went into iterating on the agent once it went live—reviewing conversations and figuring out how to improve it. We thought, “Great, let's productize that as Duo Autopilot.”

In fact, AOPs themselves were a result of this exact scenario, because before AOPs—

You would have to write all these procedures in code—

And then we found that it was taking a lot of forward-deployed engineering work to write all these things in code. We thought, “Wow, wouldn't it be so much easier and more efficient if we could productize it by writing it in plain text?”

Right?

So the way we think about product improvements for forward-deployed engineering investment is that everything is built around what we can productize from forward-deployed work, so that engineers and any kind of customer-facing resources on our team don't need to be as heavily involved.

Can I ask you a blunt question on this line of thinking? I know we've already talked about why OpenAI and Anthropic won't be the last startups, and you've talked about why there's room to have much more specific use cases and specific companies. But you've also had “oh” moments where you're like, “These labs are getting so much better, and the models are getting so much better.”

Long term, let's say we hit AGI and the models can do all sorts of things we can't even imagine today. What's Decagon's moat at the end of the day after all of that? Why does Decagon, 10 years from now, still have a right to exist?

I think in the short term, actually, it is the ability to work with enterprise resources. What I mean by this is that the capability of models today is far greater than how they are being used within the enterprise. You can't just take a model and say, “I'm just going to give this model access to everything within the enterprise, and it'll just figure everything out.” That's practically not how these things work.

To make models like this deployable within the enterprise, let's assume that every model is perfect and makes no mistakes. You need a way to tell the model what it can and cannot do and make sure that it cannot do anything catastrophically wrong.

Then you need a way to make sure that hundreds of people within the enterprise can collaborate to ensure that the agent is behaving as expected in the use cases in which they are experts. Then you need a way to test this model, make sure it doesn't cross any regulatory lines you have, and test that it works well.

Then I need a way to look over the millions of conversations that happen for me to extract insights for the rest of my teams, right? So there's a lot of infrastructure and software that you need to build around these models to make them deployable within an enterprise and make them work with all the legacy systems that these companies have. And so I think for the next few years, that's probably going to be the primary thing that these models need to be able to work with. Once that gets commoditized because the agents can build that on the fly, I don't know, and we'll figure it out 3 years from now.

By the way, I think just listening to you guys, it's very clear that you guys deeply understand how to sell AI to the enterprise. And I don't just mean mid-market, newly IPOed companies; I'm talking about some of the largest companies in the world. I think this is particularly interesting because you both are very technical, but also go-to-market animals.

It just feels like you've turned what maybe started as feeling more like a David and Goliath, with multiple Goliaths, market dynamic into really a 2-horse race between you and Sierra. So share a little bit more about why some of the largest enterprises in the world are buying from you guys.

And I think what's really remarkable to us as people who have studied application software for over a decade is that the sales cycles are crazy fast. I'm sure you guys, with urgency, want them to be faster, but usually you don't sell contracts that big to enterprises that big, right? That takes 2 years sometimes.

So maybe just share a little bit more on this. This is a long question, but how did you grow that commercial? Did you come with that into founding the business, and what's resonating with these large companies that enables you to get in and move so quickly?

Yeah, I mean, we have a lot of respect for Sierra and also just other folks in the space generally. The big platforms all, I think, move a bit slower, but we've met a lot of those teams. They're very competent teams, and they're optimizing for a lot of different things at once.

On Decagon versus Sierra, our most recent customer actually turned off of Sierra to come to Decagon. The reasoning, when we asked them, was that it kind of goes back to this deployment model. When they worked with Sierra, it was mostly FDEs, and it just felt like a black box. The FDEs were good, but they had to go through the FDEs for everything.

So to build new journeys or even get a deeper understanding of what was happening in the conversations, over time that created a lot of drag on how quickly they could move. In the initial deployment, that was good, but then over time, maybe the FDEs were staffed on other things, and it just took them a while to get insight into what was happening and then build out new journeys. Over the course of the year, they maybe built out—I think they said—3.

And so the reason they came to us is because they had that frustration, and they wanted to have a different model where it was a lot more productized. Back to us being very product-driven in our vision, they should have a core product that, even if we're there helping them, even if we are forward-deployed, is in service of helping them build a product that they can use themselves and iterate really fast, with everything in their control.

We like to call this a glass-box approach instead of a black box. Within basically a month, they spun up 7 new journeys on Decagon.

Wow.

Yeah, mostly.

And it had taken Sierra a year to get 3.

Yeah.

Okay, interesting. So it's just the speed of iteration. Some teams will really like this: “Hey, we have control of it. Our teams, especially our nontechnical people, can come in and do things, and they understand what's happening in the conversations.” Maybe there are other teams out there that do like the “Hey, you guys do everything for us” approach. But that's kind of the difference in the approaches, and that's why we've been having a lot of success there.

And then, zooming out, just selling to the enterprise: this is something that Ashwin and I have never sold to the enterprise before, and I think it just so happens that both of us find sales exciting. The enterprise was kind of a quick learning curve for us.

I think a lot of it honestly came naturally, just because our space is so hot. Generally, in these conversations, we're not really having to convince people to invest in this space. It's more, “Hey, we're the right approach for you.” So you partner with us.

With enterprises, it's really just about navigating the organizations and having empathy for what they value and what they're afraid of. We just go back to being sales-led, right? From the beginning, we were like, “Hey, we're going to be extremely strong on the go-to-market side, and that's going to inform the product.”

Even though we have this product-driven philosophy, we don't want to just be dreaming up random products to build. We always had that DNA, and in the early days we were just pushing really hard. I also want to say that we got kind of blessed with a really strong early sales team.

We have a lot of really talented people in that group, and that helped us really get leverage as we were talking to the big enterprises.

Some of whom cold-applied to you guys in the early days, I remember.

Yes. They cold-applied because I think they were working in the space already, and they were seeing from afar what Decagon was starting to do. Some of them had nontraditional sales backgrounds. They were coming into sales. The other profile we had a lot of in the early days was Ivy League athletes, I guess.

Those profiles were kind of a good foundation for the group. We've had to scale that team really fast, which is never easy, so there are things that we're still trying to catch up on in terms of enablement and org structure. But because we've always had that intensity on the sales side, and the whole company knows that everything starts with sales and kind of propagates back, we've always had that focus.

The other thing I think that helped us a lot, to your earlier point about how we got some of these large deals closed so quickly, was that we were very curious about how we could productize parts of it within the enterprise.

Right. By which I mean, we aren't a company that just says, “Hey, here's a product. We'll throw it over the wall, and you get it a year later.” Within a lot of these enterprises, the question they have internally, in addition to “Will this product work for me?” is “Can I actually get this live?” Within a lot of these enterprises, it's actually complicated, especially if you're in financial services and you're regulated, for instance.

So we actually spent a lot of time mapping out that part of the journey very well. When we walk into one of these enterprises, we can walk them through, in very granular detail, how we go from this first meeting today to going live at 100%.

So at this stage, for a company like yours, this is what your model risk process is likely to be. This is how your testing process should look. This is how we should do the initial rollout. This is how we should catch any issues that come up, how we're going to fix them, and how we'll ensure that they don't happen again.

The product and technology part of what we sell is important, but for these large companies, equally important is us helping them think through the process to actually get this deployed and at scale. I think that is something that often gets overlooked by tech companies selling into enterprise.

Yeah, for sure. And by the way, I can also personally attest to the strength of your early go-to-market team, having met a bunch of them.

That being said, I don't want to underplay how many times a decision-maker has told me that one of the reasons, of many, that they're going with Decagon is that they want to make a bet on you guys. They'll literally say, “We think the founding team of Decagon is going to move the fastest. This is a very fast-paced market. It's changing on a weekly, if not daily, basis, and we think that you guys are going to look at the chess pieces and make the right moves.”

It's not the kind of market where everything's going to be the same in a year or even 6 months. So I'm curious—I mean, don't give up too much alpha here—but how much time do you guys spend on sales as founders, and how has that evolved over time?

I probably spend most of my time on it—80%, maybe.

Yeah. Okay.

A lot of it is just pushing speed. Some of it is, as one of the founders, you just have to be in calls. People want to meet the founders, but also, how can I be the main force that's pushing our team to go faster, while also pushing the partnership to move faster?

One of the things with that is that now we work with several of the largest banks in the world, as well as airlines and telcos. No matter how fast you go, those are still massive organizations, and it will take time. One of the things we really try to do is take the project and piece-meal it, so we're not just deploying across every surface area and every use case at once. Instead, we pick 1 or 2 of the top use cases and get a win.

I would say that's been helpful, right? If you navigate a big bank, it's not going to be quick. You don't just close a big deal.

Right?

At least for us, it's not. Maybe some people can do it, but it's still a lot of effort and it takes time. You have to figure out ways to design things from a process perspective, an org perspective, and a product perspective that keep shortening that and finding clever tactics. That kind of thing takes founder involvement. You wouldn't really expect a sales team to constantly come up with new configurations, because they're not responsible for the product or the end-to-end process that the company runs.

Having the founder involved there is very important, I would say. The salespeople's job is to execute on the sales side—build champions, navigate the organization, and so on.

The other reason to spend a ton of time with both sales prospects and existing customers is that the market is changing so quickly. Being able to really quickly understand what the things are that we're not doing today but should be doing is important, because model capabilities are changing all the time. As models roll out, people see other things happening and say, “Oh, wow, this is really cool. I'm seeing this here, and you guys aren't doing that as well.” Being able to stay really, really close to that feedback loop is something we never want to let go of.

Yeah. Do you want to talk about how that informs the product roadmap? Probably 2 years ago or so, most of Decagon's customers were focused purely on customer support, and nowadays I would say that's not true. You guys have broadened your vision to be an AI concierge for your customers. Do you want to talk about what the distinction between those 2 actually is and, in practice, what that means for both your sales teams and your product teams?

When we launched, the original set of use cases that we sold were in customer support. The reason was, 1, that was one of the biggest challenges that a lot of our early customers were facing, and 2, that was where the capabilities of the models ended at the time. That is pretty much the limit of what they were capable of doing.

Now, however, as models have gotten better, our customers have realized, “Why would I have 1 set of models that just learns about my customers when they have a problem, and something else when they come to me to buy something?” We had a customer that we originally went live with for customer support, and then they realized, “Well, you know a lot about our product now. You know about the capabilities that it has, because you need to know that for customer support. You know how we like talking to our customers and what our brand is. Can you help us with inbound sales? When someone comes in, answer questions about us, do some discovery, and then assign it to the right enterprise rep if it's a deal of large enough value.”

We had another customer that started using us for a lot of operational workflows. We're able to proactively reach out to them once we start seeing any kind of issues on that customer's account. Ultimately, the thing that we built—and intentionally built this way from the start—was not an agent that does customer support well, but rather an agent that follows a business process well. Executing on operational workflows, doing sales lead qualification, and answering certain customer support questions are all, at the end of the day, just an agent following a business process. We built it flexibly enough to do all these things because we realized that, at certain points, the models were going to get better—and they have.

And what did they specifically get better at that allows you to do that?

It's specifically the ability to follow instructions well. When you had models, let's say, a few years ago, you'd have to give them very tight guidance—very specific instructions that you didn't want them to deviate from. As the models got smarter, you could give them broader and broader guidance, bigger and bigger instructions, and just trust that the models have good enough sense to interpret it like a human would and fill in any missing gaps.

For customer support, you can have a very tight path that the model should follow, and that's all you really need. Whereas for sales qualification, you want to ask open-ended discovery questions. The conversation is going to bob and weave, so you need the model to fill in with reasonable things. That's specifically what the models got better at over the years.

Yeah. I think if you think about what the 12-month product roadmap is, because things are moving so fast, the real answer is that we see how it evolves. We obviously know what we're working on now, but realistically, in today's AI world, it's very difficult to have a 12-month roadmap to a T. You may know some themes of what you want to build, but ideally, if you have those things, you just build them right now, because it's so fast to build things now.

I would say that's one element, but the long-term vision is still very clear to us, which is why we use the term “concierge.” Really, it just means that an AI agent should be the front door of your business or your brand, and every interaction, whether it's reactive or proactive, with a customer should be handled by AI. We've already seen that AI is very good at customer service, which is a huge pillar of that because it's all these inbound interactions. But why not also be able to do all these other things?

Over time, we're not trying to figure out on our own what these things are. We now have a lot of customers that give us signals on the things they care about, and those will be the things that we build.

We've talked a lot about how the models are getting better and how your capabilities are moving along, even ahead of that progress. What are some of the bottlenecks you're seeing right now, whether that's on the capability side? It could also be around persistent memory—I don't know if you guys feel like that's up to snuff or where you'd like it to be—or it could be other bottlenecks. I'm curious: What would you like to see, and what's holding you back?

Hiring.

Got it. So it's less on the AI side. It's actually that you are voracious consumers of tokens, but you would always love more great people. I think there's so much to build these days.

And why can't you hire AI agents to do the things that you're doing?

Yeah, we are voracious consumers of tokens. Our token bills are very, very large. But there are still things—I don't quite yet think we're at the point where we can have AI agents make decisions on what to build and have the taste to say, “Is this done yet?” We can outsource a lot of specific execution steps, but I don't yet think they're at the point where they can make the call on what to build, what to exclude, and things like that.

The models are improving. Since you founded it 3 years ago, has that changed your hiring needs at all? A lot of people are like, “Oh, you can build 1-person unicorns.”

I think this argument gets tossed around a lot, but an easy counterexample is that all the AI coding startups are hiring like crazy. They're presumably the most sophisticated users of these models, and they are hiring like crazy. I think the reason is that everybody has access to these tools, so if our competitors are going to use them and build more things, we need to build more things.

If somebody else said, “Here's our roadmap, and now we can get through it in 1/3 of the time,” and then they just stopped hiring, we would take that to mean, “Wow, we can get through it in 1/3 of the time. Great. Let's build 3 times as much stuff.” It turns out everybody does the same calculus. So everybody both needs to keep hiring more and ships more. It's great for consumers of these models, but I don't think it has materially changed our hiring plan.

It's so funny. I thought you were going to say something like, I don't know, the latency of voice models or something like that. But it seems like, on the technological bottleneck side, it's—

Yeah, there's still stuff that we're waiting for. Voice-to-voice models are an interesting frontier; there's still research happening on that. Getting smaller models to be smarter out of the box is another one. There are still going to be developments that we're watching closely and that we care about.

But from a business perspective, it's less on the model side and more on whether you can build the company fast.

Yeah. Actually, maybe since we're on the topic of hiring, I feel like “grind slop” has become this theme on X.

It’s so funny because, as a VC, I’ll admit: you guys are famously in the office 6 or 7 days a week. I hope this doesn’t get marked as “grind slop” now, but I think you’re constantly hustling for your teams and your customers. It’s so funny to see that kind of turned on its head.

I’m curious: What are your thoughts on the narrative out there? “Grind slop” is such a general term, but you guys grind, and there’s also a lot of camaraderie and excitement in the office. Say more about that and how you’re building the culture.

“Grind” is a funny term. We’ve never posted “grind slop” because we view working hard as—I don’t think people are working hard to grind. It’s just that there’s a lot of stuff to do. People spend time there mostly because this is a fun time of our life. We want to take advantage of our talent and potential so that it isn’t wasted.

I think that’s the main reason, and it’s many orders removed from the main goal, which is: Can you build a good product, and can you win in a space? One of the effects of that is that people work harder. Even from the beginning, yes, we have an office culture, but we’re never mandating people to come in on the weekends. We don’t really care how long they are in the office. People are in the office so that we can maximize communication, and that’s how we view it.

I don’t view ourselves as abnormally grindy or abnormally ambitious. I think we just have a lot of ambitious people around us, and it has become normal. Everyone works hard, so it’s just normal. I don’t think it’s something that we view as super special.

We also view a lot of what we do very much as a team sport, where we very rarely have lines between our orgs. You will commonly see engineers on early-stage sales calls. You will see salespeople debugging parts of the product. You will see our APM team at absolutely both ends of the spectrum.

Being able to have teams that are so disparate from a function perspective all working together means, first, that you need people in the office because everybody’s jamming on ideas together. But second, it also makes it fun because everyone is working together toward some very specific outcome.

It’s either building this thing for this customer in time for the deal to close or launching this new thing. Because it’s so many different teams working together, it’s a feeling of, “We’re all in this together to get this across the line.”

How does that scale? You’ve launched a lot of new offices recently. You have a new Australia office, a London office, and your New York office is growing like crazy. How do you maintain that culture when you guys are both in San Francisco?

I don’t know. I don’t think it’s a solved problem for us. We’re constantly working on it, and every time the company gets to the next phase, there are new things we have to institute to make sure that everyone understands the culture. There’s very high accountability, and there is pressure because there should be.

That’s something we’re constantly adding as we grow. In the first 100 people, it doesn’t really matter because everyone knows each other. But as you grow, people might not have had the vision or the culture communicated to them.

Ben was talking to us about the a16z culture, right? It’s very action-oriented, and you can’t just put fluffy stuff on there. These are all things that we’re trying to do a better job of as we grow.

The other thing is that we bring everybody we hire out to San Francisco for a couple of weeks when they start, so they’re immersed in the original Decagon culture. At this point, New York and London are big enough that they have the original Decagon culture there anyway. But for brand-new offices, we have people from one of these hubs go out and spend a few months there, until the office becomes big enough and has its own culture, so that it doesn’t become too different from the original Decagon culture.

Actually, on the topic of international, we brought on Raghu Raghuram last year, obviously the former CEO of VMware. In addition to investing, he’s helping us build out a ton of our international capabilities.

One of the things that we’ve seen is that our AI companies are just getting pulled internationally much earlier. For you to have an Australia office seems premature, except for the fact that you have customer pull. Your scale is quite large for how long ago you were founded.

Maybe say more about that. Does your product translate well to these other geographies? Are there more enterprise concerns, or fewer, or is it comparable to the U.S. market?

I think there are 2 trends. One is that AI is such a phenomenon that every buyer out there has tried ChatGPT or whatever, so there’s a lot of top-down pressure from boards and CEOs to get moving on something.

If you think about a lot of these businesses, they’re like, “How do we adopt AI?” Well, let’s do some coding agents and customer service, because those are the obvious ones. There is a lot of pull, to your point.

The other trend is that language is a lot easier with AI. In the past, maybe a blocker would be, “My language just doesn’t work in—or my app just doesn’t work in—German,” or pick your language. But now it’s a lot easier to adapt your app.

I think for those reasons, international has been a lot faster. At the same time, we want to make sure that we’re not getting spread too thin. It’s a balance where it’s unclear what the perfect answer is, but we’ve made a determination about which markets we’re okay with really investing in. If we’re going to invest, we’re going to really invest.

Generally, those markets are ones where we’ve naturally picked up some customers out of the U.S. office or something. Even though there are these trends that make it easier to go internationally, there are also things you don’t really think about. You have to have data residency, there are local competitors that just know the market a lot better, and you have to navigate that well.

Absolutely. Do you think there is space for local competitors to the large categories that we know about?

There is space for them. I think the question is whether, long term, there is consolidation. You could say that for both geographies and verticals, as well as market segments. There are going to be people that find their niche in different places.

Our view—the reason we’ve built so horizontally—is that we believe the winners in our space are going to be horizontal. There’s just not that much that is super-verticalized, where you could see a pure vertical solution surviving. Historically, that’s just been true in our space: Salesforce, Zendesk—all these solutions are very horizontal because you gain more from having that scale and having a very robust and deep product than you do from having very vertical-specific features.

Over time, we’re also going to build vertical features into it, but our view is that from a vertical and market perspective, there will be consolidation.

Related to consolidation, but maybe not just geographic consolidation: If AI concierge becomes really the interface between the business and its customers, how do CRM and all of these traditional, very important systems of record for the end customer evolve in this new world? Do you see any consolidation there in terms of your own role?

I don’t think it’s necessarily an either-or. Ultimately, what we’re doing here is trying to democratize access to, or availability of, these concierges.

If you were going to a business where you were spending $100,000 a year, you would get the most personalized treatment. They would know exactly who you are and what your preferences were. They want to help you shop, for instance. They’ll shut the whole store down for you.

Actually, I don’t know if they do that for—

But you get the general idea, right?

You’ve never tried that before?

I’ve never tried those.

However, if you're at a business where you're spending $10, they can't do this for you because they can't make it economical, right? It is not a lack of desire to do this for their customers. It is just that the unit economics don't support it.

And so, effectively, all we're doing here is saying, “Okay, if you could give them that experience for 10 cents, all of a sudden it becomes economical, and they'd want to do that.” Now, to the point of whether that means CRMs go away, my answer is no. If you have a company today where your concierge is a human being, they still write your information in a CRM so they can track it for later.

I think when we have these AI agents, they will need somewhere to put that information. I don't necessarily think those auxiliary pieces of software go away, because for us, as we're building these concierges, our goal is really: How do we create that great experience? We will still need places to put that data somewhere, right?

Yeah. I actually think CRMs could do quite well. They'll be slightly different, in the sense that CRMs are kind of databases, in a way, and the frustration people have with them sometimes is that the interfaces are really difficult to use. But in the future, maybe the agents are just using the interfaces, and you don't even have graphical interfaces or whatever.

CRMs are still very valuable because they hold the source of truth, and then the agents are just getting pinged a lot more because they're using them. So that's one possible world that's bullish on CRMs. For us personally, so far with Decagon, we have zero desire to build a CRM because we think there's so much to do in the agentic layer, and that's where we want to focus.

Yeah, okay, so SaaS is not dead. [Laughter] Cool. Maybe the last thing is, we were chatting right before we started recording that you guys have done some little AI experimentation on your own as you figure out how to make your own lives more productive and effective. It also sounds like you've done something kind of interesting.

Yeah. I think the models have gotten very smart over the last several years. The 2 of us will often use them to brainstorm ideas because they are genuinely very smart at coming up with great ideas.

However, the bottleneck I realized, at least for a lot of the work that I do, is business context. There's a lot of context for every idea: the constraints that we have, the goals that we're going for, and things like that. That's difficult to explain to the agents every time.

So I actually spent a while building agents for myself to capture all the business context. It looks over my shoulder all the time and is constantly compiling context: Here are the people that we've hired; here are the people that we need to hire; here are the deals that we're working on; here are the problems; here are the current challenges that we have.

Later on, I can just go to it and say, “Hey, there's this new person that we're thinking of hiring. What do you think?” Now it's able to automatically reason: “Well, we had 2 candidates that were very similar, and these candidates had these drawbacks or skills that they didn't have. If we hire this person, it's going to be another person that has those exact same things. So we need someone complementary. This is probably not the best person to hire.”

Or, “In this deal, we're barreling down a very similar path because we didn't validate these things early enough. So this time, we should validate them slightly earlier.” It's really all about how you capture context well, because my job is making decisions with lots of context. If I can outsource that more and more to a model, maybe I can put myself out of a job quicker.

Sounds like you created Jesse. [Laughter]

I do think one of the big struggles of being a solo founder is that you don't have anyone to bounce ideas off of, so you just arrive at conclusions a lot slower.

You guys were both solo founders in the past, right?

Yeah. The reason it was so much easier for us to work together is that we could iterate on things much faster. You kind of just talk something out.

And now you've talked to Fable or whatever. It's pretty good, honestly. They seem very original. [Laughter]

Because in the past, they were just kind of sycophantic, right? They'd just agree with you: “Oh, that's a good idea.” But now they're like, “No, that's a bad idea. Don't do that.”

Actually, for a while, Mark had posted the prompt that he used for Claude. It was something like, “Disagree with me. Be very direct,” things like that. I used that one, and it was great.

The funny story is that I really enjoyed it because it would agree with me very aggressively and disagree with me very aggressively. I took it to my wife and I was like, “This is great. You should use it.” She put it on, and then a day later she was like, “Wow, Claude was being so mean to me all day. I had to turn it off.” It just kept telling me, [laughter] "Yeah, it was just disagreeing with me so aggressively." [gasps]

Amazing. Well, since we're on this topic of founders using AI to do things, I have to bring up the whole AI slop fiasco—maybe “fiasco” is a strong word—that Brian Chesky just went through.

I want to bring it up because you both have grown your profiles a lot over these last few years. I mentioned, Jesse, that you had these pieces that were just hitting the zeitgeist of the discussion that everyone wanted to have, and you came in with a very differentiated take. That's the kind of stuff that we see hit exactly: You're hitting the conversation with the right message at the right time—a unique message at the right time.

Do you use AI for writing? Separately, this is more of a meta question, but how important are X and the sentiment on X to you?

For most of our early days, it was mostly LinkedIn, with the reasoning of, “Hey, our customers are on LinkedIn. We're probably not going to get someone seeing us on Twitter and then coming as a customer.”

But I think the learning we had with X—or at least I was reflecting on it—is that X is kind of the timeline that people talk about. Most of that timeline is not really about your company. If you're just promoting yourself on X, it's going to get no traction whatsoever.

Totally.

But it is sort of like a single timeline that everyone reads. It kind of mind-controls everyone into thinking about the same thing.

Yes, and that's where it's valuable to have some say in it. Who was this guy I was listening to? There's this guy, Jeremy Giffon or something, who's on Patrick O'Shaughnessy's podcast, who I like. He made some claim about how it used to be that the big status symbols in the world were that everyone wanted to be a billionaire, because he calls it the priest class or whatever.

So billionaires are the priest class. But nowadays, when people become billionaires, they want to become X influencers, because those people hold the real power. They can influence what the whole world is thinking about.

That's one reason to have some presence on X, I suppose. When I post on X, I don't really post about Decagon specifically. It's more about our thoughts on what is happening. I think that's a good way to do it, but it is very different.

You write it all yourself, right?

Yeah. AI is good for helping you brainstorm what topics to write about. I think that's pretty good.

I think that was a learning: LinkedIn and X work very differently. You can't just come up with something cool and post the same thing on both, because very few things do well on both. LinkedIn is really good for classic stuff: making announcements, talking about your product, and fundraising. I guess you can do fundraising on X as well, but X is a lot more about placing yourself on top of that single timeline that everyone's on.

Is that too much of a simplification to say X is for hiring, especially AI research talent, and maybe the ecosystem as well, and LinkedIn is more for enterprise customers? Or are you actually seeing enterprise CIOs pay attention to X? Hard attribution is hard, obviously.

Yeah, it's hard, because you could say, “I made a post on X, and then the people on the All-In podcast were talking about it, and CIOs definitely saw that.” So indirectly, I'm sure we got some eyeballs from CIOs. Is the CIO themselves scrolling X all day? Maybe not.

But if you're part of that major timeline, there are always these secondary effects. Then reporters will reach out from mainstream media, and if they write about you—Ashwin was in The New York Times recently—those definitely get eyeballs.

But it was just open-source stuff.

Oh, Kimberly's only on X. [laughter]

You didn't put the next article. I didn't see it. I guess maybe a last question would be—since we touched on hot-button X topics—one serious one has sort of reentered the narrative, I think, with the Anthropic video. Maybe it never left the narrative, but it's about this concept of how, as progress gets better around jobs, the messaging around that becomes more sensitive.

It's interesting because I really think customer support was maybe the first end-to-end use case where you could really do an entire job. Coding was always pair programming to start with. How has that—you know, we sort of joked before, but we weren't really joking—that AI is actually creating jobs? I'm curious: how do you turn that narrative on its head when folks are just losing their jobs? Do you see the up-leveling of folks with AI, where maybe they were doing this job and now they're doing something else?

Yeah. We see this all the time. If you recall earlier, when we were talking about what we're truly doing, we found that for a lot of our customers, there's actually more demand for things like customer support than there's supply.

Right?

Companies realize, "Okay, if our cost of doing customer support drops by 30%..." Most of them aren't immediately saying, "Now what I will do is let go of 60% of my team." They're saying, "Now that this thing, which is clearly valuable for my customers, is much cheaper, let me do more of it, so that my customers retain for longer, so that they don't turn off as much, so that they activate sooner," things like that.

We had a customer in the early days—this was probably 2.5 years ago at this point—that said their ticket volume, the amount of customer support inquiries they received per month, was, I think, 50,000 a month or something, based on the existing surfaces they had. Once they started using us, they said, "Wow, it turns out our customers have a lot of problems." They said, "Let us make support more easily accessible."

So instead of support being buried within one part of a support panel, they said, "Let's put support on every page and make it more prominent in places where people are more likely to get stuck. Let's allow immediate support even for free users, rather than only paying users." Because of this, there's more latent demand for support than there is supply. So automating things doesn't necessarily result in people laying off their entire teams.

That may be the best example of Jevons's paradox in real life that I've heard. So it's exciting.

Yeah. I think AI will kill jobs but not careers, in a way, because the jobs being done currently shouldn't be done by humans. They're very mundane and menial. It's a super-high-volume use case, and people are just picking up the phone: "Okay, let me click here, click here, and, okay, here's the answer," right? That should be done by AI.

But there's actually a near-infinite number of things people could be doing to make their customers happier and take care of them more. People will end up doing those things, and more and more of the mundane, repeatable things will get eaten up by AI. That's what we think will happen.

Jesse, I think on a podcast—maybe Patrick O'Shaughnessy's podcast—a couple of months ago, you mentioned that even your customers, when they've been using BPOs for customer support instead, haven't actually seen layoffs at the BPO. It just turns out that those employees have gone and done other things instead. Is that still true?

Oh, I mean, it really depends on the situation. There are definitely scenarios where people use their BPOs a lot less or don't need the BPO anymore. There are other situations where they're not in cost-cutting mode whatsoever, and their goal is either that their business is growing so quickly that they don't want to scale their operations along with their growth, so with Decagon they can keep it flat, or they still need people, but now there are all these other things those employees could be doing, including more revenue-generating things.

That's a big area for us, even. As AI matures, you first start with these cost-cutting use cases because those are easy, but then revenue-generating use cases should also be able to be done through this conversational interface. So it really depends on the customer, but we definitely have customers that have made massive changes.

Actually, I'd like to end it on that uplifting note. To repeat what Jesse said, it may kill jobs but not careers. I love that. Thank you for joining us, guys. A pleasure to have you.

Thanks for having us.