How Enterprise AI Really Gets Deployed

Summary

---

Podcast Summary: “Decagon’s Playbook for Building Enterprise AI Applications”

Podcast: The a16z Show
Date: July 31, 2026
Host(s): Andreessen Horowitz (Sarah Wang, Kimberly Tan)
Guests: Jesse Zhang & Ashwin Srinivas (Decagon co-founders)

---

Episode Overview

This episode dives deep into Decagon’s approach to building, scaling, and productizing enterprise AI applications, particularly AI agents for business processes and customer support. The conversation covers the shift toward open source models, the nuances of agent vs. infrastructure companies, the evolving nature of enterprise sales in AI, team culture (“grind slop”), and the impact and future of AI on jobs and enterprise workflows.

---

Key Discussion Points & Insights

1. Rethinking the AI Stack: Open Source vs. Frontier Models

• Journey to Open Source:
  • Decagon began prototyping with leading “frontier” closed models (OpenAI, Anthropic) for speed and performance.
  • As scale grew, latency and control became critical, motivating a switch to fine-tuned, smaller open source models, now driving 90% of the workflow.
  • "[...] the main reason was for latency to really optimize our voice agents. Over the last year we've seen tremendous improvement in how it sounds, how it feels, but still also like keeping the accuracy high." – Jesse Zhang [02:16]
• False Trade-offs:
  • The supposed trade-off between intelligence and cost is often misplaced: smaller, fine-tuned models can outperform large models on targeted tasks.
  • "...even if you have a quote, dumber model, you can [...] get it to higher performance on that specific task." – Ashwin Srinivas [05:04]
• Enterprise Adoption:
  • Enterprises will move towards open source, but slowly, due to the complexity of fine-tuning and evaluation, as well as model risk governance.
  • "Even with our team, fine tuning these models is non-trivial [...] most enterprises can only do so many use cases at once. There is inertia there." – Jesse Zhang [07:13]

---

2. Product vs. Infrastructure: What Makes a Moat?

• Not Just Wrappers:
  • Decagon’s value is not as a “GPT wrapper”, but in deeply productizing workflows, modeling business logic, and integrating with enterprise infrastructure.
  • "...most of the fine tuning we do is like customizing it for our use case. Like the customer service use case." – Jesse Zhang [16:31]
  • "You’re encoding [...] business logic that the AI needs to know, but that has nothing to do with the models themselves." – [17:00]
• Application Labs vs. Agnostic Models:
  • The idea of “agent labs” is rising: companies blend model research with productizing domain-specific workflows for enterprise deployment.
  • "We human beings are kind of AGI. Right? [...] Even once you have AGI, agents are going to need somewhere to store work and pull information from and reason about things." – Ashwin Srinivas [19:08]
• Forward Deployed Engineering (FDE) & Agent PMs:
  • Early “forward deployed” teams help uncover workflow truths in greenfield AI domains, but scalable productization is essential for long-term defensibility.
  • "Once you know what the workflow is, if you can productize it, you should productize it..." – Ashwin Srinivas [21:26]
  • "Otherwise you are just building like a modern Accenture." – Jesse Zhang [25:47]

---

3. Scaling & Selling Enterprise AI

• From Black Box to Glass Box:
  • Customers are seeking control and transparency (“glass box”) instead of opaque, consulting-like deployments (“black box”).
  • "Within basically a month, they spun up seven new journeys on Decagon. It had taken a year to get three with the prior provider." – Jesse Zhang [39:36]
• Sales as Founders’ Work:
  • Founders remain heavily involved in sales (~80% of their time), critical for learning, relationship-building, and organizational speed.
  • "I probably spend most of my time, like 80% maybe." – Jesse Zhang [44:44]
• Productizing Enterprise Process:
  • Decagon’s success in fast enterprise cycles stems from mapping integration, risk, and rollout processes, not just product value.
  • "Equally important is usually helping them think through the process to actually get this deployed and at scale." – Ashwin Srinivas [42:14]

---

4. The Expanding Scope of AI Agents & Product Evolution

• Beyond Support — To Business Processes & Concierge:
  • Upgrading from customer service to operational workflows and AI-powered inbound sales.
  • "At the end of the day, the thing that we built [...] was not an agent that does customer support well, but rather an agent that follows business process well." – Ashwin Srinivas [49:11]
• Model Advances:
  • Improvements in following complex instructions unlocked new use cases.
  • "As the models got smarter, you could give it broader and broader guidance, bigger and bigger instructions, and just trust that the models have good enough sense..." – Ashwin Srinivas [49:32]
• Iterative, Not Long-term, Roadmaps:
  • Planning 12 months ahead is difficult in the current AI landscape — rapid iteration with tight customer feedback loops is key.
  • "In today's AI world, it's very difficult to have a 12 month roadmap to a T." – Jesse Zhang [50:24]

---

5. Challenges, Team Culture & Talent

• Hiring is the Bottleneck, Not Technology:
  • The biggest limiters are recruiting and onboarding the right people, not technical constraints.
  • "Hiring." – Ashwin Srinivas [52:02]
  • "I don't yet think [AI agents] are at the point where they can make the call on what to build, what to exclude, things like that." – Ashwin Srinivas [52:21]
• Team Structure & Grind Slop:
  • Decagon’s “grind slop” culture is about team sport, camaraderie, communication, and shared goals over enforced long hours.
  • "Working hard is just [...] there’s a lot of stuff to do [...] it's a fun time of our life." – Jesse Zhang [55:32]
  • "We kind of also view a lot of what we do very much as a team sport. [...] everyone is like working together towards some very specific outcome." – Ashwin Srinivas [56:57]

---

6. International Expansion & Market Structure

• Rapid International Pull:
  • AI’s pervasiveness and improved language capabilities accelerate global adoption.
  • "AI is just such a phenomenon that every buyer out there has tried ChatGPT or whatever. And so there is a lot of just top down pressure from boards and C suites to just get moving on something." – Jesse Zhang [60:37]
• Horizontal vs. Vertical Moats:
  • Decagon bets on building for scale and horizontal applicability (like Salesforce or Zendesk) rather than niche verticalization.
  • "From a vertical and market point of view, there will be consolidation." – Jesse Zhang [62:21]

---

7. Enterprise Data, Systems, and SaaS’s Future

• CRMs & Systems of Record Still Matter:
  • AI concierges will need places to reliably store data; SaaS isn’t dead.
  • "If you have a company today where your concierge is a human being, they still write your info in a CRM so they can track it for later. [...] those kind of auxiliary pieces of software go away, because [...] AI agents will need somewhere to put that information." – Ashwin Srinivas [64:32]
  • "We have zero desire to build a CRM because we think there's so much to do in the agentic layer." – Jesse Zhang [65:44]

---

8. Founders Using AI, Writing, and Social Narrative

• AI for Decision Support:
  • Founders use AI agents to gather and contextualize information, brainstorm, and accelerate decisions, but not for final calls.
  • "My job is making decisions with lots of context. So if I can outsource that more and more to a model, maybe I can put myself on a job quicker." – Ashwin Srinivas [68:32]
• Role of Social Media:
  • X (Twitter) is for zeitgeist participation and hiring/research. LinkedIn is for customer outreach.
  • "If you're very just promoting yourself on X, it's going to get no traction whatsoever. But it is sort of like a single timeline that everyone reads. So it kind of like mind controls everyone to be thinking about the same thing." – Jesse Zhang [71:25]
  • Attribution to business outcomes is indirect but amplifies reach, credibility, and inbound opportunities.

---

9. AI, Jobs, and Social Impact

• AI’s Real Impact: Kills Jobs, Not Careers
  • Automation increases total support capacity and creates new types of customer engagement; people shift roles rather than suffer mass layoffs.
  • “AI will kill jobs, but not careers... People will end up doing those things [that add more value] and more and more of the mundane, repeatable things will get eaten up by AI.” – Jesse Zhang [77:25]
