The Infra Pod - AI Is the Fourth Application Architecture! Chat with Dave McJannet (ex-CEO of Hashicorp, CEO of Dome Systems)

Episode Date: October 6, 2026

Dave McJannet — CEO of Dome Systems, former CEO of HashiCorp, and a veteran of Cloud Foundry, Hortonworks, and GitHub — joins Tim (Essence) and Ian Livingston (Keycard) to argue that AI isn't a feature wave, it's the fourth application architecture after mainframe, client-server, and cloud.Dave walks the stack layer by layer to separate what endures from what gets layered over: compute shifting from CPU to GPU and onto an inferencing layer, messaging (Kafka vs. Temporal) becoming more critical, not less, APM racing to monitor a new substrate, and a data stack that probably doesn't get rebuilt at all. He makes the case that agent governance is a DevOps problem, not a security one — the platform-engineering team that can't answer "what will this thing do once deployed?" is what's actually blocking enterprise agents today, exactly like security teams stalled cloud growth in 2015 before the cloud 2.0 playbook unlocked it.Plus: why he thinks the open-source business model is broken in a world where an agent can reconstruct your repo overnight, what replaces it as a moat, why heterogeneity of models is inevitable (and why India got there first), and a spicy take that vertical SaaS and the incumbents are far more defensible than the Valley believes.- 0:00 — Intro & AI as the fourth application architecture- 12:39 — Why Dome Systems: agent governance as a DevOps problem- 22:56 — Enterprise adoption, heterogeneity, and the death of open source as a moat- 35:49 — The Spicy Future: hot takes and closing thoughts

Welcome back to the InfraPod. This is the 10th from Essence, and Ian, let's go. Hey, this is Ian Livingston, CEO, co-founder, Keycard. Super excited to be joined by Dave and Janet, CEO of Dome Systems, former CEO of HashyCorp, and a long-time seller and thinker in infrastructure. Dave, happy to have been on the pod. Tell us, what in the world got you back to building? It's a funny little world, right?

The world of folks that are focused on infrastructure is a relatively small ecosystem of people to begin with. And it's what we like to do. We like to build the things that people can't see, but that quietly power the things that we all use each and every day. And I think this notion of platform transitions has always been the thing that has gotten us going. There's changes at the app layer. That drives new infrastructure requirements. and that puzzle is just sort of a challenge we find a hard time resisting. You know, as you were thinking about this sort of platform,

it was there some sort of insight? Was there something you saw that you were like, no, I got to jump back in. This is like the moment for me to like to do it instead of taking a well-deserved break of SashiCorp. Well, the funny thing is, as we're just talking about at the lead-up, as you sort of indicate, I've been working in the world of infrastructure for better part of 25 years. And the common thread through all of those is actually being platform transitions.

So back in the day, we sort of participated in the app server to platform into service transition with the creation of Cloud Foundry, this kind of created the new Paz notion, actually. To think about it, that's sort of was the first time it happened. We then left that and helped create a company that was around the big data transition. Again, platform transition from people running skill up systems to open source, distributed storage frameworks. And that lineage actually became what

Databricks is today, ultimately, that notion. And so, you know, Hachrop was actually really just like the most recent of the ones we pursued. I think the thing that kind of the threat to all of them is actually this notion of application architectures. And we were talking about Cloud Foundry previously. And, you know, Paul

Mertz was one of the key architects behind that notion of former CEO of VMware. And he would talk about the three platform shifts. You know, there was mainframe, there was client server and there was cloud, and each of them represented a new application architecture. If you think about application architecture being the thing that unlocks new application types, you know, for example, tick the cloud on this most recent, you know, before cloud existed,

you couldn't build things like DoorDash and Uber and those sort of stale up things that we all take as the norm today, things like Zoom, right? Well, Zoom, it presupposed infinite compute, infinite networking availability. It's a cloud construct that you could not have built if you were building them on traditional infrastructure. You know, for example, like one of the tax filing services we built middleware four years ago used to have to scope their infrastructure for April 30th every day. That was because they needed to have everything idle until that day. And so the way you build it out because it's very different.

I think when you look at what AI is to us, it really is just the fourth application architecture. And so when you stare it at it goes, well, the thing that makes it really, really simple to understand is it is a new application topology. It used to be in the cloud generation, a piece of code talking to a back-end system. And every time I ask that question, I would give the same answer, and I can scale it up and scale it down. But fundamentally, it's a deterministic piece of software following that path. But now the application architecture is a piece of code talking to a model, talking to a backend system. And so it unlocks these completely new application types.

So things like self-driving cars, things like chat assistants that can fill in your forms, is because it has an application apology. That notion of application architecture is, I think, the most interesting thing. I think, obviously, it's a different type, but there are a lot of parallels to project what might be required with infrastructure layer when you think about it through that lens. And with this platform shift, you know, there's just a final change. I'm curious if you have, you know, is your one pinpoint place you think that here's that's actually like funnily changing with the movement towards agents and AI that's so different

