# The AI founder advice you won’t hear on X | Ashwin Sreenivas (Co-Founder at Decagon)

Markdown copy of https://realalpha.app/v/_FmwqPzqkjY/ on Real Alpha, the best minutes from long interviews with the people building AI. Cite and link the page, not this copy.

Ashwin Sreenivas says AI founders should find urgent customer pain, then move fast to capture the market.

- Show: Knuckle Up with Nakul
- Hosts: [Nakul Mandan](https://realalpha.app/people/nakul-mandan/)
- Guest: [Ashwin Sreenivas](https://realalpha.app/builders/ashwin-sreenivas/) is cofounder and CTO of Decagon.
- Published: May 19, 2026
- Length: 1 h 14 m

## The best minutes

- [2:13](https://realalpha.app/v/_FmwqPzqkjY/?t=133) [Customer pain should shape the product before strategy](https://realalpha.app/s/customer-pain-should-shape-the-product-before-strategy/) (4 min)
- [13:09](https://realalpha.app/v/_FmwqPzqkjY/?t=789) [Decagon accepts coordination costs to preserve speed](https://realalpha.app/s/decagon-accepts-coordination-costs-to-preserve-speed/) (4 min)
- [40:01](https://realalpha.app/v/_FmwqPzqkjY/?t=2401) [Most AI companies need product-minded FDEs](https://realalpha.app/s/most-ai-companies-need-product-minded-fdes/) (3 min)

## Also worth watching

- [7:57](https://realalpha.app/v/_FmwqPzqkjY/?t=477) [Decagon brings engineers into customer sales and support](https://realalpha.app/s/decagon-brings-engineers-into-customer-sales-and-support/) (5 min)
- [25:52](https://realalpha.app/v/_FmwqPzqkjY/?t=1552) [Decagon uses bar raisers to protect its hiring bar](https://realalpha.app/s/decagon-uses-bar-raisers-to-protect-its-hiring-bar/) (3 min)
- [31:18](https://realalpha.app/v/_FmwqPzqkjY/?t=1878) [AI writes most code, but Decagon engineers remain accountable](https://realalpha.app/s/ai-writes-most-code-but-decagon-engineers-remain-accountable/) (4 min)
- [35:05](https://realalpha.app/v/_FmwqPzqkjY/?t=2105) [AI shifts engineers toward judgment and EPD leaders toward alignment](https://realalpha.app/s/ai-shifts-engineers-toward-judgment-and-epd-leaders-toward/) (5 min)
- [57:19](https://realalpha.app/v/_FmwqPzqkjY/?t=3439) [Decagon fine-tunes smaller models for specific customer tasks](https://realalpha.app/s/decagon-fine-tunes-smaller-models-for-specific-customer/) (3 min)

Skip the co-founder backstory, office routine, sales-workflow discussion, and the quickfire round.

## Full analysis: Ashwin Sreenivas says buyers first as host cites Decagon’s 450 staff

- The host said Decagon had 450 employees after three years.
- Sreenivas’s buyer-first account is credible as experience, not a universal playbook.
- For AI teams, test whether faster building yields reusable products without more rework.

Its 7 sections, what it means for you and what to watch are on [the page](https://realalpha.app/v/_FmwqPzqkjY/#analysis), free with an account:

- [2:58](https://realalpha.app/v/_FmwqPzqkjY/?t=178) Buyer pain gave Decagon its first strategy
- [12:21](https://realalpha.app/v/_FmwqPzqkjY/?t=741) Customer access keeps product decisions close
- [13:38](https://realalpha.app/v/_FmwqPzqkjY/?t=818) Speed shifts cost into coordination
- [15:31](https://realalpha.app/v/_FmwqPzqkjY/?t=931) Bespoke delivery buys learning before configuration
- [31:29](https://realalpha.app/v/_FmwqPzqkjY/?t=1889) AI writes code, but engineers own the release
- [40:15](https://realalpha.app/v/_FmwqPzqkjY/?t=2415) Product-minded FDEs should turn edge cases into product
- [1:01:00](https://realalpha.app/v/_FmwqPzqkjY/?t=3660) Sreenivas says hiring capacity worries him most

## Summary

Ashwin Sreenivas co-founded Decagon with Jesse Zhang in 2023; the company builds an AI customer concierge platform. Before Decagon, he worked at Palantir and founded Helia, which he says was sold to Scale.

Sreenivas says founders should start with repeated buyer pain and willingness to pay, rather than a long-term plan; Decagon found its customer support focus through conversations with enterprise buyers. He says speed is worth some coordination costs, while customer access, clear ownership and hiring standards help the company scale. He expects AI to change engineering and product work: agents write most of Decagon’s code, but engineers remain accountable for it, and customer-facing engineers should turn user needs into general product capabilities. Sreenivas argues that enterprise software around models, customer understanding and specialized in-house models can differentiate Decagon, while hiring capacity and quality are bigger concerns for him than competition from model labs.

### Minute by minute

- [2:00](https://realalpha.app/v/_FmwqPzqkjY/?t=120) **Customer pain beats long-range plans.** Sreenivas says he and Jesse avoided a 10-year plan and first looked for a recurring pain buyers would pay to solve. Conversations with heads of customer success, customer service and operations at fast-growing tech companies surfaced customer support as a costly, labor-intensive problem. He says changing AI capabilities make it important to revisit what can be solved every six months.
- [7:57](https://realalpha.app/v/_FmwqPzqkjY/?t=477) **Customer contact shapes culture.** Sreenivas says Decagon’s values include building what customers want and treating work as a team sport. He described salespeople, product managers and engineers celebrating deals together, and said engineers join customer calls or customer Slack channels so feedback reaches the people building the product.
- [13:09](https://realalpha.app/v/_FmwqPzqkjY/?t=789) **Speed takes precedence over coordination.** Sreenivas says Decagon tries to maintain quality but accepts coordination costs, including teams building similar things, because AI has shortened development cycles. He says the company initially built bespoke solutions for enterprise customers, then added configuration options and agents to make customization scalable.
- [17:43](https://realalpha.app/v/_FmwqPzqkjY/?t=1063) **Office time lowers coordination costs.** Sreenivas says Decagon moved from six office days a week when it was small to five for most employees; he and Jesse still go in on Sundays. He says proximity helps teams coordinate as they ship quickly. He and Zhang share similar goals and trust each other’s competence, with Zhang focused more on go-to-market and Sreenivas on EPD and recruiting.
- [23:24](https://realalpha.app/v/_FmwqPzqkjY/?t=1404) **The founders delayed their first hires.** Sreenivas says Decagon reached $1 million in ARR with two founders and no employees. The founders delayed hiring because revenue grew faster than expected, recruiting took time, and they were busy building for and onboarding customers. He says they worked seven days a week during the first year and could each sell, onboard customers and write code.
- [25:52](https://realalpha.app/v/_FmwqPzqkjY/?t=1552) **Bar raisers protect recruiting standards.** As Decagon grew to 450 employees in three years, Sreenivas says he and Zhang stayed involved in reviewing hiring packets. About 20 to 25 internal bar raisers conduct final interviews, and candidates need a clear strength rather than merely receiving threes across the company’s one-to-four ratings. He says AI coding is expected in EPD, while other teams can learn relevant tools on the job.
- [31:18](https://realalpha.app/v/_FmwqPzqkjY/?t=1878) **AI writes most code, engineers own it.** Sreenivas says AI coding tools now write most of Decagon’s code, but engineers must understand and take responsibility for what they ship. The company supports that work with AI-ready documentation, code structure, testing and review. He says security has remained tightly managed through coding practices, internal reviews and regular external penetration tests.
- [35:05](https://realalpha.app/v/_FmwqPzqkjY/?t=2105) **Engineers iterate; leaders set targets.** Sreenivas says engineers increasingly work from less complete product requirements, try options quickly and use their judgment to shape the result. He says EPD leaders need to define the problems, ownership and interfaces clearly, without prescribing every implementation detail. Teams can test many approaches, but should present customers with a simple solution.
- [39:53](https://realalpha.app/v/_FmwqPzqkjY/?t=2393) **FDEs can serve two different roles.** Sreenivas distinguishes bespoke integration work from a second FDE role that discovers product gaps alongside users. He says most AI companies need the second type: a product engineer who can understand a user’s problem, identify what generalizes and build it into the product. Decagon uses configurable integrations and coding agents to reduce bespoke last-mile work.
- [44:48](https://realalpha.app/v/_FmwqPzqkjY/?t=2688) **AI speeds sales and implementation.** Sreenivas expects AI to make SDRs five to ten times more productive for now, while AEs still need to understand buyer pain and demonstrate product fit. AI helps with prospecting, meeting preparation and sales administration. Decagon also uses Duet, an agent built on its own product, to help customers and its post-sales team build agents.
- [49:06](https://realalpha.app/v/_FmwqPzqkjY/?t=2946) **Humans retain customer and people work.** Sreenivas expects customer discovery to remain human-to-human for a while, even if agents eventually listen to calls, prioritize features, write code, review PRs and ship. He says interpersonal issues still require one-on-one conversations, though AI can summarize account signals for executives. For new founders, he recommends treating an AI-ready engineering workflow as a product.
- [53:29](https://realalpha.app/v/_FmwqPzqkjY/?t=3209) **Enterprise software can defend AI products.** Sreenivas says enterprise AI needs software for governance, collaboration, analytics, quality checks and integrations beyond the core model. He argues that customer knowledge and technical execution also matter because enterprise buyers can distinguish a product that works well from one that is merely close. He says about 90% of Decagon’s model traffic runs through models it builds in-house, tuned for its specific use cases.
- [1:00:39](https://realalpha.app/v/_FmwqPzqkjY/?t=3639) **Hiring capacity is a company risk.** Sreenivas says hiring is his main concern: Decagon could miss demand by hiring too slowly or damage itself by hiring too quickly. He and Zhang take Saturdays off and try to separate controllable causes from outcomes after losses. He says the key lesson from earlier startup experience remains to focus on what customers care about.
- [1:07:53](https://realalpha.app/v/_FmwqPzqkjY/?t=4073) **Fast-growing companies face internal fires.** Sreenivas says fast-growing companies routinely face internal problems, including bad hires and lost deals, and that his team tries to analyze setbacks rather than treat them as exceptional. He calls advice to hire many FDEs overrated unless they serve the product-engineering role, admires Ramp, uses Whisperflow and recommends books about the Wright brothers and Pixar’s culture. He says he now takes lingering doubts about candidates seriously. His advice to his earlier self is to move faster, hire faster and reach large customers sooner.

## Transcript

Knuckle Up with Nakul, hosted by Nakul Mandan, with Ashwin Sreenivas.

Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.

[0:00](https://realalpha.app/v/_FmwqPzqkjY/?t=0) I would wake up at five o'clock in the morning. The first hour, I would do history. For the next hour, I would do geography. And then I would take a 30-minute break. And then physics, chemistry. I would do math every day from five in the morning to like 8.30 at night. From like fourth grade to like 12th grade. And so in a way, I'm somewhat used to this. And now all of a sudden I get to come in here and there's a lot of people and I'm having fun. This is all of a sudden much easier. The pace of building has changed so quickly with AI. There isn't that much time for coordination. you have to give somewhere.

[0:30](https://realalpha.app/v/_FmwqPzqkjY/?t=30) And we gave for speed. Go faster, hire faster, build faster, get out to the biggest customers faster because the need is real, the market pull is real. You just need to go capture as much of it as quickly as you can. In the Decagon journey, have there been any hiccups where you guys felt today was rough? I guarantee you every fast-growing company, probably without a single exception, they've had a thousand fires internally. It's just normal. That's just how it is. Ashwin Sreenivas co-founded Decagon in 2023. Three years later, the company's AI customer concierge platform serves some of the largest companies on the planet, is valued at $4.5 billion, and is one of the fastest-growing startups of the AI era.

[1:12](https://realalpha.app/v/_FmwqPzqkjY/?t=72) An immigrant from India who started his career at Palantir and sold his last startup to scale AI, Ashwin is as customer-obsessed a founder as they come. In the first few months of Decagon, instead of theorizing about where AI was headed, he and Jesse focused singularly on talking to as many customers as possible and understanding their pain points and finding where willingness to pay was unmistakable. That obsession is how Decagon went from zero to one million dollars VRR with two founders and no employees. As a co-founder of Decagon, Ashwin is in a rare position. He has an AI native org and an AI native product that is growing super fast.

[1:55](https://realalpha.app/v/_FmwqPzqkjY/?t=115) What do culture and operations look like inside a fast-growing AI-native company like Decagon? We get into all of this and more today. Ashwin, welcome to the show. Yeah, thanks for having me. So I want to start with a quote of yours. A lot of first-time founders, us included at the time, spend a lot of time over-intellectualizing the problem. Being able to figure out what is the right three-year strategy at the start. it's really easy to fool yourself into thinking you're doing great, important work. Can you talk about how you and Jesse decided to work on this specific idea for Decagon? How did you go through the idea maze?

[2:35](https://realalpha.app/v/_FmwqPzqkjY/?t=155) Yeah, yeah. And first, thanks for having me. I'm really excited to be here. Early on in the company, we decided to explicitly avoid this thing that I think a lot of first-time founders do, which is thinking, okay, you know, what is our 10-year plan? How are we going to build the right set of modes to build our defensibility? Just because I think in the early days of the company, there is so much that is unknown that doing that well, I think is nearly impossible.

[2:58](https://realalpha.app/v/_FmwqPzqkjY/?t=178) **Ashwin Sreenivas:** So early on in the company, essentially what we did is we said, the only thing that matters is what do customers care about and what are they willing to pay for today? Because everything that

[3:07](https://realalpha.app/v/_FmwqPzqkjY/?t=187) comes is downstream of that. So in the early days of the company, all that we did was we said, hey, let's focus on a buyer and the problems that they have. And as an early stage company, the only thing that you're looking for is what is a common, unique pain amongst a specific set of buyers. And once you figure out the pain that you're trying to address, only then do you say, okay, now this is how I think I can solve this pain. This is the product that results from it. This is the go-to-market motion that results. So in the early days, the only thing that we focused on was who's the buyer that we want to serve and what is the specific pain point that we have. Ultimately, as we started talking to a lot of these buyers and specifically, we were looking at heads of customer success, heads of customer service, VPs of operations, right?

[3:52](https://realalpha.app/v/_FmwqPzqkjY/?t=232) Within fast growing tech companies, the number one issue that they all had was customer support, right? They kept coming back to us again and again saying, hey, we have all these problems, but the number one thing that I'm struggling with is customer support, right? Because number one, it's crucial to the company, right? Because this is the lifeblood of companies today. And two, it's very labor intensive and it's hard to manage. So that was kind of how we hit on the problem we wanted to solve. Did you not consider the top-down approach at all, like market sizing? A lot of founders come into it from what they've individually felt as a pain point in their last startup.

[4:28](https://realalpha.app/v/_FmwqPzqkjY/?t=268) They take a top-down approach of, hey, where is the world headed? This is where I'm excited. It seems like you guys were maniacal about finding customer pain point through that journey. Yeah. So no top-down approach at all in your journey with Decagon. No, not as much because I'm of the opinion that the markets that you serve honestly determine a lot of the outcome of the company. There are great markets to build companies in in periods of time and there are bad markets to build companies in in periods of time. And I wanted to ensure that I wasn't just going after what was a bad market. I think Mark and Reeson had a blog post that he wrote about, I think this was in the early 2000s or maybe the late 2000s, where he said, great market means bad founder, market wins.

[5:15](https://realalpha.app/v/_FmwqPzqkjY/?t=315) When bad markets mean great founders, market wins. And so we were very focused on making sure that we picked the right market and the right problem within the right market, which was ultimately this view that if you pick the right market, the market will pull the problem and product out of the founding team. Do you feel actually in today's times, even more so, this bottom-up approach is the only way it works because the world is changing so dramatically that if you're not too opinionated about where the world is going in three years, you're going to get killed by the market shifting sands? I would say, you know, having done a company now both ways, right? One which didn't work out quite as well and one which did. I think this advice holds all across time. I think the difference today is that so many markets are changing so quickly that opportunities that did not exist before are opening up. So I think the big difference today is just that things that were, you know, kind of completely off limits, markets that were completely captured by companies before and markets that just weren't accessible to software are just opening up.

[6:22](https://realalpha.app/v/_FmwqPzqkjY/?t=382) So it's worth kind of re-examining every single market from the ground up and saying, okay, what are the primary pains that the biggest buyer in this market has? And is there now a way to solve them? And given so much is changing now though, how do you stay true to what you decided as the product vision? Your own primary research with buyers is still true today. Are you and Jesse constantly revisiting product market fit? Yeah, I think this is actually extremely important for us to regularly think about. And the reason is because the technology is changing so quickly, something that was state of the art six months ago because of where the models were and things like that.

[7:03](https://realalpha.app/v/_FmwqPzqkjY/?t=423) If you overbuild a product toward that, what could happen is six months later, you have a new set of models that come out. And all of a sudden, all the assumptions you made before in terms of the way you built product, the kinds of problems you thought you could solve, because that was all that was solvable at the time, all go out the window very quickly. We built a research team in-house to focus on that. Our engineering team and product teams are very heavily embedded within our core customer base because we know that every six months, because of how quickly the technology is changing, the kind of product that we build, the kinds of problems that we solve are all going to completely change. And if we don't get ahead of that, someone else will, and we will end up being the ones that get this stuff in. So let's get into how Decagon is run. And I really want to focus, you know, on the next hour on the core of it as because not just is Decagon one of the most exciting companies in the world today, but it's also probably one of the most AI native companies, right? And you started three years ago, right at the beginning of this wave. So I want to spend the next hour thinking or talking through culture, how the various functions are run, how leadership works

[8:09](https://realalpha.app/v/_FmwqPzqkjY/?t=489) at Decagon. Let's start with the culture. So your four stated values are just get it done, invent what customers want, winner's mindset, the polymath principle. How do these actually show up on a Monday or any given week? Yeah, yeah. You know, invent what customers want, I think, was tied to, you know, the thing that we were just talking about, which is this idea of the only thing that matters is customer pain. And we really wanted to avoid this world in which, you know, at a certain point, once you get big enough, there is this pool, just because it's a little bit easier to sit in a room and say, okay, I have the perfect vision. I know what customers want.

[8:46](https://realalpha.app/v/_FmwqPzqkjY/?t=526) We're just going to build that and put it out into the world. And we really wanted to ensure that that wasn't how products got built within Decagon. And so, you know, that this idea of invent what customers want is mostly on the EPD side, right? Which is ensure that anytime you're building something, you know who it is for because they have explicitly asked you about it. Not because you think, oh, this is probably what they want. But most of the time, again, the market will pull it out of you. The polymath principle was something that was... That's an interesting one. I've not seen that one before.

[9:16](https://realalpha.app/v/_FmwqPzqkjY/?t=556) That one is actually because we consider everything within Decagon to kind of be a team sport. The fun example that I'll give is most enterprise sales teams have a gong, some kind of a gong where once a deal is closed, you have the salesperson come and strike the gong for having won the deal. At Decagon, it's not just the salesperson, it's the salesperson, the APM on the deal, and the engineers that support the deal that all kind of do it together because we believe that everyone is involved in getting a deal across the finish line. And we think it makes everybody better, right? Because a salesperson that deeply understands the product and the technical complexities and the engineering decisions is able to understand customer issues better and communicate why we're different. Similarly, engineers at the other end of the line that deeply understand, hey, this is what is important in a sale. This is what customers care about today, are able to build better products. So we really want to emphasize this idea that, hey, just because you're in one particular team doesn't mean that that is the only thing you should care about because you just end up doing better work, the better you understand the business as a whole. Does the polymath principle show up when you're recruiting

[10:27](https://realalpha.app/v/_FmwqPzqkjY/?t=627) So this does show up on the recruiting side as well. So for engineers, we spend a lot of time thinking through, hey, how do you think about product? How do you think about designing things in a very user-centric way? I mean, it's hard to simulate a sales cycle or things like that, but we do check for this ability to understand user problems and build against them well. And on the sales side, of course, it is, hey, how much do you have the ability to sell a more technical product to dive into details. Of these four, which was the hardest to operationalize as you've gone from two people to like 400 plus people within three years?

[11:05](https://realalpha.app/v/_FmwqPzqkjY/?t=665) Honestly, it's, you know, it's different ones for different teams. So, you know, this idea of build what customers want does often get more difficult as you scale out because you now have people that can get farther and farther away from the end customer, right? Because you have more teams that are dedicated to running that customer specifically. So we put in like very conscious efforts to make sure that that doesn't happen, right? Because on one hand, you want engineering teams to be able to stay focused, have like long periods of deep protected time, but you also, again, want to ensure that they don't build in silos. And similarly, on the sales side, it can be easier to say, hey, you know, here is the top track. Here's the top track that's worked a thousand times before. As long as you stick to these well-defined playbooks, things go well. So ensure that we have this kind of deep cross-cultural, cross-team collaboration, especially again, as we get bigger, we have offices in countries all over the world, ensuring that that stays well has been something we've put time into.

[12:03](https://realalpha.app/v/_FmwqPzqkjY/?t=723) Is there any mechanism that you guys have figured out? Sales reps listening directly from customers on what they want, or if there's friction in sales processes, or customer success orgs getting that, that the entire company gets to hear that, whether it's a weekly Slack summary or something, is there some mechanism for you to know this? So this is exactly where luckily the polymath principle helps us a bunch because if we were behind on a deal, right? Like the sales rep can quickly figure out why we're behind. And then the right engineers are pulled right in, right? Like they join the customer calls themselves.

[12:38](https://realalpha.app/v/_FmwqPzqkjY/?t=758) So we don't have to go through this process of, okay, how do we make sure that that goes into a digest somewhere that is then distributed to the right teams? We just make sure the right person on that team is in the sales call themselves. Similarly, if this is an existing customer and they're unhappy about something, we have Slack channels with every single one of our customers.

[12:55](https://realalpha.app/v/_FmwqPzqkjY/?t=775) **Ashwin Sreenivas:** And anytime that customer has an issue, the right engineer or product leader on the team gets added to that Slack channel if they weren't there already.

[13:04](https://realalpha.app/v/_FmwqPzqkjY/?t=784) And then they respond directly. So again, we want to ensure that there aren't these kind of long chains from the customer to the person building the thing. So this actually just solves that problem entirely. And then the next one, the just get it done, decisive action and speed over prolonged deliberation and planning. How do you ensure, because speed has a trade-off, right? So speed obviously is an attribute that all of us aspire to in business, but at the same time, like speed can also mean thoughtless execution, sloppiness to cut corners, to just get it done fast. How do you kind of strike that balance?

[13:38](https://realalpha.app/v/_FmwqPzqkjY/?t=818) So I think the trade-off for us has been speed on one hand versus coordination on the other, right so in terms of quality we've been able to maintain the quality bar by ensuring that hey when you ship something out when you roll out a new process it meets the quality bar but coordination is something that can suffer right because if you have two teams building the exact same thing in slightly different ways then you know it's hard to coordinate if everyone is building it out in two days and that's actually just a tax that we have decided to accept right it's not it's not a

[14:11](https://realalpha.app/v/_FmwqPzqkjY/?t=851) **Ashwin Sreenivas:** perfect trade-off you have to give somewhere and we gave for speed and the reason i think this is

[14:15](https://realalpha.app/v/_FmwqPzqkjY/?t=855) more true today is actually because the pace of building has changed so quickly with ai right in the old world when development took a lot longer and you know if you say okay i'm going to scope out this feature and it's going to take me two weeks to build there's kind of some inherent coordination time in there right because it's going to take two weeks to build so during that two weeks, you have time for everyone else to coordinate what people are building. But now, instead of two weeks, if it's two days, there isn't that much time for coordination. And we knew that one of these had to give. And so we were more okay with the coordination piece giving in because we think if you're building fast enough, yes, if you have two teams that turned out to be building in slightly different ways, we're moving so fast anyway that we can fix that on the back end when it actually becomes a problem. Actually, it's an interesting point, like the trade-offs.

[15:05](https://realalpha.app/v/_FmwqPzqkjY/?t=905) So you have these definitive cultural elements that you really want to adhere to. Some of that is informed by your past experiences, maybe for both you and Jesse. You mentioned one, coordination is something you're willing to give. Are there other aspects that you guys came in thinking, hey, these things get talked about a lot, but we are okay giving up on those a little bit for the sake of these four? Coordination is definitely the biggest one. The other big one is probably productization quickly, by which I mean our general philosophy as a company, because we sell primarily to enterprises, was making sure that whatever we built worked exactly for the company as though it were built just for them.

[15:51](https://realalpha.app/v/_FmwqPzqkjY/?t=951) Right. And this is something that people generally are like, hey, don't do this because it's going to be very, very, very difficult to scale if everything is built bespoke. right and so the difficult decision for us was how do we make something feel very bespoke and scalable at the same time so what we did was in the early days and this is now the very early days we actually built basically bespoke in a completely unscalable way because we figured once we get big enough we will figure out how to productize now that we are much bigger the way that we productize is not by saying hey we're going to build the standard thing and everybody should be able to kind of get to that, but rather to say, we're going to build the kind of right configuration points so that you can configure the product to suit you exactly, right? And that last mile of configuration, now we have AI agents, right? This is what they're very good at. So as an end customer, you can get something that fits you perfectly, but in a scalable way. Now, the problem that this causes is now when you're building out a new thing, there is a risk of you overfitting to a customer because, again, our philosophy is it should fit you perfectly. And then if three people

[17:00](https://realalpha.app/v/_FmwqPzqkjY/?t=1020) want three different things, you figure out the right configuration points. And again, that's a trade-off, right? Sometimes you're right. We will overbuild. We will build in a somewhat custom way that isn't scalable. But again, the assumption that we're making is, hey, once this becomes a problem, we will figure out the right configuration points and rebuild if necessary. Was some of this informed from your stint at Palantir? I know you started there in your career. No, a lot of it was, But I think a lot of it is also because of the market that we serve, right? We sell primarily to large enterprises, primarily in large deals.

[17:33](https://realalpha.app/v/_FmwqPzqkjY/?t=1053) And so effectively what happens is these are very demanding customers, and as they should be, right? Like we are essentially representing them to their end consumers, and they have very specific needs. So I think part of it is, you know, a lot of what we did at Palantir back in the day, but a part of it is also the market and type of customer that we serve at Dekugan. And then the next piece about your culture is in office, what, six days a week, five days a week? Yeah, we used to be six days a week, actually, when we were much smaller. But now we're big enough that we're five days a week for most of the company.

[18:08](https://realalpha.app/v/_FmwqPzqkjY/?t=1088) Jesse and I are in the office on every Sunday. I mean, today's a Sunday when we're recording and you were coming from office. Yeah, I was coming from the office. Yeah, so Jesse and I are in the office every Sunday. And then, you know, teams that have things that are blowing up are in on Sundays. but by far, for most of the teams, why are we so religious on this? Honestly, just because it comes back to that coordination problem. Actually, in the very early days, it was because everything we were doing was new, right? And I think it just, in my opinion, nothing beats that, you know, everyone in a room looking at a whiteboard and whiteboarding things out.

[18:40](https://realalpha.app/v/_FmwqPzqkjY/?t=1120) Today, it's mostly because of that coordination piece that we talked about, right? Like the more remote you are, the higher the coordination tax. And again, we talked about, you know, given that things move so quickly, the more remote we are, the less coordination you can have, which kind of forces you to go even slower or have even more chaos. And that's quite difficult. So even now we find that most of our conversations are from, you know, people kind of leaning over and saying things to each other. In fact, a funny story, not only did I want people to be in the office, but when we move, we're actually about to move to a new office. And I specifically asked our head of workplace to get smaller desks so that people are packed even closer together so that you can lean over and talk to you know an exponentially larger number of people does it create an issue the 16 the offers especially like for some kind of people decacon is not a great place then now that we are a much more mature company for most people it is actually just five days the only people expected to do the six are actually just me and jessica because again we understand that you know there are a lot of people that work at decacon that have families

[19:46](https://realalpha.app/v/_FmwqPzqkjY/?t=1186) And I want them to spend time with their families on the weekends. I don't want them to miss like dinner with their kids and things like that. And we understand all that. Like there are people at different phases of life. And yeah, we make it work for all of them. So let's talk about recruiting. And the first and the most important hire is the co-founder hire for both of you. How did the two of you decide to work with each other? Yeah, just give us the backstory there. Both Jesse and I had started companies before. I started a company called Helia that we sold to Scale. He started a company called Loki that he sold to Niantic.

[20:16](https://realalpha.app/v/_FmwqPzqkjY/?t=1216) And this was right in the period where both of us were figuring out what we were doing next. And once we met, we had a number of things, surprisingly, that were very much in common. So we both sold our first companies. We both got married relatively young, both to women a year and a half older than us. And actually, our wives get along very well. In fact, we now live in the same building. both of us wanted to start enterprise companies both of us wanted to do problem discovery in a similar way right everything we talked about in terms of you know being very focused on the end customer and what their pains were both of us grew up in very similar environments like both of us used to do the olympiads and so you know we we we had a lot of like common background both of us thought about work in a very similar way which is neither of us did much in our life except work. And so we were just aligned on a lot of things. The most important thing was also, I think both of us respected the other person's competence, which is actually very important because when you have a fast growing company, you have to lean on your co-founder a lot, right? So being able to say, hey, I know this is a big, important issue to figure out. I don't have time

[21:34](https://realalpha.app/v/_FmwqPzqkjY/?t=1294) for it, but I trust that you can do it and I don't need to think about it anymore. So having that quality was very important as well. How long did you know each other to get comfort on that? It ended up being relatively quick because when we kind of started the company together, this was kind of a gradual process in that initially we were like, okay, you know what, we're both figuring stuff out. Let's just hack on things together, right? And there was no, let's sign on the dotted line, start the company immediately. That took up, you know, that was a few months later, but mostly because in the early days we were validating problems, talking to customers, things like that.

[22:11](https://realalpha.app/v/_FmwqPzqkjY/?t=1331) So we kind of got to build that out over time by seeing the other person do it. Do you guys now know, or even at that time knew the relative competence where one is stronger than the other? We found out pretty quickly because again, in the early days, we were doing all of the things, right? Like we were cold emailing customers. We were getting on customer calls. We were building, we were prototyping and building solutions to things. So we got to see all of that like pretty quickly. but both of you are polymaths so my point was more like is one person better at people problems versus product problems or actually both of you because you're president he's CEO like kind of it seems from a distance that both of you are polymaths across the org so both of us actually do get into the weeds on everything across the org which is which is actually great but actually to make things go quickly each of us have very clear areas of ownership because again internally we believe that every problem should have a single person that is responsible for it.

[23:12](https://realalpha.app/v/_FmwqPzqkjY/?t=1392) And between me and Jesse, everything maps either to him or to me uniquely so that we know that, hey, these are the things that you're going to take care of and you will do them well. Jesse does a lot of the go-to-market stuff. I do a lot of EPD. People, interestingly enough, rolls up to me, people in recruiting. So yeah, but both of us actually go into the weeds on everything across the company. And then the other interesting thing about Decagon is you guys did not hire a single employee or maybe there was one junior employee till a million of ARR which is rare yeah I mean we are in the business of recruiting for our startups and most founders come and they start recruiting engineers two three four right at the beginning some start hiring their sales reps at 500k of ARR yeah why make that choice of not hiring was it intentional or just happened so quickly no it it was somewhat intentional but you know looking back I wish we had started a little bit earlier, but with the information I had at the time, I think it would have been difficult.

[24:11](https://realalpha.app/v/_FmwqPzqkjY/?t=1451) I think now having seen so many companies, us included, growing so quickly, it's like, oh, it's obvious that we should have hired sooner then. But I think if you think back to sort of 2023, before a lot of these companies had started, a lot of the revenue ramps were much slower. So one, we were surprised by how quickly our revenue ramped in the early days, but we weren't sure how quickly it would continue to ramp, which was honestly why it took us a little bit longer to hire our first people. And also secondly, early stage recruiting takes a lot of time. And we just had our hands full with building for customers and onboarding new customers.

[24:48](https://realalpha.app/v/_FmwqPzqkjY/?t=1488) And we're like, okay, next month, as soon as we build these three features and onboard these three customers, then we're going to have so much time and then we're going to recruit our first set of people. Do founders selling also, where did you have the bandwidth to build all the things that the customers need? because the first few customers all have their unique-ish demands. And you again took that approach of... Make sure they have everything exactly as they need. Yeah. I mean, it was tough. In the early days, we would be in the office, which was one of our apartments, at probably around nine in the morning.

[25:18](https://realalpha.app/v/_FmwqPzqkjY/?t=1518) And we were there until one o'clock at night. And in the early days, we did seven days a week. The two of us did seven days a week, I think for the first year or so. And then we stopped that because both of us are married. Seven days a week is a... How are you convincing the price of this? But yeah, it took a lot of time. The other benefit that we had was, again, because both of us could do sales calls, both of us could do customer onboarding, and both of us could write code. That helped quite a lot because, you know, we were able to kind of juggle and fill in for the other person whenever needed.

[25:49](https://realalpha.app/v/_FmwqPzqkjY/?t=1549) And then you made the switch and you've gone pretty fast. So you've gone from zero employees to 450 employees now within three years. I want to get into what's the trade-off of hiring that fast and all of that. But before that, do you guys have an overall recruiting philosophy and framework that the entire org follows? Or each hiring manager ends up having their own framework? We do have an overall philosophy. And even to this day, Jesse and I are pretty involved in recruiting. I mean, at this point, neither of us can do all the interviews anymore because there's just too many. But even now, including for ICs, we review hiring packets.

[26:25](https://realalpha.app/v/_FmwqPzqkjY/?t=1585) And so we're still pretty involved. And the things that we're trying to make sure of are that all the new hires that we bring on align to the kind of core cultural values that we're trying to look for, right? So have we looked at this person's ability to operate across multiple teams? Have we looked at their ability to go really, really, really deep on problems? Has the interviewer on the Decagon side probed for all these things? Have we found a clear champion within Decagon? We, like many other companies, hire on the one, two, three, four scale.

[27:00](https://realalpha.app/v/_FmwqPzqkjY/?t=1620) **Ashwin Sreenivas:** And if you just have threes all across the board, okay, there's no clear champion for this person.

[27:05](https://realalpha.app/v/_FmwqPzqkjY/?t=1625) They haven't spiked strongly enough and we shouldn't be making them an offer. So yes, we're still pretty involved in recruiting up and down the line. But at that pace, 450 employees being hired in three years, like how do you maintain that bar? Because the flip side is you maintain the bar that high, hiring becomes slow. I'm of the opinion that when you need to hire at scale, You just, you need to talk to a lot of people, right? There are a lot of great people out there in the world. And now it is our job to find them and convince them that, hey, Decagon is a great opportunity for you. In terms of how we maintain the hiring bar, we actually have a group of bar raisers internally that do the final interview, right?

[27:46](https://realalpha.app/v/_FmwqPzqkjY/?t=1666) So once you've gotten the thumbs up from everybody, one of the bar raisers interviews you. And, you know, we've specifically picked out the bar raisers as people within Decagon. and we're like, hey, these are the people that really kind of hold our values. They've demonstrated it over time and they know what they're looking for amongst new folks. Actually, I've never heard this before. So the bar raiser, how many bar raisers at Dekacon today approximately? I think like 20, 25 people. Do they go and interview that final interview in their own functions or it can be cross-function? It can be cross-functional because again, the thing that these people are looking for is this person's ability to move quickly without needing to wait for permission or decisions, dive deep into various areas.

[28:28](https://realalpha.app/v/_FmwqPzqkjY/?t=1708) And they're looking for evidence that this person has done this in the past. Because in terms of competency at the function, that's what we expect the regular interview process to do, right? And you're right, we're hiring a lot of people. So a lot of people that are interviewing might themselves be newer, but we always make sure that the hiring manager himself is extremely competent at interviewing capability for that function. Even to this day, for managers, both Jesse and I are reasonably involved. Is there a cultural expectation that every employee at Decagon has to be AI native? Like their AI savviness across...

[29:06](https://realalpha.app/v/_FmwqPzqkjY/?t=1746) Engineers is probably easier because they are in the thing, but hiring a customer support person, customer success, sales, do your sales reps need to be AI native? Are you testing for that in the recruiting process? Pretty much everybody across Decagon has, I mean, has embraced AI because of the fact, also because of the product that we sell. You know, if you look at kind of each of the three orgs, sales and everything, pre-sales, post-sales, and EPD, on the EPD side, of course, it's, you know, much more understandable that everybody is building with AI. On the post-sale side, interestingly enough, we have built an AI agent that handles Decagon, implements Decagon.

[29:47](https://realalpha.app/v/_FmwqPzqkjY/?t=1787) Actually, we announced this maybe a week ago called Duet, right? So the post-sales team is building a lot of their Decagon implementation and everything through Duet. You know, we've built out the ability for Duet to be taught new skills on how to implement Decagon, things like that. So, you know, everybody on the post-sales side is pretty AI native at this point because of the kinds of work that they do. And on the pre-sales side, again, we've used a whole range of AI tools, everything from, hey, how can you help me prep for this meeting better? How can you help me find new accounts better? Things like that.

[30:17](https://realalpha.app/v/_FmwqPzqkjY/?t=1817) But is there a recruiting criteria? Like you need to see some AI nativeness in the portal or no? I think on the EPD side, yes. In fact, we've rebuilt a lot of our interviews. I wouldn't go so far as to say it requires AI, but honestly, to do a pretty good job and like build out as much as you need, you either have to be one of the fastest coders in the world, in which case, great, we are higher anyway, please. Or you probably need to be pretty good at AI coding. on the pre-sales side, we haven't like required it as much because we're like, hey, these are skills that, you know, if you're very good at your job, otherwise you can pick these up pretty quickly and we're happy to help.

[30:52](https://realalpha.app/v/_FmwqPzqkjY/?t=1852) I'm actually curious, have there been senior business execs who've built a lot of their career in the pre-AI world who are laggards and who you had to kind of, hey, no, no, this thing is like... Not as much at Decagon because again, of the kind of person that we pull in and recruit for. And also this is probably a kind of person that says, hey, I want to opt into working at an early stage startup that is moving pretty quickly. And again, that's the kind of person, again, that's like, I want to, you know, use the latest and greatest. So let's now dive into each of the individual functions for a bit.

[31:23](https://realalpha.app/v/_FmwqPzqkjY/?t=1883) So let's start with engineering. At this point, are your engineers even writing code at all? Yeah, it's a great question. I think I would say at this point, the vast majority of code that is written is written by, you know, Cloud Code, Cursor, Cognition, Devon. But we still expect our engineers to understand what was written and essentially sign off on it and saying, hey, I pushed this PR. I'm fine with it. Right now, we want to give them all the support around that. So, for instance, we've spent a lot of time investing in how do we set up our code base to be easy to use AI with. How do we create good documentation in the code base?

[32:02](https://realalpha.app/v/_FmwqPzqkjY/?t=1922) How do we split it up in a way that the agents can understand? How do we create good, you know, Cloud MD files if you're using Cloud Code, for instance, so that as an engineer picking it up, you can get started very quickly. Similarly, on the review and testing side, we've invested a lot in saying, how can we find issues very quickly? How can we automate checking for style issues and structural issues and things like that and security issues, of course. But we still expect the engineer to be responsible. We say, hey, use all the tools you have available so that you can move faster. but at the end of the day,

[32:33](https://realalpha.app/v/_FmwqPzqkjY/?t=1953) **Ashwin Sreenivas:** you are responsible for the code you push and you should be prepared to defend it

[32:36](https://realalpha.app/v/_FmwqPzqkjY/?t=1956) rather than saying, oh, you know, the AI agent wrote it. That's all I know. Do you mind sharing whatever you can on what's the engineering stack at DecaCon now in terms of course, like, yeah, what AI tools that you guys are using? So interestingly enough, we subscribe to all of them at this point because engineers have their preferences on what they would like to use. So we have some engineers that use Cloud Code. We have some engineers that use Devon. We have some engineers that use cursor and we have some engineers using codecs. And we are fine with whatever they want to use because ultimately we use this as a, we view this as an accelerant to building.

[33:13](https://realalpha.app/v/_FmwqPzqkjY/?t=1993) And so we're not opinionated on what they use. So the things that we do on the EPD org to help is, number one, making sure that the code base is well set up initially to be able to work with these kinds of agents. and number two, ensuring that everything downstream can handle now the increased rate at which PRs have created like testing, reviews and things like that that would otherwise become bottlenecks. But in terms of the tools themselves, we actually partner with all of those folks. Testing, security, enterprise readiness of the code. At this pace of code gen, and you guys are selling to some of the largest organizations in the world.

[33:50](https://realalpha.app/v/_FmwqPzqkjY/?t=2030) These people probably have low tolerance for customer support or you're giving them something that deals with their customers. So have there been some fuck-ups in the journey? Have there been areas where you're like, guys, we need to be really, really strong on this. We can't just adopt AI. On the security side, we've been very, very tight. Kind of no issues there. Because again, from the very early days, right from day one, we're like, we work with extremely large enterprises that are trusting us with extremely sensitive pieces of data. So even from the very early days, security was always like very tightly maintained.

[34:23](https://realalpha.app/v/_FmwqPzqkjY/?t=2063) And the way that we actually go about operationalizing this is several fold. One is ensuring that your coding practices itself make it hard to mess up. So for instance, requiring that when you create a new route and you automatically add an authorization tag, it just does all the best practices for you. So it's kind of essentially we make it harder to mess up on the security side. Second, a lot of our PRs explicitly look for certain kinds of security issues. Third, we have an application security team in-house that's constantly doing pen tests, that's constantly doing reviews on any changes to anything sensitive.

[35:00](https://realalpha.app/v/_FmwqPzqkjY/?t=2100) And fourth, we're getting pen tested externally all the time. So really something would have to go through lots of misses for there to be any kind of impact. How does the IC engineering role change in these, starting from six months ago when Cloud Code seemed to have made a very step function difference to the next one to two years? So I think the IC engineer's role changes to being able to just iterate really fast. Back in the day when you had a very high cost to trying something, the correct thing to do was say, I'm going to spend a lot of time planning. Because if I do something incorrectly, it's going to take me even more time to fix it.

[35:40](https://realalpha.app/v/_FmwqPzqkjY/?t=2140) now essentially what we're doing is we need to push a lot more of that planning and thinking into one engineer's head because they can autonomously run for a really long period of time so the way that the ic engineers role changes is being able to say okay my job is no longer just taking a well fleshed out prd and just executing against it to getting a much more vague PRD with not all of the pieces filled out and saying, I'm going to be able to try things for each of these things that are unfinished and develop good taste on what the right final thing should be. Because that, again, constrains the development cycle substantially, right? Like, I don't need to wait for PM to come in and review this. I don't need to wait to have three meetings with people to figure out what the right thing is. Now, because of this, I think the VP engineering and VP products job change substantially because since you have these small teams that are moving very, very fast without as much time to coordinate between them,

[36:47](https://realalpha.app/v/_FmwqPzqkjY/?t=2207) **Ashwin Sreenivas:** the job of EPD leadership becomes to very clearly paint the targets of where we want to go

[36:55](https://realalpha.app/v/_FmwqPzqkjY/?t=2215) because the moment you do that for a specific week, a hundred micro decisions will be made without you and to ensure that everyone is rowing in the same direction, achieving the same kinds of goals. Your job on EPD leadership is to figure out very clearly and articulate very clearly what are the core problems we're trying to solve, who is responsible for solving each of those things, and if there are big kind of cross-team decisions, being able to very clearly point out what those are and what the decisions were. EPD leadership, has this not created a lot of noise or surface area for like too many micro decisions being made?

[37:33](https://realalpha.app/v/_FmwqPzqkjY/?t=2253) I have to pay attention to so much of this. Yeah, no, you're absolutely right. So I think effectively what the job has become is to be able to define these kind of higher level goals without being opinionated on how they're implemented. So for instance, you should be able to say, look, we built agents. So we need a good solution to be able to test agents well. And maybe say two or three sub bullets under that in terms of, hey, here are the kinds of things it should do and not be as opinionated on, oh, exactly how do we accomplish each of these? Because if you can say, okay, this piece on how an agent is tested with the three subspecifics is done and you just trust that, okay, this person's going to do it.

[38:16](https://realalpha.app/v/_FmwqPzqkjY/?t=2296) And now you look at a separate thing, right? Essentially what you're looking for is you have these services and you have contracts between them and you're not as opinionated on how each of those things is built. And as an EPD leader, your job is to be able to draw these clean lines and say, here are the interfaces. that this is what each part should do. I'm not opinionated on how it is built because I know all of those decisions will be made very, very quickly without me. And teams should just be able to trust that everything on that side of the house will get done. Actually, as we're having this conversation, I wonder if, you know, Steve Jobs had a great quote, focuses about saying no.

[38:49](https://realalpha.app/v/_FmwqPzqkjY/?t=2329) And in a prior era where the cost was, hey, if I try 15 different things, it takes time to build it. It takes time to fix mistake. Now you're saying, actually, it doesn't take as much time to build it and it doesn't take as much time to fix mistakes, do you actually feel your advice would be to say yes more to EPD leaders? I think it's actually in between, where it would be try a lot of things. Because what you don't want to do is give... The customer, at the end of the day, wants that problem solved, right? And ideally, they want that problem solved in the simplest possible way. And we run into this all the time, right?

[39:27](https://realalpha.app/v/_FmwqPzqkjY/?t=2367) If you go into a customer and say, here is a product. And by the way, here is 500 different things that you could do to make this fit exactly like it. The customer just wants that problem solved. So it is our job to be able to abstract away a lot of this complexity from them. So we try a lot of things. We try a lot of different solutions. But we want to go to the customer and say, hey, this is the right one for you. So I think that the adage on simplicity still holds. So let's shift towards FDE or customer success slash FDE. And that's an interesting area for AI because, you know, it's a lot of FDE motion right now in AI.

[40:06](https://realalpha.app/v/_FmwqPzqkjY/?t=2406) You yourself were at Palantir. How has the FDE motion evolved since your Palantir days to where AI is today in the enterprise? I think this is an important point because I think this gets mistaken a lot in this space. There are actually two types of FDE work. And I think when people talk about it on Twitter, they conflate the two. And I think this is dangerous. The reason is the first type of FTE work is what is more typically understood as FTE work, even historically. This ability to say, I'm going to go in and build the last mile of software and integrations for this end customer because no one else is going to want anything like that ever again.

[40:46](https://realalpha.app/v/_FmwqPzqkjY/?t=2446) Right. And it is truly bespoke consulting. work. The second type of FTE motion is saying there is a lot of product I haven't built yet and so this is not going to be usable for my customer but this is product stuff that I need to build anyway. Now the reason I think there is a lot of this type of work today, the second type, is because there's a lot of net new product thinking. So for instance if you were starting a CRM company or a sales automation company, there's been 10 years of product thinking on what are the user journeys? What are the kinds of things that I need to support? What are the kinds of workflows my users expect of me?

[41:24](https://realalpha.app/v/_FmwqPzqkjY/?t=2484) But with AI tools, all of this is so new that the users themselves don't know what kinds of workflows they need to support until they start using it. So I think the job of the second kind of FTE is honestly just a product engineer that happens to sit next to users and see what the issues they're facing are and build it correctly into the product.

[41:45](https://realalpha.app/v/_FmwqPzqkjY/?t=2505) **Ashwin Sreenivas:** I think confusing the two can be very tricky and dangerous because if you are the second kind of FTE, and this is actually the kind of FTE I think most companies, most AI companies need today, your job is to figure out what is the generalizable product thing that I need to understand from my end users and build into the product.

[42:05](https://realalpha.app/v/_FmwqPzqkjY/?t=2525) And I think this gets conflated a lot because everyone just calls them FTEs. Yeah, I 100% agree with you. I'm seeing this across our portfolio also. but then accordingly what's the right background for that kind of an FDE the person who can generalize it is it a product person? Yes it's a really good ideally a really good product engineer that can both empathize with the user understand what the generalizable thing is and build it right because now this engineer can move way faster than before but otherwise an engineer and a product person kind of pairing together. And then obviously every you touched on this already But every FD org runs into the tension of how much of this is permanent services and a permanent drag on the gross margins, people dependence versus how much of this will get productized across the portfolio of customers.

[42:54](https://realalpha.app/v/_FmwqPzqkjY/?t=2574) Have you guys had that tension at all or this framework that you just shared is pretty disciplined in how your FDs approach the entire business? For us, we don't feel this tension as much because we view all of this kind of last mile work as helping us find the right configuration points within the org, right? Because we think two things are true. We think that, one, there exists enough configuration points to help you build something that feels completely bespoke, right? And it's just a matter of finding those right configuration points. for instance, you could say that, look, every integration is going to be bespoke work, right?

[43:36](https://realalpha.app/v/_FmwqPzqkjY/?t=2616) Because by definition, someone that has a in-house build of some service that they built themselves in-house, you're never going to be able to have a product integration for that. But our view was, great, the way that we're going to do it is our product itself is going to have an integration service where you can build an integration into anything directly within the product. and now we're going to have a coding agent help you build that within product again, right? So that last mile integration work goes from, oh, I need to like, you know, create PRs and things like that to integrate with internal services to no, you can actually do most of it within the product because we built this generic integration builder and coding agents to help you do it.

[44:15](https://realalpha.app/v/_FmwqPzqkjY/?t=2655) Is your FDE organization, I know you have an agent builder, like are they building agents for their own work to get automated? Yes, actually. So interestingly enough, again, we launched this as Duet a week or so ago and interestingly enough, we use Duet to build Decagon agents. Duet itself is a Decagon agent, right? So we built Duet on top of Decagon. So anytime, you know, people on the agent building team need to expand the capabilities of Duet, like make it do things before, it's just a Decagon agent. Like there is an instance of Decagon for it. So they just go in, expand the Decagon agent and now, oh, Duet can do more things and now it can do it across the entire customer base.

[44:54](https://realalpha.app/v/_FmwqPzqkjY/?t=2694) Let's shift towards your sales org. How pervasive is the use of AI in your sales and marketing org? Are you guys using AI as GR tools and stuff like that? Yeah, no, absolutely. Exactly like in EPD, we view these tools as accelerating people's progress substantially, right? And today, I would say AI isn't yet good enough to be able to do an entire sales cycle end-to-end for our kind of customer base. We think it'll get there eventually. It's not there today. But absolutely, like everything from prospecting to, you know, meeting prep to documentation updates to deal cycle reviews, we use kind of AI tooling.

[45:35](https://realalpha.app/v/_FmwqPzqkjY/?t=2735) Do you believe in a world where SDRs won't exist and it'll be only AI agents? Or do you believe in a world where each SDR will be 5x, 10x more productive because of AI? You know, I think for a while the SDR role will be 5x, 10x more productive because of AI. There's a lot of people building interesting products in the space. Maybe that will change. But I think for the next while, it's going to be an SDR is 5 to 10x more productive. Because you guys sell into very large enterprises. So it's consultative selling and the market is also competitive. Has the AE role actually changed because of AI or not really?

[46:12](https://realalpha.app/v/_FmwqPzqkjY/?t=2772) I think the fundamental nature of the role hasn't changed yet. In the same way that I think the fundamental nature of EPD hasn't changed. But I think it's changed less actually. Because ultimately, if I'm in AE, I have two goals and just two. Number one, if you're an end customer, I need to understand what your pain is. And two, I need to show you how my product can solve your pain, right? And given that everything is interpersonal, I think there's a lot of work around this motion that has been accelerated by AI, right? So finding the right person, prepping for the meeting correctly, doing the post-call work better with AI.

[46:52](https://realalpha.app/v/_FmwqPzqkjY/?t=2812) But I think the meeting itself, right, where I'm understanding your problem and I'm showing you things about my product that solve your problem, I think that hasn't changed yet. How much AI is being used in your sales efforts? Let's talk more about the AE side than the SDR. SDR makes sense. Right. But based on what you just said, is there much AI being used in your sales team? There is because, again, there's a lot of overhead in sales. I need to take notes during my call. I need to update my Salesforce records. I need to provide proper roll-up. So there's effectively all of this work that, honestly, most reps hate doing.

[47:31](https://realalpha.app/v/_FmwqPzqkjY/?t=2851) All of the work around it can be helped quite a lot so that you can say, hey, as the AE, go do what only you can do today and kind of focus on that and offload all of the busy work around it to AI. In recent times, like Ramp, as an example, has taken a pretty aggressive becoming an AI native company stance to release something called Ramp Class that they've talked about. Have you guys built internal tooling at Decagon that kind of is the connective tissue across the company? So we've built a slightly different version of this, again, called Duet, also built on Decagon. And it's very focused on Decagon product itself, right?

[48:09](https://realalpha.app/v/_FmwqPzqkjY/?t=2889) So we effectively built it for our end customers and ourselves internally to be able to understand the health of Decagon deployments to help people build better agents faster and effectively do everything within Decagon. So the big switch for us internally was we think there are kind of three phases to these AI agents. And let's use Decagon as an example. phase number one is where you do the work phase number two is where you decide what needs to be done and you tell an ai agent and the ai agent does the work and phase number three which is what we expected we built to add for is the work gets done and anytime you need to make a decision it pauses and comes and asks you for approval so it's not even your job to think about what needs to get done because all of it is just getting done autonomously all the time and whenever there needs to be a human in the loop decision, it'll just pause and come ask you questions. So it's a different kind of thing than what the RAM team does. We have a ton of respect for the RAM team but the place where we focused our AI agent was kind of on Decagon deployments themselves. Do you foresee in the way you just described it, three years from now, what is the role of the

[49:27](https://realalpha.app/v/_FmwqPzqkjY/?t=2967) human at Decagon? I think there's still going to need to be people for a few things. Again, I think for a while, everything on the customer side is going to end up being human to human. This idea of understanding what your core problems are. Now, once we do that, perhaps we have everything downstream from there handled by AI agents, right? Because AI agents listen to the calls. AI agents listen to all the calls. They prioritize the features. They build out the features. PRs that are created, and you have other AI agents that review the PRs and ship them into production. Once you do that, you have AI agents write the call notes.

[50:04](https://realalpha.app/v/_FmwqPzqkjY/?t=3004) I think getting all of these to work exactly is going to take a little bit of time. So I think until that happens, you're always going to have humans at kind of each of these stages. How are you and Jesse using AI today, day to day for your own leadership and call it your third co-founder, as your third co-founder? Honestly, it's for a lot of personal leverage, right? Because at this point, there are so many things happening in the company that being able to see everything is difficult. So a lot of it is training AI agents with skills and other kinds of things to say, here are the kinds of things I want to know about.

[50:44](https://realalpha.app/v/_FmwqPzqkjY/?t=3044) Now, here's a raw stream of everything, flag things to me that I would like to see and just give me a quick summary of everything else. Health of these accounts, because again, we have Slack channels, everybody. Just tell me if anything is going wrong that I should pay attention to because otherwise, the team has got it. They're doing a good job anyway. Where do you not trust AI for your leadership or giving you leverage? When there are people issues. I think people issues are always more complicated. And really, it's about like sitting down with people and understanding what their problems are and talking to them one on one.

[51:17](https://realalpha.app/v/_FmwqPzqkjY/?t=3077) I think AI is good when there are these kind of external artifacts that you can use. There are external calls. I can review the calls. And, you know, that is the full truth of what happened there. customer health. We're pretty open in our Slack. Interpersonal issues is never the full story until you really sit down with someone and have a conversation with them. Do you have thoughts on how your own role might evolve in three years with everything that's happening around you with AI, your orgs, getting more automated, their roles evolving? So how does your role evolve? You know, I think my role in a way, I don't think will change that much because as having an executive team, I kind of rely on them to do a lot of the work within their orgs, right?

[52:06](https://realalpha.app/v/_FmwqPzqkjY/?t=3126) So now, whether that is an executive or an AI agent or an executive sitting on top of a team of AI agents or a team of people, I think doesn't actually fundamentally change my job, which is making sure as a company, we're building the right things, we're going to the right place, we are hiring the right people, or maybe instead of hiring the right people, We have the capacity to do all the things that we need to do. We have capital in the bank to do what we need to do. I think fundamentally all those things probably don't change. You guys are in the rare position. There are probably like only like 10 AI native companies where you started in 23 after ChatGPT came out, which has had similar success.

[52:42](https://realalpha.app/v/_FmwqPzqkjY/?t=3162) Like they're probably not more than 10. If somebody were to start a company today, in terms of the AI native org aspect of it, what would be your recommendation to founders starting today? Really the highest leverage place today for AI agents is probably in EPD. If you're starting a company, that's almost certainly where you need to be focusing all your time anyway. So really put a lot of thought into how you can create this kind of agent factory where you have a code base that is approachable by AI, where you can have AI agents try things out, where you have AI agents that can review the work.

[53:19](https://realalpha.app/v/_FmwqPzqkjY/?t=3199) essentially treat building out this factory as a product in itself. And that'll substantially increase your velocity at building things, which means that increases your velocity at trying things, which means you can put stuff in front of customers faster, which probably increases your chances of success by quite a lot. Let's talk about moats, because a lot of discussion in AI enterprise layer or application layer is about Anthropic is attacking my business and stuff like that. And you've had, you know, thoughts on this about like, if 90% of your value is about which model to use, you're going to get screwed. How do you guys think about moats at Decagon, if at all? No, we definitely think about it. However, I think, you know, the underlying question might have been, well, what if the model labs come and decide to do this? When we think of the kind of products that we're building, and the kinds of users that we serve, there is a lot of software that we build after the model layer, right? And we think we have tremendous amount of respect for all the model companies that are building incredible things. But when we need to operationalize some of the work that we do at these large enterprises, after the model comes,

[54:29](https://realalpha.app/v/_FmwqPzqkjY/?t=3269) okay, well, we need governance and versioning because you can't just save something and have it go out. We need the ability for our 10,000 employees to collaborate and build the right kinds of agents, okay? Now, when we're having millions of conversations, we need a way to do analytics and insights and QA and things like that. And now we have internal systems, we need a way to build these bespoke integration into our legacy thing. And you kind of have this long tail of just SaaS software that you build to make something like this work, which, you know, we don't really see the model labs wanting to do. Would it be fair to extend your thought in saying, hey, people think of AI as the end of SaaS. It's really SaaS 3.0 or something like that.

[55:11](https://realalpha.app/v/_FmwqPzqkjY/?t=3311) I think this is true. Yeah. And I think the kind of companies that are most at risk are the ones where one of two things is true. One is where they were building workflows for human beings to do. And now fundamentally, human beings are not doing that kind of work. And two, when most of the value of the product can be replaced, like, you know, 98% by a model doing the same work. AI for customer support has become a pretty crowded space, right? You and Sierra were probably the first ones to go and attack this and you guys are the leaders, but there's more and more coming. How do you guys think about competitive differentiation and edge in a world where software can just be built faster?

[55:52](https://realalpha.app/v/_FmwqPzqkjY/?t=3352) The 17th company entering the space can catch up to 80% of your features very fast. You're right, things can be built very fast. So that requires us to also get good at building things very fast. And I think there are two big kind of competitive barriers here in a way. One is just deep understanding of the customer issues, right? Because the problems that enterprises have are complex. And we've just spent years at this point, like embedding very deeply with them, understanding the nuances that they have to be able to build and deploy these agents well. And I think that learning takes a lot of time to get to.

[56:30](https://realalpha.app/v/_FmwqPzqkjY/?t=3390) And number two, there is actually still a lot of technical difficulty to being able to do this very well. And what we found is our enterprise buyers are pretty discerning customers, right? These are sophisticated buyers. They've thought about the problem. They're able to evaluate these solutions very well. Someone that is doing something at 80% versus 100%, you actually get weeded out pretty quickly because these enterprises, again, they have options and they want to pick the best one. for this reason was why we started things like Decagon Labs, because we do a lot of our own model training in-house. And so I would say at this point, probably about 90% of all of our model traffic is through models that we build ourselves in-house. Yeah, actually, maybe double click on Decagon Labs. You released it, what, a month ago, two months ago? Yeah. Why do you need Decagon Labs to stay at the cutting edge when model capabilities are already getting better and parallel people are spending billions of dollars? Why does Decagon need to build its own model? It's a great question. The thing that we found is that at the frontier of capability, model performance is actually pretty jagged, by which I mean, just because you have a model that

[57:39](https://realalpha.app/v/_FmwqPzqkjY/?t=3459) advances a lot in one capability doesn't mean that it does that in every capability. And in fact, in certain cases, it might regress. Now, let me give you a specific example. For our use case, We use a whole constellation of models in each interaction with an end customer. And we care about each of these models doing a few specific things. Now, I don't care about that model being good at coding. I don't care about that model being good at writing poetry. I care about a few very specific qualities. Now, if I use the frontier model for everything, in a way, I'm kind of wasting a lot of parameters and capabilities that I don't care about.

[58:19](https://realalpha.app/v/_FmwqPzqkjY/?t=3499) **Ashwin Sreenivas:** And so in our experience, you can get a model to do better at the few things that you care about in a smaller model, which is hence faster and cheaper.

[58:32](https://realalpha.app/v/_FmwqPzqkjY/?t=3512) And so therefore, if we want to create the best customer experience, we should fine tune and build a lot of those models ourselves. Because we get everything better performance, cheaper and faster. I'm curious, how do you decide what to build in-house versus where to partner? So, you know, voice is clearly a core aspect of customer support. How do you decide we should build voice models in-house versus partner with existing providers? Our general approach to everything here is what can give us the best customer experience the quickest, right? By which if we can get best in class from a partner, we will always do that.

[59:12](https://realalpha.app/v/_FmwqPzqkjY/?t=3552) if we think we can do better ourselves because it is better for the end customer, then we build ourselves. I think this example of Deck Gone Labs was a great one where for the capabilities, for the kinds of models where we think, you know what? A frontier model does do the best. We can't improve on it all that much if we do it in-house. Great. I would prefer to partner with someone, right? Because again, now we get to leverage their R&D spend and capabilities kind of automatically get better. Whereas in cases where I think we can build better and it is crucial to the end customer experience, those are the things that we build in-house. Like I'm not too sensitive to saying, oh, this is really important. So we must do it in-house ourselves. Everything is about where can we improve on the end customer experience.

[59:58](https://realalpha.app/v/_FmwqPzqkjY/?t=3598) In your most paranoid self, where do you and Jesse worry about, hey, if the frontier labs keep pushing, this is where we get cooked. And then how do you think about if, is it going back to all the orchestration and the software around the agent. Maybe talk about the paranoid self a little bit. I, as I'm sure every startup founder is, is paranoid about lots of things. Luckily, that isn't actually a top five concern because again, our view of the world is that there's so much software that you need to build around the core models to make these things work at enterprise scale that we don't think that is where kind of primary competition comes from.

[1:00:39](https://realalpha.app/v/_FmwqPzqkjY/?t=3639) Now, of course, I'm worried about loss of other people building similar things or competitive pressures or market dynamics or things like that. Luckily, the model labs are not one of them. That's a good steer into the inner game section that I wanted to cover with you. What worries you most at your perch today? It's actually two things. One, interesting enough, is hiring. This is probably the number one thing on my mind. because I think it's clear that, you know, the market opportunity is here. There are a lot of buyers. There are a lot of customers that need the product that we've built. But to service them well, we do need a team that can do this, right?

[1:01:22](https://realalpha.app/v/_FmwqPzqkjY/?t=3682) Again, we have customers all around the world and that just requires a lot of complexity to service well. And so we need to hire people very, very quickly. And so there are two issues here. One is we don't hire fast enough to be able to kind of meet the market demand and then we kind of fall short of where we could have been as a company. And number two, which is equally bad, is, or perhaps worse, is we hire the wrong kinds of people because we are in such a rush to hire. And I think both of those can have pretty serious effects to us as a company downstream. So I spent a lot of time thinking about this.

[1:01:53](https://realalpha.app/v/_FmwqPzqkjY/?t=3713) What about the competitive pressure? Is that a concern at all, that everybody is attacking this gigantic space that you proved has an insanely large market pool? You know, interesting, not as much as this, because I think in a way, I'm most concerned about, hey, what are the things that could seriously affect us as a company? And at this point, we're growing fast enough. I think we've proven out our product to a lot of enterprises that this won't come from competitors that try to build and push us out. It'll come from basically us having indigestion, trying to bite off too much and not hire well enough or not hire quickly enough.

[1:02:28](https://realalpha.app/v/_FmwqPzqkjY/?t=3748) I think that is more likely to kind of slow us down than competitor comes in and tries to do something. Taking a slight step back beyond the over-intellectualization point you made that both of you probably had some scar tissue from a prior startup, like are there any other lessons that both of you were bringing to the first few days of Decagon and how that have stayed true for this journey? You know, the biggest one probably remains don't over-intellectualize and listen to your customer because in a way, it's also the only one that matters, right? Because if you build a company doing something that your customers care about, you can mess up everything else in a way and it doesn't really matter.

[1:03:13](https://realalpha.app/v/_FmwqPzqkjY/?t=3793) And conversely, you could do everything else right and not really build something that people really care about having. And also, again, nothing else matters. So in a way, it's kind of pure. It's just this one thing. If you focus on that, don't worry about everything else. Everything else will work itself out. And it's also clear from your culture, even in my prior interactions with you, you guys move at an extremely high pace. It's part of the culture, cultural values and stuff. Does that get tiring as the leader? Because there's a little bit of a mental capacity that it takes to drive the organization week in, week out, day in, day out, probably in every interaction.

[1:03:48](https://realalpha.app/v/_FmwqPzqkjY/?t=3828) How are you managing your psyche driving this organization at this pace? I think maybe this goes back to, you know, when I was growing up, this is back in India, I used to spend a lot of time doing these like competitive Olympiads. There's this one particularly intense period. This was in eighth grade. You had the NTSC, the National Talent Search Exam. And this was in eighth grade, and they test you on everything, right? Like history, chemistry, geography, physics, like everything. And I remember the prep for that, that entire summer, was I would wake up at 5 o'clock in the morning, and for the first hour, I would do history.

[1:04:29](https://realalpha.app/v/_FmwqPzqkjY/?t=3869) And then for the next hour, I would do geography. and then I would take a 30-minute break to have breakfast and then I was fresh again. So for the next hour, I would do physics. The next hour, I would do chemistry and I would take a 30-minute break to shower and I was fresh again. So in the next hour, I would do math and so on. And I would do this every day from five in the morning till I went to sleep at around 8.30 at night and I did nothing else except this for that entire summer. And this was roughly the schedule, probably from like fourth grade to like 12th grade. And so in a way, I'm somewhat used to this.

[1:05:05](https://realalpha.app/v/_FmwqPzqkjY/?t=3905) And now all of a sudden I get to come in here and there's a lot of people and I'm having fun, you know, hanging out with people. So in a way, this is much easier for me in a way rather than sitting by myself in a room and just working alone. It is challenging, but I'm like, oh, if I did that, this is all of a sudden much easier. But let me double click on that. So that you did, I can see it in the way you, you know this is a much more rewarding journey than you know you're building a great company but there's a people aspect of it now you're not just driving yourself you're actually confronting slowness in your organization you're confronting issues does the people aspect become tiring for you the nice part about having been one of the co-founders is you get to pick the people that you work with right and i love our executive team because they're also all people that care about the same kinds of things and have the same kinds of values so my job just becomes spotting things that they might have missed otherwise and again if they were the kinds of people that would push back then you're right it would be extremely tiring because it would just be a whole set of arguments but they're actually great because once you point out they're like oh yes you're right like

[1:06:14](https://realalpha.app/v/_FmwqPzqkjY/?t=3974) let me go fix that problem so psyche management doesn't seem to be a thing that you either needed or maybe you're just... No, the psyche management thing, I think matters in places, not in this one, luckily, but I think it matters in a few other places. One, you're right. If you push too hard, you can get burnt out. So we actually, we actually, Justin, I've had actual conversations with each other. We were like, hey, how do we make sure this doesn't happen? Because again, we want to build this company for the next 20 years. And yes, burning yourself out is a real thing. So, you know, we take our Saturdays off and we actually take that fairly seriously to be able to decompress.

[1:06:50](https://realalpha.app/v/_FmwqPzqkjY/?t=4010) Number two, I actually ended up talking to a number of sports coaches, actually, because there's a lot of similarities between high-performance sports and building a company, right? There's a lot of pressure, honestly, that you also put on yourself. And there is a lot of kind of visibility into how you're doing. So being able to separate, here are the things in my control, here are the things that I can fix and here are the issues that I need to work on whereas here are outputs that I can't stress too much about it's actually very important because you know even today we take every deal loss like very seriously and personally right it's like okay we lost this deal it's okay we need to strip it down remove the emotion from it figure out why we lost figure out what are the processes that caused us to lose and kind of look at it a little more analytically because otherwise yes you're right it can crush you and but yes we put a lot of time into thinking about these things to make sure that you know you can kind of stay sharp for the long haul from a distance somebody looking in Decagon seems like a straight up into the right story you guys started it the fundamental ingredients were great the market size was large you guys are moving at

[1:08:10](https://realalpha.app/v/_FmwqPzqkjY/?t=4090) an insane pace. Have there been hiccups in the journey so far in this one? I know prior startups you may have some stories but in the Decagon journey have there been any hiccups where you guys felt, man today was rough? There's been probably a thousand of those like in every company you know I think the thing about every company is from the outside everything looks amazing right? But I guarantee you every fast growing company, probably without a single exception, they've had a thousand files internally. Because I think that's kind of the nature of things, right? As you grow quickly, as you have a lot of people, as you have competitive markets, just things are bound to go wrong. The person that you hired that you thought was amazing wasn't, and then they messed a lot of things up.

[1:09:00](https://realalpha.app/v/_FmwqPzqkjY/?t=4140) The deal that you thought was a for sure thing that you were going to win that you built a lot round four, you lose at the last minute. So all of these things happen. And I think they happen to everybody. And so I think a part of it is spending a lot of time realizing that, you know what? It's okay. It happens. I know you had Frank Sloopman on your podcast a while ago. So Jesse and I were talking to him maybe two weeks ago. And he was the one that was telling us, he was like, you know, Snowflake was his third company that he scaled. And he was like, you know what? I was anxious the entire time.

[1:09:34](https://realalpha.app/v/_FmwqPzqkjY/?t=4174) Because, you know, there were always things blowing up. And so for us, we're also like, okay, this is someone that has built three generational companies, was also anxious the entire time. It's just normal. That's just how it is. I actually asked him the specific question that, did you ever have doubt on yourself? And his literal answer was all the time. So next up is our quick fire round. First one is most overrated advice in AI in founder circles right now. Hire a lot of FTEs because FTEs are necessary. Again, I think they're necessary for the early days, but only if you think of it as that second type of FTE, otherwise you're asking for trouble.

[1:10:10](https://realalpha.app/v/_FmwqPzqkjY/?t=4210) The AI company other than Decagon that you admire the most? We have a lot of respect for the folks at Ramp because they would, in a way, have every excuse to not be an AI company, but they've just built incredible things. Personal favorite AI product other than ChatGPT and Cloud? I use Whisperflow a lot, actually, because again, now I do a lot of slacks. I do a lot of emails and I can just I can talk way faster than I can type. I swear to God, that company must have the highest NPS. It is one of my top two personal favorites also. And I know so many people who just swear by it. Yeah, it's a great product.

[1:10:46](https://realalpha.app/v/_FmwqPzqkjY/?t=4246) One book every AI founder should read. You know, probably two come to mind if that's OK. One, there's this biography on the Wright brothers that I think was pretty interesting because, again, it talks about the cycle of invention in a way. I think one of the interesting anecdotes from that book was about how once they built the airplane, you would think that there would have been incredible pull for this. I mean, obviously, they just invented a flying machine that nobody ever had. Do you know how long it took them to convince the U.S. Army to buy their first airplane? Six years. The point was just, you know, even if you have these amazing, incredible inventions, it takes a lot of time to educate the customer on why this is necessary, how to adopt it and things like that. And it's not just, you know, you build an amazing thing and they will come.

[1:11:34](https://realalpha.app/v/_FmwqPzqkjY/?t=4294) It's also important of, you know, good go to market in a way. The second was this book called Creativity Inc. by Ed Catmull from Pixar. And, you know, it talks a lot about how they built this culture of creativity into the company, which I think is probably very, very important for companies, especially today when so much stuff is changing and you can rethink everything from the ground up. Red flag in a candidate that you never ignore when recruiting. I actually changed my mind on this a little bit over the last several years, having hired so many people. It's not a specific flag, but rather that like gut feeling of something's a little off and I'm not sure I want to pull the trigger on this because there have been times when I've kind of ignored that and said, look, I'm looking at everybody's reports. Everybody loves this process. I'm looking at that background, it's amazing. I'm looking at, you know, everything that my notes from my interview and they answered everything correctly. But something doesn't sit right with me. And I used to say, you know what, that's okay, because, you know, I should be objective. Let's look at this clinically. And every single time I've been like, I have regretted that higher. And so now it's just

[1:12:37](https://realalpha.app/v/_FmwqPzqkjY/?t=4357) this unsettling, maybe I shouldn't do this that I now take very, very seriously when I have. Last question. So, you know, you've had a phenomenal run and it's just the beginning still. But if you could go back to the day you and Jesse were starting Decagon, knowing everything you know now about the journey, what would be the one thing you'd tell both of yourselves? Yeah, it is go faster and kind of play to win. The market is so much larger and moving so much faster than either of us had thought of at the time. So it would be go faster, hire faster, build faster, get out to the biggest customers faster because the need is real.

[1:13:16](https://realalpha.app/v/_FmwqPzqkjY/?t=4396) The market pull is real. You just need to go capture as much of it as quickly as you can. Great. Ashwin, this has been a pleasure. Thanks for coming on. Yeah, thanks for having me. CHIIPS