Free with a sign-in.
The best 11 min of 74
The AI founder advice you won’t hear on X | Ashwin Sreenivas (Co-Founder at Decagon)
Ashwin Sreenivas says AI founders should find urgent customer pain, then move fast to capture the market.
Knuckle Up with Nakul · Nakul Mandan
- Ashwin Sreenivas is cofounder and CTO of Decagon.
The best minutes
- 2:13Customer pain should shape the product before strategy4 min
- 13:09Decagon accepts coordination costs to preserve speed4 min
- 40:01Most AI companies need product-minded FDEs3 min
Also worth watching
- 7:57Decagon brings engineers into customer sales and support5 min
- 25:52Decagon uses bar raisers to protect its hiring bar3 min
- 31:18AI writes most code, but Decagon engineers remain accountable4 min
- 35:05AI shifts engineers toward judgment and EPD leaders toward alignment5 min
- 57:19Decagon fine-tunes smaller models for specific customer tasks3 min
Skip the co-founder backstory, office routine, sales-workflow discussion, and the quickfire round.
Full analysis · 6 min read
Real Alpha · Nov 8
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.
Free with an account
Read the rest of the analysis
7 sections, the 4 other voices it tests Sreenivas against, and what it means for you. Every episode we cut gets one.
Check your inbox
We sent a link to your address. Click it to finish signing up. Not there in a minute? Look in spam.
or
Signed up before? The same buttons sign you in. The episode, its moments and the transcript stay free.
Buyer pain gave Decagon its first strategy
Sreenivas said Decagon began by grounding decisions in current buyer priorities. He and Jesse Zhang avoided a ten-year plan while major facts remained unknown.
He did not ignore market selection when choosing the opportunity. He said they sought a favorable market, then used buyer conversations to locate shared pain.
For example, customer support kept surfacing with heads of customer success, service, and operations at fast-growing technology companies. Sreenivas described it as crucial, labor-intensive, and hard to manage.
Decagon sells an AI customer concierge platform. This is one company’s self-reported path, not proof every startup should follow it.
“what do customers care about and what are they willing to pay for today?”
Our read
Start with recurring pain and willingness to pay, then let evidence shape product and go-to-market. Treat this as one founder’s operating experience, not a universal sequence.
Customer access keeps product decisions close
Decagon puts builders directly into active deals and customer channels. When a deal stalls, Sreenivas said, relevant engineers join calls. Customer Slack channels also bring in engineers or product leaders.
That cuts handoffs, but it can compete with protected engineering time. Sreenivas said the company tries to keep builders connected without letting teams work in silos.
Alex Danilowicz, Magic Patterns’ cofounder and CEO, said on Lightcone in October 2026 that everyone handles customer support. Jake Stauch, Serval’s cofounder and CEO, spoke on No Priors that month. He said most engineers join at least one call weekly, and he thinks most join one daily.
Those routines are not identical to Decagon’s deal-specific routing. But each puts builders closer to customer friction. Teams still need to separate recurring needs from one-off requests.
“there aren't these kind of long chains from the customer to the person building the thing.”
Alex Danilowicz · Lightcone · Oct 22Daily customer support improves design without sacrificing speed
Jake Stauch · No Priors · Oct 29Serval puts engineers in customers’ daily conversations
Our read
Keep the feedback path short, but give teams a way to distinguish shared pain from local noise. Track whether customer contact leads to reusable product changes, not just faster replies.
Speed shifts cost into coordination
Sreenivas framed the trade-off as speed versus coordination, not speed versus quality. He said Decagon maintained its quality bar while accepting duplicated work when teams built similar things.
AI shortened the development cycle, he said. Work that once took two weeks might now take two days, leaving less time to coordinate before building. Take two teams building similar features in parallel. Decagon accepts overlap and plans to reconcile it once it becomes a problem.
That is a choice, not proof the costs disappear. Rework, inconsistent features, and confusion can still accumulate, though the episode offers no frequency or cost figures.
The same logic reaches beyond code. Sreenivas said Decagon’s five-day office routine helps coordination, while he and Jesse are in the office Sundays.
“we gave for speed”
Our read
Speed is valuable when the learning or shipping gain exceeds the rework it creates. Measure both sides before treating faster output as higher productivity.
Bespoke delivery buys learning before configuration
Decagon initially built enterprise products to fit individual customers, even in ways Sreenivas called unscalable. The later task was finding configuration points that could preserve tailored results across customers.
For instance, Sreenivas described an integration service for customer-built internal systems, with coding agents helping create integrations. That is a productization approach, not evidence that bespoke work has ended.
Large enterprise buyers have specific needs, and a tailored product can help meet them. But the account describes Decagon’s approach, not its measured scalability.
The episode gives no figure for engineer time per deployment or how much configuration reduces that work. Without those measures, the scaling case remains unquantified.
“we actually built basically bespoke in a completely unscalable way”
Our read
Treat bespoke work as discovery only if repeated requests become durable product capabilities. Track engineer hours per deployment and how often a configuration serves multiple customers.
AI writes code, but engineers own the release
Sreenivas said the vast majority of code at Decagon is written by AI tools. Engineers still need to understand, approve, and defend what they ship.
Decagon supports that responsibility with agent-friendly documentation and code structure, automated checks, security reviews, an internal application-security team, and external penetration tests.
Those safeguards matter more than which coding tool each engineer prefers. Yet this account is self-reported. Sreenivas gave no incident rate or review data showing how often controls catch defects.
Angela Jiang, Anthropic’s Head of Product for Claude Platform, described a related split on Latent Space in October 2026. She said Claude helps with implementation while people remain accountable for system design and quality.
“you are responsible for the code you push”
Our read
Budget for verification as code output rises. A practical test is whether engineers can explain and defend agent-written changes, not just merge them quickly.
Product-minded FDEs should turn edge cases into product
Sreenivas separates two kinds of FDE work. One delivers bespoke software no other customer may need, while the other finds missing capabilities that belong in the general product.
He says the second role is closer to a product engineer working beside users. The job is to recognize reusable needs, not only deliver customer-specific fixes.
Jacob Lauritzen, Legora’s CTO, described legal engineers configuring workflows and FDEs writing code on Latent Space in November 2026. That is a different division of work from Sreenivas’s two FDE categories.
The FDE label alone cannot show whether services become a lasting cost. Sreenivas’s case depends on converting one-off requests into configuration or product features. The episode gives no staffing ratio or gross-margin data to test that outcome.
“a product engineer that happens to sit next to users”
Our read
Classify field work by what it produces. Count one-off integrations separately from recurring product gaps, then watch whether those gaps become reusable capabilities.
Sreenivas says hiring capacity worries him most
Earlier in the episode, the host said Decagon had grown from zero to 450 employees within three years. Sreenivas said the company had about 20 to 25 cross-functional bar raisers for final interviews.
He said candidates need a clear strength, not uniformly solid scores. He also said hiring too slowly could leave demand unmet, while rushed hiring could bring the wrong people.
Sreenivas called hiring his top concern, ahead of competition from model labs. He said demand requires a team capable of serving customers around the world.
A bar-raiser process is a control, not proof of hiring quality. The episode gives no time-to-hire, offer-acceptance, retention, or performance figures showing whether standards hold at scale. Customer access, rapid product work, and enterprise delivery all need enough people. Headcount growth alone does not show that capacity is reliable.
“This is probably the number one thing on my mind.”
Our read
For a fast-growing company, the hiring question is capacity without quality erosion. Watch how quickly roles fill and whether new hires meet the bar over time.
What it means for you
- Test buyer pain. Talk to target buyers this quarter. Record repeated problems, current workarounds, budget owners, and willingness to pay.
- Measure coordination cost. Track duplicated work and rework alongside shipping speed. That will show whether AI-assisted building improves delivery or moves costs downstream.
- Audit agent-written code. Review a sample of AI-generated changes for engineer understanding, defects, and security findings. Compare results with review time and release pace.
- Classify field work. Tag implementation requests as one-off work or reusable product gaps. Measure engineer hours and how often each capability serves multiple customers.
What to watch
- Whether enterprise requests become reusable configuration rather than lasting bespoke work.
- Whether code review, testing, and security checks keep pace with AI-generated changes.
- Whether hiring capacity grows without lowering the bar Sreenivas described.
Send this to product and engineering leaders building for enterprise customers.
Watch the minute where the host gives Decagon’s employee count.
Written by Real Alpha from the episode's transcript and the other moments it links, then checked against the transcript. Quotes are the speaker's exact words.
Minute by minute
- 2:00Customer 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:57Customer 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:09Speed 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:43Office 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:24The 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:52Bar 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:18AI 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:05Engineers 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:53FDEs 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:48AI 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:06Humans 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:29Enterprise 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:39Hiring 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:53Fast-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.
Published May 19, 2026.
Transcript · 1 h 2 m read
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.
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.
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.
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.
Read the whole transcript
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.
“the only thing that matters is what do customers care about and what are they willing to pay for today?”
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.
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
“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.”
“you have to give somewhere and we gave for speed”
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.
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.
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.
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
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.
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
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.
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.
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.
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.
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.
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.
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.
“if you just have threes all across the board, okay, there's no clear champion for this person.”
Is there a cultural expectation that every employee at Decagon has to be AI native? Like their AI savviness across...
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.
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.
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.
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.
So let's start with engineering.
“you are responsible for the code you push and you should be prepared to defend it”
“the job of EPD leadership becomes to very clearly paint the targets of where we want to go”
And that's an interesting area for AI because, you know, it's a lot of FDE motion right now in AI.
You yourself were at Palantir.
“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.”
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.
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?
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.
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.
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.
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?
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.
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.
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?
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
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.
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.
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.
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?
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.
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.
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,
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.
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?
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.
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
“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.”
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.
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?
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.
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.
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.
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.
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.
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.
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
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.
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
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.
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.
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.
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.
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.
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
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.
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