from what came before, like is there something that you've isolated around? this platform shift that you're really focused on or catches your imagination. It's so much as like the movement from, you know, rack and stack up servers to cloud or from, you know, using stuff like puppet and moving towards like more reactive infrastructure. I'm curious if there's one specific thing

or a set of things to stick out in your mind about this. Yeah, I think like the puppet one's a good example, puppet just a good example, where I think, you know, that was sort of a new infrastructure reconstructed came out of an application platform evolution. And I think the lesson is it usually takes a couple of years, two to three years after the application paradigm becomes obvious for the infrastructure to settle down enough for you to know what those new

premises are going to be. And I think that is a little bit of what's happening. I think things like Poppet and Chef were created actually a little bit before the notion of like immutable infrastructure and everything has an API that enables things like TerraFarm to actually become the standard way as opposed to the previous way. It wasn't there. It was wrong. It was slightly early. And then it turns out the market paid out a different way because the primitives of cloud ended up being immutability, APIs everywhere, cattle, not pets, kind of the notion. So I think that's a little bit what's on our mind is sort of

like, hey, now it's been maybe three years since the Jackie Dement. Maybe it's four years. As the infrastructure substrate settled down enough that I can now start to identify what those components are going to be. And I think that's the bet that we make. And I think, you know, the timing ends up being right because now you can see actually, If you think about an agent is just a piece of code, calling a model, calling some back-end systems, it actually is a lot more manageable than you might think. Now, there's some idiosyncrasies that are new, like, things like identity. I know you guys are focused on that aspect to a large degree.

Yeah, do we need to reinvent some of those constructs because now you have, you know, identity as a sort of a new element? You know, TBD, I think what I do know is that you have a piece of code, talking to a model, talking to some tools. So basically, if you're going to treat the agent as the thing you want to govern, you need to actually figure out what are those standard kind of connectivity points, and then how do I provide a set of capabilities to govern what that thing's going to do rather than governing the endpoint itself, if that makes sense. So I think this notion of, oh, you can start to imagine

what the whole thing might look like now that the infrastructure elements are clear. We have MCP gateways, we have model routers, we have code. God, okay, well, you know, my personal view is, I think, that it's timely because of strifying open router recently, what I saw just on Twitter, they're like, well, is that a market or is that just a component? Like, I would, I would pause that. That's actually just a component of what the actual problem is. The problem is how do you govern agents, not like how do you broker what they're going to talk to? So that makes it a capability. So I think what really interests us is that? It's like, what does actually the picture look like two years from now once all the stuff is settled

down as ever, like we make bets as to whether it's going to work out the way that we think it is? And we might be wrong. We might be right, but we'd like making those bets. That's, yeah, it's super insightful. And it's a good thought process for thinking through it. I really like the way that you framed is that it's a problem. What's the problem is the market? You know, and what are the enduring pieces we don't really know. I'm curious as you think through this transition and as you're thinking through, you know,

with your experience, which is innumerable. Look, there's this ultimate debate in the Valley and Infrastructure, Tim and I talked about a lot, is like what pieces of, and one of our friends, Martin Cassato always says to me is like infrastructure always just gets layered, right? And I'm curious which incumbents or which piece of infrastructure we have today continue to have like real returns in the next generation versus get layered. Like a good example would that be like IBM's DV2. Like that thing got layered. It lives inside some very specific plans of service institutions.

But certainly like from the mind share of developers, it is not in our mind share anymore, right? But there's still a business by definition, but it is not a relevant piece of infrastructure. I'm curious if there's parts of the stack that you've thought about, hey, I think these things become less relevant over time. This stuff's going to become more relevant because of there's change and sort of like user interface or interaction patterns or value chain. I tend to think market first. If I withdraw visually what's kind of happening,

you're going, we have new kinds of applications. Those always drive new requirements and infrastructure layers. So what are those things? And how does that compare to what's already there? So if you think about layer by layer, you've got chips. Okay, well, I used to deploy things. on CPUs, now I'm going to deploy them on GPUs. Right. So that basically you're going to see a transition of workloads from CPUs to

GPUs, you know, lots of reasons why there's new applications should, you know, preferentially be deployed on GPUs if they can. The layer above that, I have my core compute, IAS services like compute EC2. Okay, well, now I have an inferencing layer. So actually, you're still going to be deploying things on EC2, but actually more of your application you're going to get deployed on an inferencing layer rather than on EC2, just because there are those new kinds. of applications. So in that sense, maybe it's slightly less relevant, and that's why Amazon's

investing in Bedrock and the Bedrock stack to be able to say, I could be your inferencing provider. So I think huge shift in terms of compute volumes over to that GPU inferencing layer. And then on top of it, I think you say there's going to be agent layer, which used to be app platforms. Now it's agent platforms and you got Bedrock. Agent layer, not surprisingly on Amazon, they're making their bet. So I think there's sort of an equivalent stack being built up the side on those three layers. And I think you then ask the question appropriately, which is like which things are enduring. Well, I think in infrastructure, things like message queuing, pretty enduring. Like, does that take a slightly different shape? And I argue, actually, I think the more