• Jevons Paradox in Customer Support:
  • As cost drops, companies provide more support, increasing overall demand for customer-facing work.
  • “Turns out our customers have a lot of problems. They said, let us make support more easily accessible... Let me do more of it so that my customers retain for longer.” – Ashwin Srinivas [75:30]

---

Notable Quotes & Memorable Moments

• On Productizing Forward-Deployed Engineering:
  • "Forward deployed engineers eat pain and excrete product." – Referenced company saying [25:24]
• On the Speed of AI Product Development Today:
  • “Realistically in today's AI world, it's very difficult to have a 12-month roadmap to a T. [...] If you have those things, you just build it right now.” – Jesse Zhang [50:24]
• On the AI/Jobs Narrative:
  • "AI will kill jobs, but not careers, because those jobs that are being done currently should not be done by humans. [...] There is actually a near infinite amount of things that people could be doing to make their customers happier." – Jesse Zhang [77:25]
• On SaaS & System of Record Survival:
  • “I actually think CRMs could do quite well [...] The agents are just using the interfaces, and you don't even have graphical interfaces or whatever. [...] We have zero desire to build a CRM because we think there's so much to do in the agentic layer." – Jesse Zhang [65:44]

---

Timestamps for Key Segments

• Decagon’s migration to open source models & rationale: [02:17 – 07:13]
• Agent vs. Infra company & the myth of the “thin wrapper”: [15:50 – 22:49]
• Forward deployed teams & productization: [22:49 – 27:52]
• Enterprise sales: differentiation & speed: [37:57 – 42:14]
• Culture, hiring, and “grind slop”: [54:09 – 59:04]
• International growth & horizontal expansion: [59:48 – 63:21]
• AI’s impact on jobs and the Jevons paradox in support: [75:30 – 78:03]

---

Final Takeaway

Decagon’s success in enterprise AI is rooted not in building the “smartest” models, but in ruthless productization, workflow mastery, transparent deployment, and relentless iteration informed by founder-led sales. The future will favor those who can combine cutting-edge models and world-class engineering with empathy for real enterprise needs — creating new kinds of work, not just automating the old.

---

Transcript

[A]

An AI agent should just be the front door of your business and every interaction, whether it's like reactive or proactive with a customer, should be handled by AI.

[B]

This narrative dominated the first half of 2026, which is that anthropic OpenAI, they're the last startups, they're going to take over everything.

[C]

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

[A]

Unfortunately, the Frontier Labs, they do have small models, but you can't really control them in the you want. So today 90% of our workflow is on open source on the specific task

[C]

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

[A]

process well, instead of us having to write these aops, Duet just does all of that.

[D]

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

[E]

The biggest breakthroughs in enterprise AI aren't just happening inside foundation models. They're happening in the products built around them. In this episode, Sarah Wang and Kimberly Tan sit down with decagon co founders Jesse Zhang and Ashwin Srinivas to discuss why they shifted most of their AI stack to open source models, how they think about deploying AI inside large enterprises, and why the future of enterprise software will be shaped by AI agents, not just better models.

[B]

Hey guys, welcome back to the studio.

[C]

Thanks for having us. Yeah, good to see you.

[B]

Thank you for being here. Before we get into customer support, I actually wanted to widen out a bit. And Jesse, I'm going to actually mention a piece that you wrote recently that went pretty viral because it's right in the middle of the zeitgeist of conversation right now on open source versus closed source models and then thinking machines. KBK3, some very interesting open source models. Models came out sort of right after and there's this really interesting debate going on around what does it mean to own your destiny when it comes to AI, especially in the enterprise, and what does that evolution look like by use case? So actually, since that's a pretty live topic right now, why don't we start there?

[C]

Sounds good.

[A]

So I'm going to talk about our journey first. Just to make it very concrete for people. So when we started the company, the goal was just to get something working, right? When the 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 have actually deliver value. And so we were using OpenAI anthropic at that time. They were kind of like one upping each other in terms of how the models performed. And then at some point as we got to larger scale, we started working with larger and larger companies and they had millions of customers. And then we also launched our voice agent, right? So a big factor became latency. So it wasn't just like, can you deliver good responses? You have to deliver them really fast. And the only way to get latency down, but also kind of make our agent operate the way we want it to, is to use smaller models. And when you want to go to smaller models, unfortunately the Frontier Labs, they do have small models, but you can't really control them the way that you want. And 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, you have to change them. And so that's when we started looking at open source. So this was about year plus ago. And I mean, it worked really well because if you think about it in the agent, right? So our agent's job is to have conversations, so it needs to do a lot of things at once, right? Like the first step it might do is, hmm, what topic is this person talking about? Or and something else it might do is, oh, is this person a bad actor that's coming in and trying to mess things up? There's all these tasks it has to do. Each individual task doesn't need all of the intelligence of a big model. So all the frontier models are obviously very smart, but they can do a bunch of different things, like they can do math, they can do coding. You just need them to be good at that one task. And so that's why you can use a smaller model. And if you fine tune it to be really good at that task, it can be just as good or better than the big models, right? So that was step one for us about a year ago. We were like, okay, let's start using these open source models. We took the small ones and then that's why we have now a research team and it's a very expensive team, but we have it because we need people that are really good at taking these open source models and Tuning them, so on. So today 90% of our workflow is on open source. And again, the main reason was for latency to really optimize our voice agents. And I think we've just, over the last year we've seen tremendous improvement in how it sounds, how it feels, but still also like keeping the accuracy high. And then the remaining 10%, of course we're still using the closed source models and the frontier models for a lot of new projects or new products. And I think that's just where the industry is moving to. So if you kind of were to generalize this, every model you can kind of evaluate along three dimensions. It's costs, intelligence and latency. And depending on what you need, you want to kind of be at the limit of those three. And sometimes you can trade off, right? So in our case, we knew that we actually pull back on intelligence because all we had to do was that one task. But now we get these latency advantages.

[C]

I want to push a tiny bit on that point actually, because oftentimes when you see these debates being had on Twitter, the trade off tends to be, oh, do we want the smartest model that is 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? Because what we've seen in practice is even if you have a quote, dumber model, you can get it and we've seen this in practice, you can get it to higher performance on that specific task. So when we fine tune smaller dumber models, it's that they're just thought as general purpose. But on the specific task we want them to do, they actually outperform the large smart state of the art models, right? So we end up getting all three things. It is better at the task, it is cheaper and it is faster.

[D]

And so do you feel like today like you need the most frontier models for really anything at Decagon because your performance is very good already.

[C]

So we do and we often end up needing them for auxiliary tasks, right? Where when you sort of have auxiliary models to our sort of primary conversational flow, you have an agent and is helping a customer with their rebooking or it's helping them with a process in healthcare, then these are like well defined pods. So we have smart, fast models to do that. But we've for instance recently launched Duet Autopilot, right, Which is our agent that improves the core conversational agent. Now for something like Autopilot, it is doing a very complicated job, right? It's saying, I'm going To go and review a million conversations that just happen. I'm going to try and find trends, I'm going to create variants of the primary model and see which of those variants does better. So now this is a much more broad, open ended, exploratory task. So we think four jobs like that, frontier models that are very smart, that can try out a lot of things, make a lot of sense.

[B]

Do you think that, I mean, you guys obviously, and you referenced it, Jesse, that you have a research team, right? You guys launched Decagon Labs, but even before the formal launch, it's always been a part of your culture. Do you think that enterprises will get there as well on post training open source models?

[C]

Oh, okay.

[B]

What's the timeline?

[A]