we work with the stuff, the more we realize it is actually service-oriented is the right way to think about in terms of triggering the next stage in downstream. So I can have topic connections, cue connections in the JMS sense, or like just like subscribers downstream of things. I think that messaging becomes super super important. Now, is that Kafka or is that temporal. You know, I think that's TBD, but I think both of those things end up being super relevant because messaging is super important to this new architecture. And then on the side, I think about APM, how do I monitor this stuff? Actually, I saw the Dinotrast made an acquisition of an AI native APM system, which I think of an acknowledgement, actually, that actually,

just like the CPU-GPU shift, an increasing proportion of monitoring workloads are going to be monitoring this new substrate, and therefore, companies like Dinotrace and did it all, we'll sprint to add this to the portfolio. So I think in that sense, I think that the stack looks very, very similar in core compute messaging, monitoring. You can try to just describe how this change. The question becomes what about data? And I think actually, you know, data is sort of this general need across both GPU-based things

and CPU-based compute loads. Is there a new data stack? I don't know that there is. I think people like Databricks and Snowflake have made it clear that for the data warehousing workloads, they're going to benefit greatly because there's a lot of new applications being deployed that are using that data warehouse. For the OLTP type workloads, I think Postgres has made it clear that it's going to probably going to be prevalent for the OLTP based workloads. And obviously, Postgres as a role in their data works as well. So hopefully somewhat structured answer to your question, which is, you can kind of see like there's almost an adjacent stack being built up.

The new workloads are being deployed on that. I think message queuing probably pretty enduring, monitoring, pretty enduring with some tweaks. But I think the rest is sort of wide open. Curious how you guys think about it. Yeah, I think Ian probably has his own perspective and we'll let him chime in at the appropriate times here. I'm actually very curious. I want to actually lead it to the Dome Systems, the why question here. And, Dave, knowing your career, you know, working at Cloud Foundry and, you know, HashiCorp and all the things in between, in my way of looking at it, seems like a lot of products you were working on is almost like enabling products.

Like back in a night, Cloud Founder, enabling people to even get to a past. People don't even know what a past is, right? It's like if there's such a new concept for folks, we have to explain, you know, Google, whatever. Hortong works, right? Big data is happening. But at a time, it's such a new concept as well. People are just looking for enabling technologies. And I guess, Dave, this is such a fun time.

You're the first time, zero to one founder, right? And I'm just curious, why did you pick almost like this agent governance security space to come in? Do you see that the timing of where we are, the AI and agents, this is the biggest missing piece? It's a found it so interesting. Even Hashigorg was more of an neighbor tooling and added volts out later on, right? But you're kind of like going like, you know what? I'm just going to take this whole security and government. Maybe talk about the reasoning why you jump into this part of them.

I actually think it's very similar, actually. I hadn't thought about it, but you're right. Like the mission statement of each of those, it was enabling. So actually, Hortonworks was about enabling a modern. data architecture, Hoshrop was about enabling the cloud operating model. GitHub, that positioning we created was about empowering developers to build great software. So the ThruLine is actually this enabling role. And I think what we're doing here actually is very consistent.

And it's kind of what infrastructure does. We used to have a brand statement at Hoshbrook, which is infrastructure enables innovation. It's actually a profound way we think about it. It's like the rails that people then build upon to do interesting things. and you could build a litany of things. So I think it's actually very consistent with that through line. I think that the thing that's getting in the way of people deploying agentic applications is, in fact, the constraints of ops and security teams that are blocking them.

So until you solve this problem, those applications are not going to see the light of day. So in that sense, it's an enabling function in the same way that is just about unlocking people to be able to deploy applications in this near model. So it's not a security thing per se you're selling top down. It is actually more of a DevOps platform for agents that allows it to say yes. The parallels are actually really good to cloud. If you think about we have this sort of obviously this inside track view into what stop cloud and then what made it take off again.

And what happened in the cloud instance was we basically would say it was cloud 1.0 whenever we were sort of swiping their credit cards, building new applications. And then there was this period where option security teams to shut it all down. And actually the cloud providers saw a massive decel in their growth rates in like 2015 until people in the big companies sort of got to Cloud 2.0, which is how do I centralize a sort of platform services that I'm going to, you know, things like centralized IAC, centralized secrets management, centralized service measures, centralized platforms like Kubernetes, so that I'm going to stand those up and you can deploy 100 times a day as long as you

go through my aperture. But if you don't go through my aperture, you can't go to cloud. And that Cloud 2.00 moments what made the whole thing take off. So what we're doing is exactly the same thing is right now all those agents are getting blocked because the platform engineering team can answer the question, hey, is this going to be do anything that I don't want once gets deployed? And so in that sense, the parallels are right there. This is enabling tech for platform engineering to be able to allow apps to get deployed. But it's not a security thing per se. It's a DevOps platform for the bottom up.

And to tie to what Ian's describing, you know, identity is one of the key enabling things of how people get to yes. right? And so we're not trying to be an identity provider. We're saying, hey, like, maybe key card's the right model for doing your femoral credentials for what agents can talk to. But there are other problems that that agents have that are more operational in nature that we're focused. So we would integrate with something like that. You asked me a question before, and I wanted to respond and what do I think is durable? What do I think advances? And I think like your analysis on CPU versus CPU is really interesting. I think the other like ratio that's interesting at the infrastructure layer is the fact that like, as we've seen, increase in GPU consumption. We've actually seen this massive supply shock on the CPU consumption, right? So it has this very interesting TikTok relationship as we've become agentic,

which then is, you know, very good for businesses like the one that you're building, and very good for business like the one of the key cards building, right? Independent is we try to like shift to a Thomas software, that changes. And so if I had to like frame my question as what am I going to be long on,

or am I going to be short on, right? If we're like playing like stocks, I'm going to be very long on core infrastructure, very long on core compute. It's pretty clear that I, platforms like abus and Azure are not going to go anywhere. In fact, it'll be more valuable. They're going to be able to capture significantly more margin because they need the layers of distraction that are required to operationalize or increase as well. I think it's also interesting.

The things that I'm short on are UIUX, right? Broadly speaking, the way that the interaction between humans and computing is changing and that actually results in those needs for those new compute layers that demand for GPUs and CPUs. But at the end of the day, like the interaction pattern between humans as the computer are drastically changing, which is, you know, KeyCard's like whole position in life is basically, look, we used to believe in this world that, like, humans point and click to the road every line of code, they did all these things. And that's a very different world than like the one where like a human, you know, describes intent. And then an agent has to like go and perform actions. You kind of have this like weirdo dynamic bounding box around that based on what the intent is, broadly speaking.

If I step back, I think there's a renaissance where there's a whole bunch of pieces of information. that were built around an interaction model that made a lot of sense in the 1980s, 90s, and the 2000s, right? And then is that interaction models, the things that be short on infrastructure, things that, like, were specifically built for that. So I think web browser is a good example of a piece of, like, code that we work with every day. But, like, what's the web browser going to look like in 10 to 15 years? Who really knows? It's unclear to me, right? Which also goes with all those UI testing frameworks and all the infrastructure around, like,

Selenium and all those things, like, where does this go over the long term don't really know? Because ultimately, as we know, what agents are goal-seeking, and also they'll find the most optimal path, which will tend to be, you know, things that are API-driven one way or the other. Yeah, and I wasn't really considering the sort of anything other than like core infrastructure constructs. Yeah. You know, the front-end stuff, totally agree. There's a whole other cutter. Things like firewalls and that sort of thing.

You know, where do they fit in this near world where you're giving an agent and tasks? You're actually, one of the reasons you want to use an agent is because you actually, wanted to use judgment to go and get around different things. So using these determinants to control some block and becomes an anti-patter. So I don't know. I'm not smart enough to be an investor, but I agree with your view that certainly the front end is all changing. We can see that every day, like the way my day-to-day works is pretty different than it was a year ago. And I kind of feel like we're living in the future a little bit, actually, because so much of my interaction is in this model and agents doing tasks for me and informing me. And that's just a totally

different workflows than a lot of infrastructure was built for previously at the finance certainly. But on the back end, yeah, I'm long compute and infrastructure, core infrastructure myself. One of the questions, and you're really curious to pick your brain on this one is, well, I think there's like two threads. You know, classically, you've sold to the enterprise

and mid-market, you know, infrastructure. I think there's like two conversations that are going in the ecosystem today. I love your view. One is most people view it is like the enterprise hasn't really woken up to AI or agents at all. And it's interesting because there's recent data that like 1% of users use like 90% of tokens or something. Interesting like that. That shows it like very, very, very early in this wave.

I think the second component is, okay, so when the enterprise does tick over, and I think I know what you're going to say, but I'm curious for your perspective, how do you think the enterprise is going to approach building sort of their like agentic strategy, knowing that your options today are kind of like what they were last generation, Instead of you kind of have open AI, you kind of got Anthropic, or you've got like open source models. Last generation was like you got your Azure, HGCP, you got your ABROS. Like, how do you think about the evolution of that market and infrastructure at large, especially given how early we are in that and the initial like rollout here.

Yeah, a bunch of questions in there. Make sure I get the first one, right, which is, hey, this is the purview of small tech forward companies today and not the enterprise. And yeah, absolutely. We see that every day. You see it every day. But that's always how it works, is right there. It's sort of the Defectorymore Technology Adoption lifecycle is there for a reason. And what we've learned in prior shifts is actually the application or the infrastructure architecture architecture that the enterprise adopts is actually going to be the one that gets worked out by these early adopters.