Yeah, I think they'll get there, but it'll probably take longer than people think because even with our team, fine tuning these models is non trivial. It's not just, oh, you can, it's like, all right, we made the decision to use open source, let's just use open source. Like you have to get the data and then more importantly, you have to like have good evals. And if you think about our evals, right, our evals are very specific to us. You can't just like use some public eval set and like that just does the job. It's like we're testing it on our task and so we have to generate our own benchmarks and evals. But I think the point is that at a certain point it's strictly better to use open source models because when your use case is solidified and you're in production at scale and you're pretty sure this is the sort of shape of the agent, then there's no reason not to use open source because you get these latency benefits and at the same time you get the cost benefits. I mean, again, we didn't do these for cost benefits, but that's a nice side effect, right? And once you're there, it's like, why use Frontier for that? But for everything that's new and sort of experimental, or as Ashman was saying, or like kind of these products where you really need the intelligence, you're still gonna use Frontier and it's just so much easier to use Frontier models. Don't worry about the infra, you just use the APIs. And I think that's why in enterprises right now, even though there's a lot of hype for open source, the sort of share of open source inference is actually going down right now because people are spinning up all these new use cases and if you're spinning up new use cases, of course you're going to use the frontier models until they're working. But of those use cases, some might die off, but like, some might like the enterprises are like, 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 because 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'll 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 is inertia there and you have to go through all the model risk governance and all the security things. And so I think it'll take time, but it will get there.

[C]

Yeah. The other reason I think it makes a lot of sense for enterprises to kind of build their cool vendor of labs 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 we'll revisit this in two years. You often need to train new models all the time because as the frontier changes, as 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 now has this capability that they didn't have before. Right. So we find ourselves constantly training 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 a lot of things that it couldn't do before. So because the model landscape is changing so quickly, Dacagon Labs is in a way a model factory of source. Right. We really built it to compress the time between new model coming out and useful. Fine tuned to our task model, kind of popping out the other end. Yeah. Just because it happens all the time.

[B]

How do you guys think about what to in house from a talent perspective versus there's also a pretty broad ecosystem right now that is, you know, could be RL as a service evals, et cetera. Like how do you guys, what's your framework for? Hey, this is mission critical and we need to do this best versus yes,

[C]

it'd 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 have. Right. That we find that we end up 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 evaluation to customer outcomes, it's way better than just looking at like loss curves over time. Right. We're not just saying, oh, can I do this one 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 delivering the end customer outcome that we care about? And because that is so unique to our setup, we found that in practice we've needed to build a lot of, a lot of the infrastructure that we need to train these models and evaluate them now 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 muscle companies, in which case we want to buy things from other vendors because that'll just help us get those models to production faster. Ultimately, the only thing that we care about is how can we get the best model to production as quickly as we can.

[D]

And so it sounds like, you know, there's a lot of talk right now about like, 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 actually thinking about the cost of these models, is that correct? It's really about the performance for you.

[C]

Performance, latency and accuracy is definitely the driving factor 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. Right. We don't actually have to trade off cost and latency and performance. And so just by optimizing for the drivers, actually latency and performance, we just get cost as a nice side benefit.

[D]

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

[A]

No, I think if you're a growth stage company, then you're honestly like, obviously we have to be responsible with our costs, but that's not the highest priority. Right? The highest Priority is just growing. And 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. So that's, that's the main thing. So actually, if you look at our unit of output of our agent, which is in our case a conversation, that's really what our customers care about. They don't really care about how much that conversation costs to us or how many tokens are in it. And actually, over time, the number of tokens we're using per conversation has gone up because we're actually doing more model calls to make the quality better, to do more checks, to paralyze more things. And 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 cost and see if we can optimize further. But it's just not the top priority.

[C]

I also think we as a company are at a different stage than a lot of people that are talking about tokenomics on X. Right. Because the tokenomic debate really is around, hey, I'm on a frontier model today. How do I analyze my costs and should I move to open source? And there I actually think it makes complete sense. If we ran our entire business exclusively on frontier models, I would care a lot about costs and I would think a lot about that. But once you're already, 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, we know how to build, train and deploy these models very, very quickly, all of a sudden that 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.

[B]

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, you know, a lingering misperception about what an AI application is. And just to get into that debate a little bit, because I think it's sort of this narrative that dominated the first half of 2026, which is that anthropic OpenAI, they're the last startups, they're going to take over everything applications, they're thin UIs with FTEs, you know, with implementation attached to it. You know, we talked a little Bit about Decon Labs, but can you guys just share what is your, like, how do 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. You know, does Agent Lab, you know, popular description floating around the last couple of weeks, like, does that describe it? Like, how do you guys think of Decagon?

[A]

So I'll give a quick perspective, just like from the, from the POV of like an enterprise. And then maybe we can talk about like broader the industry. So let's say I'm like a Fortune 100 company, right? And I'm looking out there on all my use cases and I have a choice of partnering with an application company or sort of using the labs and building from scratch. I think there is a lot of merit to partnering with the labs in certain cases. I think if you look at our case, right, like we just talked about all this fine tuning stuff. I think a common misconception that people have is, you know, fine tuning is a way to like, customize it for that customer. In fact, most of the fine tuning we do is like customizing it for our use case. Like the customer service use case.

[B]

Yeah.

[A]

And 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. And so it is worth it for us to put in a ton of time and research into, like, how do you tune this one model to be good at selecting customer service topics. But if you're the enterprise, is it really worth your valuable resources to like, tune a model for these customer service behaviors? Probably not. So that's one 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 the frontier models. And to my earlier point, I'm not fine tuning for behavior, but I'm sort of teaching the AI my own procedures. And again, that doesn't happen through fine tuning. That happens in context. Because if you were to fine tune on that, you'd have to reverse it every single time you change your procedures, which doesn't make sense. And so you kind of build out your logic and you're building your business logic in. Well, then you watch the agent and then the second day you look at your conversations and you're like, oh, well, actually I need to change these three things. And now it's more engineering effort to do that. And it's like constantly engineering effort. So 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. And that stuff has nothing to do with the models. Right. Like how the business logic gets captured by this AI, like how do you handle someone calling in because their flight was canceled and they need to rebook three people at once. So that is business logic that the AI needs to know and you're encoding that, but that has nothing to do with the models themselves. And so 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 and the labs themselves will have more application capabilities, but those will be fairly general. Like there you can maybe build general agents that can do this thing or that thing. But for a lot of these like core verticals like ours, our thesis is that, you know, you're going to need something that's like very deep and has all the integrations, has all the ability to capture business logic, has the ability to run, you know, tests and experiments and then review the conversations and run QA and like, you know, have tooling for your compliance team to monitor like what's happening. So that's our thesis on it. And so it's kind of, it's, it's not black and white. Like there will be some use cases where it does make sense to use the frontier models, but there will be these like core verticals where going super deep makes sense.

[B]

Yeah.

[C]

I also think, you know, everyone is kind of bleeding into everybody else's space a little bit. True. Right.

[B]

That's a convergence.

[C]

All the, all the labs are building applications on top of it because rightly so, they're saying this is how the enterprises adopt us more. Right. And this is how the enterprises see ROI from using our products us on the application layer. We're realizing that hey, we can squeeze out a lot more performance and latency and cost for the use cases that we care about by building our own models. Right. And 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 lost startup view of the world though. And I think this is true both for SaaS companies and for the new AI startups because in a way we human beings are kind of AGI. Right. And human beings have needed to use software for lots of things. You know, you need databases to put stuff in. You need CRMs 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, you know, a certain class of SaaS companies that were solely built for people to do work might face a bit of heat. But I think, I don't think software as a whole in any meaningful way is going away. And I still think, you know, on the application layer, there's so many different kinds of work that, that need to be done that can be done faster, more efficiently, 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, you know, because your primary product ends up being the models that are just really good at doing those specific tasks. But I think the application layer is probably here to stay. I also want to kind of pick on another thing that you kind of said in passing.

[B]

Yeah, please.

[C]

And maybe this is like a spicier take of, oh, are application layer companies just for deployed companies that are kind of doing the last mile of work?

[D]

Yes. Right.

[B]

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

[C]

Yeah, I think it's a really hot thing thing. Also, again, not to pick on tech Twitter to be like, oh, like, you know, we need to bring back the four deployed engineer and you know, every company is hiring tons of for deployed engineers. I think this is a trap, actually.

[B]

Oh, say more.

[C]

Okay, my, my view on this is that for 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 five years ago, most SaaS products are pretty well explored. Right? Like you roughly know what the user is trying to do and your job is maybe come with a 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. And they're kind of, you know, kind of paving the road. Like, you know, they're kind of laying out the track as they see which way the train is going in a way. But long term, I think they should just be building product, right? Like once you know what the workflow is, you should not be relying on forward deployed engineers anymore. Because once you know what the workflow is, if you can productize it, you should productize it and then become, you know, a typical company with these scaling properties of a tech company. And if you can't do that, then you're just building a glorified consulting truck.

[D]

Well, I'd love to dig into this more because I know when we started working together probably almost exactly three years ago, and you guys landed on this idea, there were two things that were relatively contrarian that now feels kind of standard. The first was when you started an AI customer service. A lot of people were like, that's a GPT wrapper. And we talked a lot about like why that's not the case. And then the second thing you did was say like, hey, we actually want to do the work ourselves. Like we don't want to just be a software platform. And now we have the term for that, that's like AI agents and everything. And you've popularized agent PMs and forward deployed as a new type of role or more common type of role in Silicon Valley. But your like Agent PM forward deployed team has actually evolved a lot since you first got started to now and so would love to talk about that like in the early, 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?

[C]

Yeah, if you look at a lot of our forward deployed teams, they are building product in one way or another, right? So all of our for deployed engineers, for instance, build core product, right? 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 is just built for that customer. It is something that is contributed to 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, you know, 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 to our core product to make it deployable within an enterprise. So at the end of the day, all of this boils down into product improvements, either through actual product improvements or through honestly process improvements. Right? Like 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. Here is how we can take you through changing your processes, through implementing new technology into this world where AI agents are doing a lot of work for you. So a lot of their product work is also processizing a lot of, you know, how we make that, how we help a company through that transition.

[D]

And Aswin, you 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 at what you did at Palantir versus the way you conceptualize this role at decagon. So I do think people use the term FDE very loosely as a locale.

[C]

Yeah. And I think it's dangerous to mix the two of free consulting work versus actually doing product. You know, Shyam, who's the CTF founder today, had a phrase internally. I think now it's been written about a ton. He would say, four deployed engineers eat pain and excrete product.

[A]

Yeah, I think it's a, it's like a massive misconception because people are like, oh, Palantir is such a hot company and like, they're doing so well and like, this is like a cool take on how to implement stuff. But first of all, very few companies, if any, can do what Palantir does, which is like close massive deals off the bat and like, it's kind of worth it to spend all that effort. So I think a lot of the people that are doing this super deployed strategy and like, hey, we'll do any AI use case for you, they will eventually have to reckon with like, okay, can we find a product that's scalable, otherwise you are just building like a modern Accenture or something, which, yeah, it could be good if that's what you want to do. But I think people kind of conflate the two. It's like, hey, I'm building a hot software company and we also have FTEs and like, that's our big strategy. So that's something that we've generally been very mindful about from the beginning, is that we really view ourselves in our core. It's a product led company. Right. In the sense of we're building a core product that everyone can use and we're not just here to, even though we have a large team now, just build whatever use case that pops up because ultimately everything has to go into the core product, otherwise you can't scale eventually. At the same time, of course, I should say we also kind of sales led in the sense of like the product is informed by sales, so we're not sitting there and just coming up with product to build. And so you kind of have this system where, as Ashwin was saying, we have all these people that are forward deployed in the sense that they work very closely with the customers, but their job isn't just to spin up random new use cases here and there and like just doing whatever the customer wants. Because in the short term that could actually lead to like larger contracts and you can kind of hunt for wherever the pain is. But then long term is just very difficult to scale. So their job is to kind of compile all those learnings from sales into a core product. And the goal at the end of the day is like, we should have the best product out there and like be able to iterate on that faster than anyone else. And that's in our space at least our vision of like, hey, the winner in this space is going to be very product driven.

[B]

I actually want to pull on this thread of, you know, that you talked about where your FDs are actually approving the product. You know, Decon is a very product driven company. So just to kick off with a very small, seemingly unrelated anecdote. But I was just trying to convince someone on the broader team to not leave a 16Z for a frontier lab. And one of my arguments was that there was a good long term career here. And the response that 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 really not thought about from that perspective. And I'm curious, you know, we talk about the product improving, right? Can you make that concrete for us? Like what are some of the oh shit moments as you improve your product for your customer either from your end or your customer's end if you can share on like, 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 the enterprises using AI, so you may have a different perspective than, you know, we do.

[A]

The first thing I want to say is I'm like certain there will be careers after AGI. The reason for that is like most of our jobs for sure are four jobs we've kind of like made up to begin. Most jobs are made up speaking self

[C]

check a very real job.

[A]

Unless you're like building infrastructure or like growing food or something. Like, most jobs are kind of like layers of abstraction built on top of, like, other stuff, right? And that. That isn't to say, like, the jobs aren't valuable. It's just they're kind of made up. So when AGI is here, like, it'll change people's jobs, but people stop jobs because you're still going to do things for other humans and. And whatever. So 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, which is like, for me, it was definitely Duet. So early days when we were building the product, right? Like, like the core problem we're solving, again, being back to sales led, we talked to a bunch of customers and they're like, yeah, 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. And also it's way easier for us operationally. It's like you're saving cost and you're making customers happier. So that's the first agent that we built, and that was the core agent we worked on for the first year or two years. And the agent on our end when we were building it consisted of a ton of stuff. Like, we would have to write these procedures, and we kind of created our own format of procedures. We call them agent operating procedures that teach the AI how to do things. We had to write these tools that the procedures can use to access Systems and pull APIs and whatever. And then after that, we need to create all these tests to make sure that this thing is working well and that you can kind of simulate all these different situations. And afterwards, once they're in production, we would manually be reading conversations. There's a ton of. Of work that goes into it, even though the core product we're building is itself an agent. And so what Duet is, is it's kind of a separate agent. It's like 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 and write these integrations and tools into their systems and write these tests and monitor the conversations do I just does all of that, right? So it's like a is a second agent that is smart enough to do all of these things. And it just feels very magical because you can just literally tell it like, hey, I have nothing built yet so far, but here's a bunch of transcripts I have, and here's some documentation. Like, you go figure out the best way to do all these procedures I want, and it'll go do it. And then of its own accord, it'll also write the tests and simulations that go along with those. And once you're done with that and you actually put it in front of customers, it'll be the one that's monitoring all the conversations, and it'll flag things where things are going well or poorly. It'll say, yeah, I read these 1,000 conversations, and actually, there's this one topic that we do really poorly on, and I've noticed that, and I've also drafted these improvements for you. So it's like one agent that can do all of that. And so that's very magical because. Well, first of all, it was not possible when we first started the company. It only became possible when all the reasoning models got better. And of course, Anthropic OpenAI are making these reasoning models mostly for the Claude codes of the world, but they are also really good for, like, Duet, for example. And that was kind of like a moment where it's like, oh, wow. Like, first of all, you can just see the improvement over time of the models. And two, it can do all these tasks where just would not be able. You would not expected AI to be able to do all these tasks at once, but it can. It can do them very well. And I think that was like, a very visceral moment of like, okay, wow, the models are getting a lot better, and they're becoming very generalized, you know, like, they can do all these things. Like, clearly the models were not trained on, like, our specific task, which is you're writing these procedures and writing these tests, but they're still good at it.