And so they matter a ton because the enterprise will just adopt those patterns because they're proven. It happened in cloud, happened in big data. and it happened that way. So it'll happen, and it's just super, super normal. I think the second question was, how do you think enterprises are thinking about it? I think there's just so much of risk, obviously, and what will make a tip?

So I'll actually want to make a tip before I answer the second one. I think what you're seeing at every enterprise right now is here like this buildup, and it's always a developer first, of people building these new kinds of applications in this new way, and are just itching to have them deployed because they are so much better than what's out there before.

At some level, like this application architecture is just composite application development. It's like the middleware market recast from 20 years ago, and now I can book composite applications really, really quickly. And guess what? I don't even have to think about data mapping or adapters or keeping them up to date. So it's a very, very compelling way for developers to build problem,

to solve problems that have in front of them. And so you've got this rising pressure inside the enterprise for the kinds of agentic applications that we're talking about. And I think eventually that's what it breaks it, is that pressure. You get business units that just start going a bit rogue, and it just sort of starts to happen. And that's the AI1.0 moment that'll happen, and they'll get their hand slapped, and they'll figure out how to go around it. It's going to be developers that push that up because of the new applications they're building. How do companies think about it?

You know, the truth is, they don't even know how to think about how to govern these things right now, because there's so many different categories and ways to think about it. And they don't even know how to categorize it because there's this top-down mandate, you must do AI. So they've given cloud code to every employee. And then they're like, whoa, now people are spending too much and they're billing things I don't want. I got agents running locally under laptops. You're like, what have I done? Okay, let's get done under control.

Then I've got my AI as a service apps that I brought in that are probably using my data in some way. Like, those are agents. And then I got people building custom apps. Like those are agents. And so they don't know how to decompose that taxonomy. I think that's the first thing that has to happen. There has to be a taxonomy that gets projected, allows people to figure things. out and they will figure out how to do that. Once they've done that, then they'll start to,

you know, think about how do we put the governance in place that then allows to say yes, and that's the AI2.0 moment. So I think this is just going to go on for a while. It's very, very predictable. When is that time? Is it 18 months from now? Might be. I don't know. I think obviously it varies by vertical. And, you know, some verticals are very, very proficient out of the sort of stuff. Historically speaking, people that have platform engineering organizations where people like banks and people like, you know, retailers, people that were building a lot of applications. Those people tend to be able to adopt the stuff quicker than others

because their orientation is up-de-f. It will happen first in those companies, but they got to figure out how to create the taxonomy first and then figure out how to provide the compliance guardrail second, and then they can let the wave go through in the interim. It's just going to be a bunch of whack-a-mole of individual business groups doing their thing, and that's just, you know, AI1.0 is how it's going to go. But it's the developers.

Yeah, I feel like A1.0, as we speak today, I didn't even know when two point it will happen. It seems like it's probably already happening. Every enterprise I talked to and friends with are all kind of in the figuring out phase. But I'm curious for you because I'm reading your perspectives on your website, you know, looking at Dome Systems. There's obviously the platform and there's a lot of like, hey, this is what you should think about as enterprise.

And a lot of it is coined around the governance site. I guess you're talking about IT. People need to able to like control your top of the product manager doing an agent at some 2 a.m. and go rampant, right? I'm very curious because it seems like, like you mentioned, most people are still in the figuring out phase. They don't know exactly how agents, what time frame, what would go wrong.

Things are already getting a little bit wrong. And you also are talking about your solution already. I saw you have Cedar doing authorization policies. There's like already a stack you already have. I'm curious, like, are you already working with people that already have agent at certain scale that know exactly kind of what they need? And you're here with opinionated stack,

almost like, okay, I know how to help you get more organized and governance and ask the way you want to be working with. Or almost like back in the day, make sure you use terraform first, make sure you use something else first, you know, and once you have us in any place, lets us connect the dots for you later. That's my impression at least, right? Yeah, yeah, I think we're sort of, so the short answer is the company was started at the beginning of this year. So relatively new, we spent that time working with dozens of enterprises that you can imagine. We've been in this market for a while. We have folks that we've built tech for in the past. So we've had a unique access to hear what their problems are.

And, you know, what falls out of this is sort of a couple of conclusions. There's going to be heterogeneity. Maybe answering Ian's question previously. There's going to be heterogeneity. It can be heterogeneity of models and there can be heterogeneous platforms. And it's actually worse than in the cloud era. In the model side, you have, you know, open a anthropic, you've got a handful of open source models. And then actually I came across this in India last year when I was traveling.

It was super interesting just to see how sophisticated they were and how forward they were on actually running dedicated small language models for specific tasks already to support the kinds of applications. And that tells me there's going to be three categories, right? Those big ones, the open source models and then the small language models. Then on the platform side, it used to just be Amazon, Azure and Google, but now there's also service now and Salesforce and everybody's a, everybody's a runtime platform. So conclusion, heterogeneity.