[C]

And also to your other question of how, you know, how did we come up with all of this and how did the product improve? Every single thing that Jesse just talked about was the result of four deployed people doing things and us figuring out how to productize it, right? So, for instance, we realized that, hey, when we go into a new customer, we need to spend all this time writing up the aops manually. And we're like, wow, this is quite a lot of time. How do we productize this? And we built that into Duet. And then the second part, which we called Duet Autopilot, was once we built Duet, you know, people were using Duet to write things up, and then we're like, oh, wow, there's still a lot of time that goes into iterating upon the agent, right? Once it goes live, like reviewing conversations, figuring out how to improve it, and we're like, great, let's prioritize that. As do I autopilot it. 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, oh, it's taken a lot of forward deployed engineering work to write all these things in code. Wow. Wouldn't it be so much easier and efficient if we could productize it by writing it in plain text, Right? So the way we think about like product improvements or deployed engineering investment, everything is built around what can we productize from forward deployed work so that engineers and any kind of customer facing resources on our team don't need to be kind of as heavily involved.

[D]

Can I ask you kind of a blunt question on this line of thinking? So I know we've already Talked about why OpenAI anthropic won't be the last startups and you talked about why there's room to have much more specific use cases and specific companies. But you know, you've also got had like, oh shit moments where you're like, these labs are getting so much better and the models are getting so much better. And so long term, let's say like 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? And like, why does decagon like 10 years from now still have a right to exist?

[C]

I think in the short term, actually it is the ability to work with enterprise resources. And what I mean by this is that the capability of models today is far greater than they are being used for within the enterprise, right? By which 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, right? Like that's practically not how these things work. So to make models like this deployable within the enterprise, right? Like let's assume that every model is like just perfect and makes no mistakes. But to make something like this deployable within the enterprise, you need to say, okay, I need a way to be able to tell the model what it can and cannot do and make sure that it cannot do anything like catastrophically wrong. Then I need a way to make sure that, you know, hundreds of people within the enterprise can collaborate to make sure that the agent is behaving as expected in the use cases in which they are experts, then I need a way to be able to test this model and make sure that it doesn't cross any like regulatory lines that I have and test it, make sure it works well. Then I need a way to, you know, look over the, you know, millions of conversations that happen for me to extract insights for the rest of my teams. Right. So there's a lot of just infrastructure and software that you need to build around these models to make them deployable within an enterprise, to make them be 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. Now once that gets commoditized because the agents can build that on the fly. That I don't know and we'll figure out in three years from now.

[B]

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 you know, mid market newly IPO companies. I'm talking about some of the largest companies in the world. And I think this is particularly interesting because you, you both are very, very technical but also go to market animals. So I want to talk a little bit about that. But you know, it just feels like you've turned what maybe started as feeling more like a David and Goliath with multiple Goliaths market dynamic to really a two 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 have studied application software for over a decade, the sales cycles are crazy fast. I mean I'm sure you guys with urgency want them to be faster but like usually you don't sell contracts that big to enterprises that big. Right. That takes two years sometimes. So maybe just share a little bit more on this is a long question but like 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?

[A]

Yeah, I mean we are, we have a lot of respect for Sierra and also just you know, other folks in the space generally the big platforms like they all the platforms themselves move a bit slower. But I think that we've, we met a lot of those teams. They're very competent teams. They're optimizing for a lot of different things at once. Decagon versus Sierra. I mean, our most recent customer actually turned off of Sierra to come to decagon. And sort of the reasoning when we asked them was it kind of goes back to this like deployment model. It's like, you know, when they worked with Sierra, it was mostly fdes and it just felt like a black box where, you know, the FDEs were good, but they had to go through the FDEs for everything. So to build new journeys or to even get like a deeper understanding of what was happening in the conversations and then over time that kind of just create a lot of drag on how quickly they could move. Right. So in the initial deployment that was good. But then over time maybe the FDEs were staffed to other things and it just took them a while to get insight into what was happening and then build out new journeys. Right. So over the course of the year they maybe built out, I think they said three. And so the reason they came to us is because they had that frustration and they wanted to kind of have a different model where it was a lot more productized. Right back to us being like 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, it is like in service of helping them build a product that they can use themselves and iterate really fast and kind of have everything in their control. Right. So we like to call this like a glass box approach instead of a black box. Within basically a month, they spun up seven new journeys on Deckagon.

[C]

Wow.

[A]

Mostly.

[B]

And it had taken a year to get three.

[C]

Yeah.

[B]

Okay.

[A]

Interesting was here. So it's just kind of the speed of iteration. Some teams will really like this, like, hey, we have control of it. Our teams, especially our non technical people can come in and do things and they understand what's happening in the conversations. And maybe there's other teams out there that actually do like the like, hey, you guys do everything for us and that approach. But that's kind of the difference in their approaches. And that's why we've been, I would say, having a lot of success there and then zooming out, just selling to the enterprise. Yeah, I mean this is something that, you know, Ashman and I have never sold to an enterprise before. And I think it just so happens that both of us find sales exciting. And the enterprise, it was kind of a quick learning curve for us. So I don't think, I think a lot of it honestly came kind of naturally, just because our space is so hot and like generally in these conversations we're not really having to convince people to invest in this space. It's more of hey, we're the right approach for you, so partner with us. And yeah, with the enterprises it's really just about navigating the orgs and really having empathy for what they value and what they're afraid of. So yeah, I mean we just back to being sales led. Right. We always from the beginning 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, this product driven philosophy, like we don't want to just be dreaming up random products to build. So we always had that DNA. And then in the early days we were just, yeah, pushing really hard and I think, I also want to say I think we got kind of blessed with a really strong early sales team and we have a lot of really talented people in that group and that helped us really get leverage. As we were talking to, you know, the big enterprises, some of whom cold

[D]

applied to you guys in the early days. I remember.

[A]

Yes, yeah, yeah, Cold applied because I

[D]

think they were working in the space already and they were seeing from afar like what Decagon was starting to do.

[A]

Yeah, so some of them had like non traditional sales backgrounds, you know, so they had non traditional sales backgrounds. They're coming into sales. The other profile we had a lot of in the early days was like Ivy League athletes, I guess. And those profiles were kind of a good foundation for the group and 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.

[C]

The other thing I think that helped us a lot to your earlier point about how did you get some of these large deals closed so quickly was I think 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. Because 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? Right. And 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 sort of mapping out that part of the journey very well, so that when we walk in to 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 you, this is what your model risk process is likely to be. This is how your testing process should look like. This is how we should do the initial rollout. This is how we should catch any issues that come up and how we're going to fix them and how we'll ensure that they don't happen again. So the product and technology part of what we sell is important, but for these large companies, equally important is usually helping them think through the process to actually get this deployed and at scale. Because I think that is something that often gets overlooked by tech companies selling into enterprise.

[B]

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. Right, that they're going with Decagon is they want to make a bet on you guys. They're, 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 because it's not sort of like a oh, everything's going to be the same in, you know, a year or even six months type of market. 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?

[A]

I probably spend most of my time like 80% maybe.

[D]

Yep.

[A]

Okay. And yeah, I think a lot of it is just pushing speed. So some of it is like, hey, like as one of the founders, you just have to be in calls and like, you know, people want to meet the founders. But also it's just, how can I be the sort of the main force that's pushing our team to go faster, but also just like the partnership to move faster. One of the things with that is like, you know, now we work, work with several of the largest banks in the world and Airlines and telcos and no matter how fast you go, those are still massive organizations and it will take time. And so one of the things that we really try to do is kind of take the project and piecemeal it. So we're not just deploying across every surface area, every use case at once. That's really just pick one or two of the top use cases and just get a win there, there. And I would say that's been helpful.