And you're not going to be able to stop that. I'm going to build an agent on Salesforce that connects to something on AWS. Why? Because the data is there and have a good reason to do it. So if that's the view, we kind of know what it will look like in the end, which is typical enterprise will have heterogeneous models, heterogeneous endpoints that they're working with. And so the only practical approach that can go to solve it is how do I just have

consistency of operations for how to do that. Again, we're much more DevOps-oriented than we are kind of be pure security. we're saying like, yeah, connect to an identity provider and enforce identity. Like, that's not us. We're just saying you need to bring that across in a relatively opinionated stack, which says, let's have an opinionated stack of how you connect to models, tools, and agents, and then let me apply authorization controls to that staff. Because we think that's just what it looks like in the end.

So in some sense, we fast forwarded to the end of what we think this looks like, but it's very, very informed by, you know, dozens of enterprise conversations of people that are kind of going down this cop, but you can see where it's going to end up, maybe as the takeaway. So going back into the perspective of your history and projecting forward, most of the companies, you worked on our open source space, right? Cloufondry, Hortown Works. Alas, it's for Dome, I guess, I don't see any open source yet. Curious for your tape, because Hedrogenius was going to be such a big part of this and this much

to larger surface than ever. And there was usually some, portion of that, the hope sometimes open source can come in to help create a community of effort to maintain some standardization, right? That's usually part of the thought process here. How do you view open source now, given you're starting a company from scratch? Do you want

to pursue something like this? We want to do something in open source space again? Yeah. People often ask about sort of the open source because they look at that consistency, but the reality is like the open source models changed a huge amount over that time. It's

In fact, like, the open source model of the Hash forp has actually almost no, very little in common to the open source model of a cloud foundry, an open source model of the Hadoop ecosystem. People need to keep in mind that actually there was a way to build open source businesses in the past that I think can't be done the same way today. And part of it's around the ecosystem maturity. A lot of it's around the incentives of Amazon, Oracle, and VMware and other folks who are actually the backers of the open source foundations. But I think the most important thing is actually the reality of AI, right?

I think the minute you make your repo is public, how long would it take you to recreate Kubernetes a day? Maybe, right? And so in a world where an agent can operate at machine speed to deconstruct that I think the downside of open sourcing any IP is incredibly magnified. And so I just think that makes it a very, very difficult business proposition down the road. that is different from before. Where open source has been super, super helpful in the past is actually around standardizing interfaces because integration surface area is the hardest thing to solve. But I think in the world of agents, it turns out it's not that hard anymore.

So do I need everybody to figure out how to create a common provider for how to plug in bedrock? No, because the API is public and I can run an agent every night to update the API to make sure that it works tomorrow. And it's just to solve problems. So ergo, both for the business side and the tactical side, I just don't think it's just not a model that works as I'm ready than it previously. What do you think the new moat is? Like, brand is still obviously a moat, but like, are there other modes? You know, one of the things that open source did do for people last generation is to help

create a moat in the sense of like there's a brand, there's a thing, you have people to start, there's the forks, the contributions, kind of turns into this sort of like little run-orice snowball and you can kind of monetize on top of that now, like, without that, that's gone away. And so I'm kind of curious, we're in a world where software is quickly becoming free to create. I wouldn't say actually free but near free. So I'm curious what you think the new ball of spaghetti is that actually keeps you differentiated and recurring over time. I think a lot of our structure.

You're right, like the moats are smaller than they were, but a lot of it's structural. One of it is sort of where does this exist in the market position? Is there a need for this in the market as a thing? Number two becomes around the brand of trust that you can build, particularly in the world of infrastructure. It's really, really, really important. I think number three ends up actually being the velocity of innovation,

and that's driven by your unique data flows that you have access to. And I think that's the thing that is more obvious to us over time, is if you get the architecture right, actually building capabilities can be done very, very, very quickly. So, you know, what we've done, for example, we've committed to this Aonative way of doing things in a particular architectural approach, and therefore our velocity of innovation actually has gotten faster,

faster, faster as we've gotten bigger, as we've got data to inform what we do, we have sort of the machinery in place for how to basically our own version of the AI platform engineering controls that dictate how we develop, how we think about code structure, such that we can actually,

as we learn, we can deliver capability faster, faster and faster. I think that slope of the line matters a lot. It's something where you're seeing a lot of the software markets where people that are not AI native in this respect, they just can't go as fast.

And it sounds like a trite thing, but actually you compounded over a three, for six, nine-month period. And actually, it is such a lighter difference relative to how somebody else can do it, that the product looks completely different. I mean, you can't even imagine a roadmap four weeks in advance right now, given how fast we can deliver things. And I think that advantage compounds. So I actually think people that are not built in this manner have a structural disadvantage. And you sort of have to, in some respects, rip the rug out and go build this advantage and say, like, as the models get better, how can I ride that curve? And I don't think that's just for