[D]

Right.

[A]

If you navigate like a big bank, like it's not going to be like a quick, like, you know, you just close a big deal.

[C]

Right.

[A]

At least for us. It's not me. Some people can do it, but it's. Yeah, it's still a lot of effort and it's. It takes time. And so you have to figure out ways to, you know, design things from a process perspective and an Oracle perspective and a product perspective as well that like, just keep shortening that and like finding clever tactics. And that kind of takes founder involvement. You wouldn't really expect a sales team to just constantly be coming up with new configurations there because they're not responsible for the product, they're not responsible for the end to end process that the company runs. So having the founder involved there is very important, I would say. And then the salespeople, their job is to kind of execute on the sales side, like build champions and navigate the org and so on.

[C]

The other reason to also spend a ton of time with both sales prospects and existing customers is also because the market is changing so quickly. Being able to really quickly understand what are the things that we are not doing today that we should be doing very quickly. Right. Because model capabilities are changing all the time. As models roll out, people are seeing other things that happen and they're like, oh, wow, this was really cool. And like I'm seeing this here and you guys aren't doing that as well. So being able to like stay really, really close to that feedback loop, because that's something we never want to, never want to let go of.

[D]

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

[C]

So when we launched, the original set of use cases that we sold were in customer support. And the reason was because, one, that was one of the biggest challenges that a lot of our early customers were facing, and two, that was where the capabilities of the models ended at the time. Right. That is pretty much the limit of what they were capable of doing. Now, however, as models have gotten better and our customers have realized, well, why would I have one set of models that just learns about my customers when they have another when they have a problem, and something else when they come to me to buy something? Right. And so we had a customer that we originally went live with them for customer support, and then they realized they were like, well, you know a lot about our product now. You know about the capabilities that it has, because you need to do that for customer support. You know how we like talking to our customers and our brand. Can you help us with inbound sales? Right. 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. So we are able to now proactively reach out to them once we start seeing any kind of issues on that customer's account. Because ultimately, at the end of the day, the thing that we built, and we kind of built this intentionally from the start, was not an agent that does customer support well, but rather an agent that follows business process well.

[B]

Right.

[C]

And executing on operational workflows, doing sales lead qualifications, answering customer support questions at the end of the day is just an agent following a business process. And we kind of built it flexibly enough to kind of do all these things, because we realized that, hey, at a certain point, the models are going to get better, and they have.

[D]

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

[C]

It is specifically the ability to follow instructions well. Right. So when you had models, you know, let's say a few years ago, you'd have to give it very, very tight guidance, very specific instructions that you didn't want it to deviate from. And as the models got smarter, you could kind of give it 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 kind of fill in any missing gaps. Right? Because for, again, 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 qualifications, you kind of Want to ask open ended discovery questions, the conversation is going to kind of bob and weave. And so you need the model to kind of, kind of fill in with reasonable things. So that's specifically kind of what the model's got better at over the years.

[A]

Yeah. I think if you think about what is the 12 month product roadmap because things are moving so fast, the real answer to that is we'll kind of see how it evolves and we obviously know what we're working on now. But I think realistically in today's AI world, it's very difficult to have a 12 month roadmap to a T. You maybe know, have some themes of what you want to build, but ideally if you have those things, you just build it right now because it's so fast to build things now. So I would say that is one element. But then the sort of long term vision is still very clear to us now. Right. Which is we use the term concierge, but really it just means like, hey, an AI agent should just be the front door of your business, of your brand. And every interaction, whether it's like reactive or proactive with a customer, should be handled by, by AI. And we've already seen that AI is very good at that. Right. Customer service is a huge pillar of that where it's all these inbound interactions. But why not also be able to do all these other things? So over time, again, we're not trying to figure out on our own what these things are. We kind of have now have a lot of customers that will give us signal on the things that they care about and those will be the things that we build.

[B]

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

[C]

Hiring.

[B]

Got it. So it's less on the AI side. It's actually like people, we are voracious

[C]

consumers of tokens, but we would always love more gay people. I think there's so much to build these days.

[D]

Yeah, it's, you know, and why can't you hire people, AI agents to do the things that you're doing.

[C]

Yeah, we are voracious consumers of tokens, really. Like our token bills are very, very large. But you know, there are still things. I don't quite yet think we're at the point where we can have the AI agents make decisions on what to build and kind of have that the taste of is this done yet? Right. So 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, things like that.

[D]

So the model's improving, have they? Since like you found it three years ago, has it changed your hiring needs? Needs at all? Because a lot of people are like, oh, you can build like one person unicorns, you know, like, yeah, you know,

[C]

I think, you know, this argument does get tossed around a lot. But I think the, an easy counter example to this is all the AI coding startups are hiring like crazy. You know, they're like the most sophisticated users, presumably these models, and they are hiring like crazy. I think the reason is just because everybody has access to these tools and so if our competitors are going to use them and build more things, we need to build more things. Right. If somebody else said, oh, here's our roadmap and now we can get through it in, you know, a third of the time, and then they just stop hiring, we would just take that to mean, wow, we can get through it in a third of the time. Great, let's build three times as much stuff. And turns out everybody, you know, does the same calculus. So everybody both needs to keep hiring more and shifts more. So it is great for consumers of these models, but I don't think it has materially changed our hiring plan.

[B]

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

[A]

Yeah, there's still stuff that we're waiting for. Right. Like voice to voice models is an interesting frontier that there's still research happening on, you know, the getting smaller models to be smarter, smarter out of the box.

[C]

Right.

[A]

So there's, there are going to be still developments that we are watching closely that we care about, but from a business perspective it's less on the model side and more on the. Just like, can you build the company fast?

[B]

Yeah, actually maybe. Since we're on the topic of hiring and you know, I feel like grind slop has become this theme on X and it's so funny, because is, you know, as a. As a vc, like, I'll admit, you know, when I. I mean, you guys are famously in the office six, seven days a week. I hope this doesn't get marked as grind slop now. But, you know, I think constantly hustling for your teams and your customers, and it's so funny to see that kind of turned on its head. And so I'm just curious, what is your. What are your thoughts on the narrative out there? And like, grind slop is such a general term, but like. Like, you know, you guys grind, but there's also a lot of camaraderie and excitement in the office. So, like, just, you know, say more about that and, like, how you're building the culture.

[A]

Yeah, I mean, grind slop's a funny term. We. So we have never posted grind slop because we kind of view that, like, working hard is just like. I don't. I don't think people are, like, working hard to grind. It's just like, no, there's a lot of stuff to do. Like, we kind of. People spend time there mostly because, like, hey, it's, you know, this is like a fun time of our life. Like, we want to take advantage of our talent and sort of potential so that it's not wasted.

[C]

I think that's.

[A]

That's the main reason. And it's a very sort of like, it's like, many orders from, like, the main goal, which is like, can you build a good product and can you win in a space? But it's like one of the effects of that is that people work harder. And even from the beginning, like, we, yes, we have an office culture, but, like, we're never mandating people to come in on the weekends. We don't really, really care how long they're. They are in the office. It's just people are in the office just so that, like, we can maximize communication. And that's how we view it. Um, like, I don't view ourselves as, like, you know, abnormally grindy or abnormally ambitious. I think, like, we're. I think we just, like, I have a lot of ambitious people around me, like Ashwin and all these people, so it kind of just become normal. And, like, everyone works hard, so it's just kind of like normal. Um, so I don't think it's like something that's. We view as something, like, super special.

[C]