the product development process. I think that's actually for every process. I think of every business process, how you do brand design. You know, if you think that as an example, like, if you commit to this model, your ability to innovate is just so much faster than anybody else. I think that really really starts to matter. And that's good for customers in the end. The bar has now just gotten way, way, way, way higher. And that's harder for us, but it's better for our users. And maybe that's just how markets work. So I think that's the third one. Number one is structural. Number two is, yeah, this brand of trust. And the third one is, I I use data to get better faster.

Yeah. So your view is like, okay, I need to build a self-building system that creates a sort of like autonomous software that buyer is buying. And that's also how I built my business to a certain degree. And it's like it's those reinforcing circles of improvement, if you will, which sits on top of the models of self-improving as well over time that actually drives like the flywheel for the business. Yeah.

And I would say it's autonomous because it's not really autonomous, but it is, you know, because it's always us driving a bit. It takes a system-oriented approach to get your head in a way. How do I do the system design so I can actually have as much automation as possible for every business process? Yeah, I think that is how it goes in the end. And like I said, that's good for our customers, but it creates a really, really high bar for us. But it compounds. It compounds.

And I think that is, that's the opportunity. And I think this AI native approach is still relatively new, right? It's only a year old. And so there's a bunch of companies. And if you're in the valley, people say, wow, they're just moving so fast. And you kind of brush it off. It's like, yeah, they're moving fast. But, like, actually, you compound that over a two, three-year period.

And there are orders a magnitude difference between companies that build that way versus those that don't in terms of what the products look like. So, Dave, I'm very curious. What is the example, since you, you know, started this company just this year? What is something you start to look at or even structurally you can pinpoint an example for our listeners? that is of example of compounding that you don't see past generation of companies, just even a few years ago or not doing. Is there something you can pinpoint? I'll take content generation, right?

So the example is, I think the challenge a lot of people are faced with is if you're using the additive SDLC, the pace of product output is just so fast that how do you actually not overrun your go-to-market organization's ability to consume it? Because the product changes so quickly. So then we've all built tooling, which is converting, hey, let me have things that look at our GitHub repos and look at what's got constructed, and then use it as if I put in place common frameworks, how do I then translate that into updated, go-to-market elements? How do I then automate every aspect of the bill of materials that comes

out of that, because it changes every week. And so I think that's an example of stuff that just compounds if you invest in actually practically speaking, building an agent that does that, you know, the velocity of what you deliver visibly matches what you're actually delivering in product. This is maybe an example of it, but product development is the most obvious one for those of us that are all close to it. You kind of see once you've got sort of your workbench plus the platform engineering controls centralized that everybody on boards and consumes, it goes faster and faster and it's actually the models get better and your code base becomes appropriately structured, like, yeah, your development cycle is faster too. You've got a compound.

All right. So we want to jump into our favorite section of our podcast. It's called The Spicy Future. Spicy Future. So, Dave, give us a spicy hot take that you believe in and most people around you don't believe in yet. I don't think we're that controversial. I think the models are magical. I think the magic of those things impresses me every day. But markets like heterogeneity. My prediction is there's a huge amount of hype around this particular moment in time, but I think it will settle down into there'll be heterogeneity of models. And I'm pretty bullish on that reality that there will be open source models that we can run locally. There will be dedicated small language models for specific tasks. And that's not that controversial, I don't think. But I think that means that the idea that Open AI Anthropic are going to take every vertical SaaS opportunity to,

I think they're more defensible than that might appear because, you know, take a Harvey or whatever it might be, they're going to run their own models that are run on an inference poster that are actually optimized for that specific task, and they will do it better than the general purpose models. And so perhaps the death of the vertical SaaS companies is exaggerated. I also think that companies like some of the more traditional ones have a much more likely chance of being just, fine than people are imagining. People go, oh, it becomes like service now or Salesforce, whatever, they're under pressure because

their new AI options. I think to the extent that they lock in and commit to building, treating agents as a first party citizen to their platforms, they will do just fine. Because I think the thing that people forget is that it's really easy to build technology. It's very

difficult to take it to market. And they have an install base as long as they innovate will be just fine. So maybe those are the three. Number one is heterogeneity. Number two, That implication then is some of these small vertical AI companies have a good opportunity. Number three, so are the big ones. And so just responding to your spicy hot tag,

and maybe one comment just mentioned earlier, that you went to India, you saw how AI4 they are, user are using specialized models and stuff like that. I'm curiously, from your observation so far, what are the companies already embracing heterogeneity even more earlier than others look like? Why would they do that, right? Why is surprised you when someone there or other markets, right, already embracing it pretty early?

Because I do think there is, largely speaking, everybody just thinks, okay, everybody can start with, of course, the frontier models, right? You know, and maybe slowly. But it feels like, yeah, the world is probably moving in very different directions and many different places at once. So just curious for you, where do you see a heterogeneous starts, right? And what kind of people and places they are starting already that we don't know of? I think it's much like cloud, whether by accident or by design, you will end up multi, is the truth. So it happens by when a business group is trying to build something specific in an enterprise. I'm working with enterprises, and they just pick the best thing for their task,

and that's going to be different than the corporate one just because they're a business group. So that's how it happens. It happens by accident in those companies, and then someone gets fast, look like how to harmonize it. How does it happen by design? I think it's a bit like the mobile phone thing. A lot of these countries jumped landlines, I'm stripped a mobile phone because that was just where they were in their cycle, and perhaps they couldn't invest in the infrastructure to do that.

And so in some of these developing countries, not surprisingly, they're going to look and say, like, I can't afford the frontier models, and they're by default going to say, well, let me figure out a model that is going to work for me, and that ends up being a small language model run on an interesting host to write at that super, super low margins. So I think perhaps in those countries where there's not surprisingly cost pressure, they're going to start with the architecture approach up front because they rank that much higher.

So India is in that category where huge, huge numbers of people, the volumes are insanely large. And as a result, they could never contemplate running some of their business processes for the frontier models, given the margins that they can then charge on the other side of it. So they had by design ended up, you know, multi. It's not, I'm sure they use the frontier models for certain things, but not for things that are quartered their business. I'm curious, one of the things I encounter oftentimes is inside organizations, but like one platform over like everything. It's like they, it's not like they are using cloud codes. It's using some bucketed up version of plug code.

They put behind something and the interface is like some weirdo component tree. What do you think the underlying factors in the organization that drive that pattern that we're? seeing. I just, there's this natural desire for control, but in practice, it's just not how stuff happens in big companies. These sort of boil the ocean things don't work or the very, very rarely work, but someone tries and then eventually the shadow AI or shadow AT pops it up somewhere else. And it just doesn't end up working that way, generally speaking, even though people try. And I think being treated to folks has to be, how do you get to yes? Like, what's a model allows you to get to yes for these new applications?

and maybe it's is acknowledging, hey, you know what, there are only three or four core services that we need to expose to the S. Number one might be a common approach to identity. If we think that's the core control point for agents, like, you know, we're going to make sure that that service is available. But we're not going to force a common, you know, every single thing everywhere. That's just not how it works. They're going to decompose it into a common set or a set of services that are composable that they want to then expose to people that they might try to these. something bigger just doesn't go that way. Maybe one last question here.

Get to such a long history or career, I guess, what is the most, maybe either surprising or a thing you have to unlearn to go into this AI day and age, you know, to do this now? Is there something that you didn't even thought of before you started dome? And now I was like, oh, wow, this is something I probably have to do differently or something like that. I think it's every workflow is different. So, you know, one of the reasons we actually decided to do this was because we wanted to

experiment with building something. AI native that wasn't encumbered by previous things. And so every workflow. So just take, for example, the way that you would do customer support, take that as an example. Well, historically speaking, you had a bunch of agents or actual people, actually support calls. Then a few years ago, then that became, hey, let me use some kind of machine learning algorithm to determine what are the three most likely things to put in front of that person as a resolution. And then I can get my yield rates down. And that's how you would use AI to do it. Now what you do is you say, no, actually, I'm just going to create an agent that has access to my Zen desk, my GitHub repo, my linear,

and actually, and it sees the same three supporters just come in. It'll just create the fix and put it in a pull request for me to accept. So the entire business process is completely different. So I think what maintains is like, hey, there are financial systems, people systems, product system, go to market systems in every company. What is different is how they actually work. And so you sort of have to approach it with that level of like, I need to think every business process needs to be rethought in a non-native way. I think software development went through the same process, which is initially it was,

hey, maybe this is about co-pilot code completion, and that's how I'm going to get things. Well, actually, no, the right answer is step back, think about the overall SDLC, and we imagine it in its entirety, and turns out that's 10 times faster than that you've done before, but the same thing holds true for customer service and every other business function in the company.

Yeah, and large companies, or even lots of interesting stars are born at this space as well. Totally. It definitely been very crazy times. We have so much questions, but interest of time, we want to kind of wrap it here.

If folks are interested in Doddome systems and infra listeners are intrigued, or Shadow IT is such a big problem for them. Want to either learn more or reach out to you. What is the best way to learn more at Dome or are you? Yeah. The best thing is if you were in this path of wanting to be able to say yes, to ejectment.

I just encourage you to take a look at dome systems. AI as a whole bunch of resources that describe how we're thinking about the problem that are perhaps legacies of having helped people through these processes in the past and then applying what we've learned from the last few dozen companies we've engaged with over the last nine months to come up with a relatively practical way to think about it. So if you're trying to get TES for agent deployment, we can probably be at service. Awesome. So there's such a great chats and thanks for being on Dave.

Thanks a job. Much. Appreciate it.