And we kind of also view a lot of what we do very much as a team sport. Right. Where we very rarely have lines between our orgs. In that you will very commonly see engineers on early stage sales calls, you will see salespeople debugging parts of the product. You will see our APM team in absolutely both ends of the spectrum. And so I think being able to have teams that are so kind of disparate from like a function perspective, all working together kind of one kind of needs people in the office because everybody's kind of jamming on ideas together. But two, it also makes it fun in a way because, you know, everyone is like working together towards some very specific outcome. Right. It's either getting this, building this thing for this customer in time for the deal to close or launching this new thing. And because it's so many different teams working together, it's kind of a, it's kind of a. We're all in this together to cross the line. Yeah.

[D]

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

[C]

I don't know.

[A]

I mean, I don't think it's a solved problem for us. Like we're constantly working on it and like every single time the company gets to the next stage, there's new things we have to institute to just make sure that everyone understands the culture. And there's very high accountability and there is pressure because there should be. And so that's something that we're constantly adding on because in the first a hundred people it doesn't really matter because everyone kind of knows each other. But as you grow, people might not have. No one's communicated the vision to them or communicated the culture to them. Yeah, I know, like Ben was talking to us about the A16Z culture, right. It's like how it's very like action oriented and you can't just like put, put like fluffy stuff on there. And so, yeah, it's all these things that we're trying to do a better job of as we grow.

[C]

The other thing is also we, we bring everybody that we hire out to San Francisco for a couple weeks when they start. So they're kind of immersed in the kind of the original kind of soup of culture. And then for every new office, right at this point, New York and London, all these offices are big enough that they have the original decagon culture there anyway. But for brand new offices, we actually have people from one of these hubs go out and spend a few months there really, until the office becomes big enough and has its own kind of of culture so that it doesn't kind of become too different from what kind of the original docagon culture was.

[B]

Actually on the topic of international, we're so we brought on Raghu Ragnaram last year, obviously former CEO of VMware. And in addition to investing, he's helping us build out a ton of our international capabilities. And I think one of the things that we've seen is that our AI companies are just getting pulled internationally way earlier. Like for you to have an Australia office, it seems premature except for the fact that you have customer pull. Your scale is quite large for, you know, how long ago you were founded. But maybe say more about that. Like does that translate? Like does your product translate well to these other geos? Are there more enterprise concerns or fewer or is it kind of just comparable to the US market?

[A]

Yeah, I think there's two trends. One is that that AI is just such a phenomenon that every buyer out there has tried ChatGPT or whatever. And so there is a lot of just top down pressure from boards and C suites to just get moving on something. And 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 let's do customer service because those are the obvious ones. And so there is a lot of pull to your point. And then the other trend is that the language is a lot easier with AI. So in the past maybe a blocker would be oh, my language just doesn't work or my app just doesn't work in German or pick your language. Right. But now it's a lot easier to adapt your app. So I think for those reasons international has been a lot faster. I think at the same time, right. Like we also want to make sure that we're not getting spread too thin. And so it's kind of this balance where it's very unclear what the perfect answer is. But we've kind of made a determination of which markets we're okay with really investing in and if we're going to invest, we're going to really invest. And generally those markets are ones where we already just naturally picked up some customers out of the US office or something and then now it's time to deploy people. Because yeah, even though there are these trends that make it easier to go internationally, there's also so other things that you don't really think about. Right. Like you have to have data residency. There's all these things where there's like local Competitors which are just know the market a lot better and so you have to navigate that well.

[B]

Yeah, absolutely.

[D]

Do you think there is a, like a space for like local competitors to the large categories that we know about?

[A]

I mean, there is space for them. I think the question is like long term, is there consolidation? And you could say that for both geographies, but also verticals and then also market segments. So there are going to be people that find their niche in different places. Our view, the reason why we've kind of built so horizontally is that we believe that in our space, the winners are going to be horizontal. There's just not that much that is super verticalized where you could see a pure vertical solution surviving. And, and historically that's just been true in our space. Right. Like Salesforce, very horizontal. Zendesk, very horizontal. Like all these solutions are very horizontal because you just gain more from having that scale and having a very robust and deep product than you do from having very vertical specific features. And over time, we're also going to build vertical features into it. But our view is that from a vertical and sort of market point of view, there will be consolidation.

[D]

Hmm.

[B]

Just sort of on related to consolidation, but maybe not just geographic consolidation. I'm curious if AI concierge becomes really the interface between the business and its customers. Do you see what, like how does CRM and all of these, you know, sort of traditional data, very important systems of record, right. For the end customer. How do those, those evolve in this new world? And do you see any consolidation there in terms of your own role?

[C]

Yeah, I don't, I don't think it's necessarily an either or. Right. Because ultimately what we're, what we're doing here is trying to democratize access or availability of these concierges. Right. Which is if you were going to a business where you were spending a hundred thousand dollars a year, you would get the most personalized treatment. They would know exactly who you are, what your preferences were. They want to help you, you know, shop, for instance, they'll shut the whole store down for you. Actually, I don't know if they do that for 100,000, but you get the general.

[D]

You've never tried that before.

[C]

However, if you're at a business where you're spending $10, they, 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 that. 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 is economical, and they'd want to do that. Now to the point of, does that mean CRMs go away? I mean, my answer is no, because. Because if you have a company today where your concierge is a human being, they still write your info in a CRM so they can track it for later. And I think when we have these AI agents, they will need somewhere to put that information. So I don't necessarily think those kind of auxiliary pieces of software go away, because for us, as we're building these conciergers, our goal really is, is how do we create that great experience? We will still need places to put that data somewhere. Right? Yeah.

[A]

I actually think CRMs could do quite well. They'll be slightly different in the sense of 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, et cetera. But in the future, maybe the agents are just using the interfaces, and you don't even have graphical interfaces or whatever. And so the CRMs are still very valuable because they hold the source of truth. And then the agents, they're just kind of getting pinged a lot more because the agents are using them. So that is one possible world that's kind of bullish on CRMs. And for us personally, so far with Zekeon, there's like, 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.

[C]

Yeah.

[B]

Okay, so SaaS is not dead.

[C]

Cool.

[D]

Maybe. 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 just figure out how to, you know, make your own life more productive and effective. And, Austin, it sounds like you've done something kind of interesting.

[C]

Yeah, you know, I think the models have gotten very smart over the last several years, and, you know, the two of us will often use it to brainstorm ideas. Right. 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 do, is business context. Right. There's a lot of context for every idea around. Okay. The constraints that we have, the goals that we're going for, and things like that, that is difficult to re explain to the agents every time. And so I actually spent a while building agents for myself to capture all the business context. Well, so it just kind of Looks over my shoulder all the time and is constantly compiling context on, oh, 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. The problems here are the current challenges that we have so that 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? And now it's able to automatically reasonable. Well, we had two candidates that were very similar. And, you know, these candidates had these kind of drawbacks or skills that they didn't have. And so if we hire this person, it's going to be another person that has those, you know, kind of exact same things. So we need someone complimentary. So this is probably not the best person to have, have or, you know, in this deal. We're barreling down a very similar path because, you know, we didn't validate these things early enough. So this time we should validate them slightly earlier. So it's really all about how do you capture context? Well, because then, you know, my job is making decisions with lots of context. So if I can outsource that more and more to a model, maybe I can put myself on a job quicker.

[D]

Sounds like you created Jesse.

[A]

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

[D]

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

[A]

Yeah. So, like us working together, I think the reason it was so much easier is that we could, you know, iterate on things much faster. You kind of just talk something out and, yeah, now you talk to Fable or whatever. It's like, it's pretty good, honestly. Seem like very original because in the past it was just like they just kind of are kind of sycophants. Right. Or they 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.

[C]

I actually, for a while, Mark at one point had posted the Prof. That he used for Claude, where it's like, you know, disagree with me, be very direct, things like that. So I actually used that for a while, and it was great. The funny story on this was I really enjoyed it because it would agree with me very aggressively. It would disagree with me very aggressively. And I took it to my wife and I was like, ah, this is great. You should use it. She put it on and then, you know, a day later she was like, wow, Claude was being so mean to me all day. I had to turn it off. Like, it just kept telling me it was disagreeing with me so aggressively.

[B]

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 is a strong word that Brian Chesky just went through. And I want to bring it up because you both have grown your profile a lot over these last few years. And, you know, I sort of mentioned Jess, you had these pieces that were just hitting the zeitgeist of the discussion that everyone wanted to have and came in with a very differentiated take. And, you know, that's the kind of stuff that we see exactly hit on. You know, you're hitting the conversation right at the end. You know, write message right time, unique message right time. Do you use AI for writing? And separately, this is more of a meta question, but how important is X and like the sentiment on X to you?

[A]

So, yeah, for most of our early days, it was mostly LinkedIn because with the reasoning of like, hey, our customers are on LinkedIn, you know, we're not going to get someone seeing us on Twitter and then coming as a customer, probably. But I think the, the sort of learning we had with X is. Or at least I was kind of reflecting on it, X is kind of like the timeline that people talk about. And most of that timeline is not really about your company. If you're very just promoting yourself on X, it's going to get no traction whatsoever.

[B]

Totally.

[A]

But it is sort of like a single timeline that everyone reads. So it kind of like mind controls everyone to be thinking about the same thing.

[D]

Thing. Yes.

[A]

And that's where it's valuable to have some say in it. And who was I listening to? There's like, there's this guy like Jeremy Giffon or something who's on Patrick OSI's podcast, who I like, and he was like, doing. He like made some claim about how, like, you know, it used to be that like the, the, the big status symbols in the world is like, everyone wants to be a billionaire because, like, he calls it like the priest class or whatever. So it's like billionaires are the priest class. But nowadays, actually, it's when people become billionaires now, they want to become ex influencers because those people hold the real power because they can influence what the whole world's thinking about. So that's like one reason to have some presence on X, I suppose. And when we now, when I post on X. I don't really post about like Dekuon specifically. It's more about our thoughts on what is happening. So I think that's, that's like a good, good way to do it and.

[D]

But it is great to write it all yourself, right?

[A]

Yeah. I mean, AI is good for sort of helping you brainstorm like what topics to write about. I think that's, that's pretty good. But I think that was like, that's kind of like learning that like LinkedIn and X work very differently. You can't just like come up with something cool and like post the same thing on both because, like very few things things like do well on both.

[B]

Yeah.

[A]

So like LinkedIn's really good for, you know, classic stuff. You're making announcements and talking about your product and you know, fundraise or whatever. I guess you can do fundraising on X as well. But X is a lot more about kind of like placing yourself on top of that single timeline that everyone's on.

[B]

And is that so is it too much of a simple, you know, simplification to say X for hiring especially, you know, AI, research talent, et cetera, maybe ecosystem as well and then LinkedIn more for enterprise customers or are you actually seeing enterprise CIOs pay attention to X? Attribution's hard, obviously.

[A]

Yeah, it's hard because, you know, I think you could say like, oh, well, you know, I made a post on X and then, you know, the people on the all in podcast were talking about it and like CIO is definitely. Yes, I saw that. It's like a, like indirectly. I'm sure we got like some eyeballs from CIOs. Like, is the CIO themselves like scrolling X all day? Maybe not, but if you are part of that major timeline, then you have there's always these like secondary effects and then. And then like reporters will reach out to like from like mainstream media. And then if they write about you, then like auction was on the New York Times recently. You know, it's like if they write about you, then those for sure surrogate

[C]

eyeballs you were that just open source stuff.

[B]

Oh, Kimberly's only on X, so you

[D]

didn't put the next card.

[B]

I guess maybe a last question would be just since we touched on like hot button x topics 1 and this is kind of a serious one actually. But it sort of re entered the narrative, I think with, you know, the anthropic video and it's just sort of maybe never left the narrative. But it's on this concept as progress gets better around Jobs and the messaging around that. It's a sensitive topic, obviously, but it's interesting because I really think customer support was maybe the first end to end use case where you could really take an entire job. Sorry, do an entire job. I should say take is the wrong word versus coding was always, you know, pair programming to start with. How has that. You know, we, we sort of joked before, but I, you know, we weren't really joking that AI is actually creating jobs. I'm curious, how do you turn that narrative on its head that folks are just losing their jobs, right? Like, do you see the up leveling of folks with AI where, you know, maybe they were doing this job and now they're doing something else?

[C]

Yeah, I mean, we, we see this all the time. Because if you recall earlier on when we were talking about, hey, what are we truly doing? We found that for a lot of our customers, there's actually just more demand for things like customer support than there's supply, right? Where companies realize that they're like, okay, if our cost of doing customer support drops by, by 30%. Most of them are not just immediately saying, okay, now what I will do is, you know, let go of 60% of my team. They're saying, okay, 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, you know, they don't turn off as much, so that they activate sooner. Things like that. You know, we had a customer in the early days, they, and this was, you know, probably two and a half years ago at this point where they said, you know, our ticket volume, you know, the amount of customer support inquiries that we get per month was, I think, I think it was like 50,000amonth or something. Based on, you know, the existing surfaces that they had once they started using us, they said, wow, turns out our customers have a lot of problems. They said, let us make support more easily access accessible, right? So instead of it just being in one part, like buried within a support panel, you're like, let's put support on every page and let's make it more prominent in places where people are more likely to get stuck. Let's allow immediate support for even free users rather than only paying users, right? So because of this kind of, there's more kind of latent demand for support than there is supply. So automating things doesn't necessarily result in just kind of people laying off their entire teams.

[B]

That may be the best example of Jevons paradox in real life. That I've heard.

[D]

So it's exciting.

[A]

Yeah, I think it's like AI will kill jobs, but not careers in a way, because like those jobs that are being done currently should not be done by humans. Like, they're very mundane and menial. It's like, it's like a super high volume use case and people are just like kind of picking out the phone. It's like, okay, let me click here, click here. And like, okay, here's the answer.

[B]

Right?

[A]

And that should be done by AI. But there is actually a near infinite amount of things that people could be doing to make their customers happier and take care of them more. And so people will end up doing those things and more and more of the mundane, repeatable things will get eaten up by AI. So that's what we think will happen.

[D]

Jesse, I think on a podcast, maybe Patrick o' Shaughan has these podcasts. A couple months ago you had mentioned that even your customers, when They've been using BPOs for customer support instead, you haven't actually seen like layoffs at the bpo. It just turns out that those employees have gone and done done other things instead. Is that still true?

[A]

Oh, I mean, it really depends on the situation. So 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 are not in cost cutting mode whatsoever. And their goal is to either their business is growing so quickly that they don't want to scale their operations along with their growth. And so with Decagon, they can kind of like keep it flat or whatnot or it's. Yeah, actually we still need people, but now there's all these other things they could be doing and it could be more revenue generating things. You know, that's like a big area for us even. It's like as the AI matures, you first start with these cost cutting use cases, because those are easy. But then like revenue generating use cases should also be able to be done through this conversational interface. So. So yeah, it really depends on the customer, but we definitely have customers that have made massive changes.

[B]

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

[C]

Thanks for having us.

[E]

Thanks for listening to this episode of the A16Z podcast. If you like this episode, be sure to like, comment and subscribe. Leave us a rating or review and share it with your friends and family. For more episodes, go to YouTube, Apple Podcasts, and Spotify. Follow us on X1 6Z and subscribe to our [e-mail] thanks again for listening, and I'll see you in the next episode. As a reminder, the content here is for informational purposes only, should not be taken as legal, business, tax, or investment advice, or be used to evaluate any investment or security, and is not directed at any investors or potential investors in any A16Z fund. Please note that A16Z and its affiliates may also maintain investments in the companies discussed in this podcast. For more details, including a link to our investments, please see a16z.com disclosures.

[C]

Sam.