Why AWS and Azure Cannot Run Autonomous AI – Ivan Burazin (Daytona)

We are a part of this like super cycle right now and the super cycle does not last forever and so if you're going to pause by the super cycle you are steing

market like that is what you are doing I would ask claw can you go fetch the data from our bank and then it was like oh yeah just log in and give me access like login give me no I will not give you

access right away fundamentally for me that was like broke the entire thesis of it so you give it its own machine when I think about agents I think of them as

digital knowledge workers. And to do anything as a knowledge worker, you do need a computer. My argument is that every agent will need at least one sandbox, sometimes more.

Hi, I'm Matt Turk. Welcome to the Matt podcast. My guest today is Ivan Borisin,

podcast. My guest today is Ivan Borisin, CEO of Daytona, one of the most talked about startups in agent infrastructure.

If you've been hearing the word sandbox in every AI agent conversation and quietly wondering what it actually means and why it suddenly matters, this episode is for you. We go from first principles, why does an agent need a

computer at all? All the way to the deep technical end, why Daytona had to throw out Kubernetes and write their own scheduleuler, and why a global CPU shortage might be coming faster than

people think. Ivan also unpacked the

people think. Ivan also unpacked the full agent stack as he sees it, models, sandboxes tools MCP memory orchestration, and where each piece is heading. Along the way, Ivan shares some

heading. Along the way, Ivan shares some really interesting lessons on go to market and distribution for technical founders that he has learned through 16 years building developer tools startups.

Please enjoy this great conversation with Ivan from Daytona.

Hey Ian, welcome.

Great to be here.

So you have said that every agent needs its own computer. What's the simplest way of explaining that idea? Well, when

I think about agents, I think of them as digital knowledge workers. And to do anything as a knowledge worker, you do need a computer or I should say anything

sophisticated. So, you and I can be on a

sophisticated. So, you and I can be on a conversation and we can get something done, but we usually need some sort of tools in our world is usually a computer to get higher productivity um and to be

able to do things. And so, I think of that in the same lens. So, for me, agents are literally just digital knowledge workers.

Great. And so it's on computer. That's

the the whole concept of of sandbox. So

as an introduction to this whole conversation, what is a sandbox?

Absolutely. So sandbox is although they the term sandox first comes from isolation. So making sure that there's a

isolation. So making sure that there's a secure place for in this case an agent to run and do things. But on the other side it is essentially a computer. It's

a full-on computer that an agent has ability to install tools, access the web, um, run scripts, run code, whatever it needs to get its job done. So, the

shortest answer is a sandbox is essentially we call them composable computers for AI agents.

Yeah. And is in some ways like this whole open claw and Mac mini like a good analogy for what a sandbox is like the Mac Mini sort of being the sandbox.

Exactly. So I think the openclaw Mac mini thing helped a lot of people understand what we actually do. It's

like oh I get it now. I get it right. So

it needs a computer in this case was a Mac Mini to be able to do different things. So yes that helped a lot with

things. So yes that helped a lot with awareness for sure.

Yeah because uh again to unpack it like the uh open claw as as a as a frameworking system to help an agent do all sorts of things on your computer.

basically you want to be able to kill it if it goes rogue and therefore you can unplug the Mac Mini the way you could sort of kill a sandbox. Is that is that kind of so there's there's a couple things that I personally thought about

and so my open claw runs on a not a physical Mac mini essentially but a sandboxed um virtual Mac mini and the reason why I didn't so the way people

usually run these things and cloud code or openclaw is usually on their own computer because it helps them you know organize emails you know search whatever

documents they have and whatnot there there's a one there's a high security risk there because at one point we were doing our board meeting presentation and

I would ask claw can you go fetch the data from our bank and then it was like oh yeah just log in and give me access and I'm like log in give me no I will not give you

access right um and so right away fundamentally for me that was like broke the entire thesis of it so you give it its own machine I personally gave it its own like Daytona account it gave it its own phone number and the reason I have

give it own phone number is because it has to do 2FA to get into the bank. Like

there's no other way except for a 2FA with a phone number for this particular bank. And so it has to have all these

bank. And so it has to have all these things like a employee like a digital employee to be able to go and access these things. And so the risk now that

these things. And so the risk now that now that it has its own computer, it has its own account. These accounts have the limitations. So it can only it can only

limitations. So it can only it can only look at the data from my bank. It can't

spend the money from my bank. And so

except for the credit card that we did give it which has you know you know $100 a day or whatever it may be. And so the only risk you essentially have at that point if it's in a sandbox is will it take this data and now leak it somewhere

and that's something we can talk about later but essentially the worst thing can happen is that and to your point you can kill the whole machine if you need to kill machine.

Yeah. And there is a a fundamental concept of um stateful versus uh stateless. Uh can you can you unpack

stateless. Uh can you can you unpack that for us?

So that basically comes when we talk to people about what we are building they're like oh doesn't this already exist in any of the hyperscalers right?

And so the answer is no. And the answer is no is is because everything that they were built for which was deploying apps they were they were stateless. Like if

you have let's let's pick any of your websites or whatever you want web apps you do not want that to change on the fly. You if you if you are the company

fly. You if you if you are the company will pick like eBay because they're in this building so they're they came to mind. And so if you're eBay and you're

mind. And so if you're eBay and you're an engineer there and you're like, "Oh, you have this new, you know, update. A

button is here or it does this thing."

You want that state that you you don't want that to be changed on the fly, right? The database might change,

right? The database might change, information might change, but you don't want the app to change, right? And so

with those things in mind, that is how people had built the hyperscalers. Like

that is the fundamental architecture you came into and built on top of that. And

the simplest analogy I give people is let's say you're building a truck, right? You are a factory for a truck.

right? You are a factory for a truck.

There's like the the weight, the type of the engine, the chassis, um all of that is made to very slowly but surely

securely transport some sort of goods, right? On the other hand, you can have a

right? On the other hand, you can have a sports car which is still, you know, it has four wheels, it has an engine, whatever, but it's made for different things. It's made to go very fast. So

things. It's made to go very fast. So

the way the chassis is built, the way the, you know, um engine, the the weight balances is completely different. And so

you can do you can do a lot of things with both, but they're not fundamentally the same thing. And as a company trying to build out both of those, they're separate platforms completely, right?

Mhm. So sandboxes are a fundamentally new primitive. Is that is that correct?

new primitive. Is that is that correct?

Is is it like a history of sandbox or did sandbox exist before? So I I would argue I would say that that the the person that could have nudged although he said he did and someone else did but anyway there was a company called code

sandbox way back in the day when we used to compete with our company code anywhere which also was in the in the realm of like replet it's all these cloud-based IDs and so they called it code sandbox cuz I I I believe it it

sounded cute it's like a box where your code you for ID um lived and they were actually one of the firsts so the team there that actually used microVM M did

snapshotting, forking, all these things that we do use today. And so that is sort of and this is maybe a decade ago,

but the utilization or the usage from or the value that it was giving human developers was not there. There's this

whole article about like the end of local hosts and people have been talking about this for I've been talking about this for 20 years. Um and basically developers would say like you'll take my local host like out of my cold dead

body. But now that agents are here,

body. But now that agents are here, local hosts no longer actually one, you don't want that for a number of reasons.

And so we're finally getting to that. So

that technology and that thesis around sandboxes originally now seems to be coming to fruition.

Mhm. And the big acceleration around sandboxes is is agents, right? That's

thing. Absolutely. When we think about agents, so one, if you even if you do run an agent on your computer, like you want to do that, up to you. Go ahead and do that. There's a bunch of problems.

do that. There's a bunch of problems. One is let's hear in your laptop.

There's this whole thing on Twitter now where people are holding their laptops open.

There people what is that? Yeah, I saw you tweet the Well, that's because I always hold my laptop open. That's just like my vibe

laptop open. That's just like my vibe without that. Um but been doing that for

without that. Um but been doing that for a long time. But people do that because they want clawed or open claw to finish.

Yeah.

Cuz if you close it, it's Yeah.

is you terminate. Yeah. It's or pause or stop or whatever. Um so like the problem is like the continued the ability to work non-stop is not there as long as your laptop. So that's one thing. The

your laptop. So that's one thing. The

other thing is you can't do concurrency.

So you can do multiple to the amount of compute that you have in your laptop which will be quite limited. And so you might want to spin up 10 or 20 or 50 or 100 or 100,000 whatever that number might be. And so that's very hard. So

might be. And so that's very hard. So

ideally you actually really want to remove it somewhere remotely. So you can start on your laptop, you continue on your phone. It's the same computer and

your phone. It's the same computer and same agent that is doing their thing, right? And so that is a takeoff of we

right? And so that is a takeoff of we have now decided that it's absolutely okay that is no longer on our local host but again it is still a local host to that agent. So it's still a computer to

that agent. So it's still a computer to that agent what a laptop is to us.

Do all agents need a sandbox or is that a specific category?

My my argument is that every agent will need at least one sandbox sometimes more and we can get to that again. there are

places where you don't need and I analogize agents with humans for the most part and again we can have we can do productive work without computers and so there is and that was the original

sort of like chatbot where basically you would just talk to an agent and it would inference so we just think and give you value so I don't know you a lot of people use it for like emotional support or whatever for the most part it doesn't

need a computer it has enough data from you going back and forth and then it can sort of understand and give you feedback but that's a smaller subset. If we think of where all productivity gains are

among the biggest verticals, healthcare, financial services, whatever, most of that is done via a computer. And so if you want agents to do all these things, then agents will need these computers to

do.

So if you do uh tool calls, coding, like any of those actions, then you need a sandbox. If you just chat,

sandbox. If you just chat, you probably don't need it. Yeah. So

like even if if you have a chat we can get it to deal but if you chat and it has to search the web it still has to open a browser or it has to use something like you know parallel or exa or whatever to get to that that would be

a tool call. So it depends on the use case but the thing that's quite interesting about the world that we live in is one let's take a step back one I

firmly believe that in due time all the tools will be headless now will it be inside a sandbox or outside that's another thing all of them will be um and

that's the most efficient way for an agent to work but most of knowledge work is still locked into legacy apps inside of inside of Windows for the vast majority, like the absolute vast

majority. Um, so if you want an agent

majority. Um, so if you want an agent today to do a job end to end, you literally have to give it a computer.

And so an example of this is again the board report, which is like, oh, can you pull out this report and our bank has an API and it can pull it out, but it only has spend on the API. It doesn't have um

incoming revenue on the API. It's just

not exposed or through the MCP tool actually. It's

not exposed. And I'm like, then the agent was like, "Oh, I can't get to it."

I'm like, "Dude, log in, download it."

And okay, I'll go to it. And then you can see it opens up a browser, it goes download whatever. Same thing with, I

download whatever. Same thing with, I don't know, with any other data source that we have. If it can pull it from the headless, it'll do it headless. If it

cannot, then it sort of logs in and do that. And so, if we want to give them

that. And so, if we want to give them power today and get value, we have to enable them to have these tools.

You had a great tweet the other day where where you were talking about like the actual use cases. uh that you see as a provider of sandbox of agents. Do do

you want to go through this? You had a code command execution computer use browser use and RL environment infra. Do

you want to unpack that?

Sure. We basically I've made it I I think I've structured it better since that tweet which is right now we have two major use cases or two types of customers consuming Daytona in different

use cases and one is on the researcher side. it'll be you know RL eval

side. it'll be you know RL eval benchmarks and the other will be on what we call background agents or long running agents and so when you think of background agents or longrunning agents

like the the most popular those are where a human is the end consumer the human talks to a let's call it app layer service that has an agent in that and then the agent will call in the sandbox

so things will be you know think of like Harvey or perplexity or whatever as or lovable as these types of background longrunning agents and so they can both

be uh sort of headless so code and command execution and or computer browser use. So depending on what they

browser use. So depending on what they need to do and the same thing is on the researcher side where it's like RL valves and whatnot you can do RL valves for you know coding and for that it's

basically just headless like commands and command execution in there or you can actually teach it to do things in the real world and then it does have to fire up a you know Windows a Mac a Linux

sort of desktop or a browser to go through the things.

code and command execution and browser computer use are like two ways an agent can work and then it's to basically the consumption of the sandboxes to do those two different things are different.

So that's a great um sort of sandbox 101 introduction to to to the concept um help us understand uh where sandboxes

fit in the overall picture of this emerging uh agent stack that uh I think everybody's trying to figure out at the same time. So there's there's different

same time. So there's there's different components, there's uh file systems, there's orchestration, there's like what what are the different pieces?

I I try to think about everything. To

me, it's actually quite interesting where and we'll get this a bit later as well. It's like a lot of this all exists

well. It's like a lot of this all exists in real life today. And so people are like overthinking this. I'm not saying that there there's not going to be new products and solutions and technology to solve it, but it's like it's not a new

fundamental way of work. And so when you think about the agent stack itself, it's like okay, you first have the models and the models are essentially the brain

that that is what it is of equivalent to what a human's brain is sort of. So you

tell it something, it replies, it understands and whatnot. And then under that is like oh what are the tools it can do to get things done, right? And so

that can be anything from like any of the MCP or or tool calls can do. It

could be the sandbox, the computer, like whatever we as humans, we also have a bunch of tools that we use. Everything

from a hammer to a computer and everything around that, right? Um, so

all of those things exist as well. Then

there is memory that exists. Can can an agent remember these things? Similar to

like do you remember these things that are there? People talk about

are there? People talk about orchestration of agents. It is like management. Do you manage people? I

management. Do you manage people? I

manage people. Managing agents is similar is not dissimilar to managing humans. Now what tools will you use to

humans. Now what tools will you use to manage them? Will you manage them in the

manage them? Will you manage them in the same way just send a slack message and or you do linear or whatever it is we will see or it's going to be a net new app we'll figure that out but it is of that and of course it's like

observability can you see what your teammate or colleague has done and verify that that job is good right and so there's tech that's sort of how I think about that on a very sort of

higher level and then you can break down to different types of solutions people are creating for this yeah let's do some of that the things that I think about like

there's also like things that are more solved and less solved where like the models I'm not saying they're solved that they won't continue to progress.

There might be different versions of models but like it's very clear that there is some sort of brain that is there and we have the leaders and the frontiers and we have people trying to do different things and that is all said

and done. The tooling I don't know if I

and done. The tooling I don't know if I would spend too much time we that's all we're talking about now which is like the sandbox the computer the MCP tools there's like a bunch of them that that

are being there. The thing that's not solved very well is one so there's memory itself and so memory itself like how do you do this right now the best

solution is just dumping things into MD files and then you know sort of having access to that and then you know compressing that and how you're going to get that I I we talked about this the other day which was the book of why we

sleep right um and in that book of why we sleep it's basically a lot of the how you do data retention and things like that and that's sort of what we're trying to solve for agents agents

themselves into that segment and so memories there the thing that is actually quite interesting for me is actually the learning of the model one thing that I didn't understand

internalize is that models actually don't learn right now so you use a model and if even if you solve memory it has memory of things so it has context of

these things and so um it can oh here's the context and so it can have a better answer because it has the context but it doesn't actually learn on the job that

is done yesterday right and so who is solving or how do we solve that does that one does that require something like you know constant RL learning post training for this or is there something

fundamentally that we change in the model so the models can do that I don't know but it's definitely something that will that's hindering progression today and it's not absolutely clear how we get

to that point because it sort of weird to work with someone that actually doesn't get smarter, right? Like you get a new model, but like it's like, oh, it's like a new new one that comes out,

but like you do something five times and it can mess up. It literally screws up the sixth time like right. So like every single time really and so you can try to prompter better. You can have more

prompter better. You can have more context so it doesn't do it but doesn't actually learn. I think that is

actually learn. I think that is something that's going to be quite interesting to see sort of how that that sort of progresses.

Yeah. And from your vantage point, memory um is one of those markdown files or like a

combination of those versus a database.

Seems like markdown files are incredibly elegant and simple but somehow feel less robust than what a database would offer.

I mean not from a personal and I might change this from a personal perspective.

I I also would tend to agree with you that like markdown seems quite trivial for the for the problem that's there and the compression and and how you get to all these things inside of that. So the

thing that we try to do as a company providing infrastructure for these things is to make sure that we can expose the ability for the agent to

access these things in a very simple way and add to them but solving it itself is outside of our let's call it mandate and in this whole um kind of agent

harness I guess everything that you describe kind of falls under the current uh concept of of of harness. Where do sandboxes fit long

of harness. Where do sandboxes fit long term? Do do you think a lot of this gets

term? Do do you think a lot of this gets eventually built into the sandbox or does the sandbox remain the the the execution layer for it all?

Two two things. So if you look there's like the sandbox itself and again restating I'm saying it so many times in in this conversation but if we take like an average worker in Goldman for example

right you have the you have the worker the person which let's call it the model in this way you have the computer which it logs in into um and the harness is a

set of the way it shapes that model that it can and cannot do things interact things so it's almost like hands sort of to speak um of that bit bit deeper but

basically the sandbox does support it and so if you think of a computer again I'll pick on I'll pick on go Goldman for example I've never worked at Goldman but it's my just assumption I worked at bigger company so my assumption is that

when you log into that computer there is so much software in that computer that logs what you do restricts what you do make sure that you don't leak data and do these things again no prior knowledge

of Goldman just assumptions on these things and so those are the types of things that we as a sandbox provider will most certainly incorporate into

that. But that harness still has its

that. But that harness still has its function in that which it guides the model like oh I now know how to interact with this machine. Oh, I know how to do

a tool call. Oh, I know how to this is how I work with memory. This is how I change with a model. And so there's a there is value in that. And so we don't take on the harness. That is something

we pretty sure that we never do. But

there's things that we do in the sandbox that does help or support that entire system.

Great. We talked about models. Uh where

do the model providers like the big um AI frontier labs uh fit in this overall picture? OpenAI recently had an agents

picture? OpenAI recently had an agents SDK announcement. What what is that?

SDK announcement. What what is that?

Yeah. So I mean they they have a big push into this this space where like claude code and their agent SDK um has been and so it's a focus for them to

essentially catch up um on that segment of of the market there. So

there's two things right there's uh OpenAI agent SDK and then cloud manage agents or they're different. Yeah they're

they're different. Yeah they're different. Yeah unpack that for us. the

different. Yeah unpack that for us. the

anthropic managed agent. So it is a managed service where you essentially have the model, the harness and the sandbox all wrapped into one basically and so you have that all managed for you

as a service that entire stack. So that

is there. Whereas if you just have an agent SDK, you can use that and run that into any sandbox provider or your own or any machine that you want to run it and

it can connect to depending on the licensing or whatever maybe you might connect it to that model provider that gave you that harness or you might be able to interchange uh those things. So

basically the one is just a harness the other is the model the harness and the the sandbox al together.

Okay. And uh I believe Daytona was a partner to open AI for agents SDK, right? Like one of the sandbox

right? Like one of the sandbox providers. Exactly. That's part of that

providers. Exactly. That's part of that original framework. Okay. That's the

original framework. Okay. That's the

sort of like overall um landscape uh around the agent stack. We're going to go uh much deeper into sandboxes and how that works from a technical standpoint

in a minute. But as a quick detour, let's talk about um your story and uh Daytona's um story. So you this is not

your uh first venture. Talk about the the the prior thing that you did. You

alluded to some of it like uh that was a little little bit like replet.

Yeah. So we started the cloud IDE space basically in 2009 both me and co-founder and so in 2009 for those of you that were around there was like no Docker, no Kubernetes, no VS code and so we had to

build the entire stack which was something that we learned how how to do and something that we applied today. So

like it was actually very very very early. The only I say that we started it

early. The only I say that we started it because the company that started before us was Heroku which became Heroku and killed the ID which we probably should

have done sooner um as well. So but we were the only one that sort of like started and finished finished in that in that sense. Later on you had other ones

that sense. Later on you had other ones like code sandbox like replet and like others that that had had joined and um stack blitz which now bolt and whatnot.

And so Replet also now changed and bolt into their other directions and Replet is doing really well. We decided to go in a completely different direction when we decided to do their next company. So

um we had learned a lot of things on how to build this entire stack. But when we decided to kick off Daytona V1, which is different than it is today, we decided not to go app layer but just be

infrastructure probably like on the teachings of Heroku which definitely went in into that direction.

It's like oh we learned how to do all these things on the orchestration level underneath that seems to be very very valuable. So let's push on that and that

valuable. So let's push on that and that is how we kicked that off. you you

tweeted uh my first startup taught me exactly what not to do at Daytona and talk about like selling to developers new onrem solution like talk about some of we learned a lot of things we one thing

we learned is timing I never understood like timing of the market like you have to pick it's very hard to time the market but you know if you're in the right time like fairly soon um ideally you want to be just before the time but

that's like very very hard you definitely don't want to be completely wrong we were like two decades wrong um for decade and a half. So definitely

wrong on that one. The other thing is like I did not know the difference between a user and a customer. And so

selling to de Daytona now is a PLG motion 100%. The code anywhere product

motion 100%. The code anywhere product was also a PLG motion but the code anywhere product had no enterprise use case value. It was all single developer

case value. It was all single developer value and signal developers do not want to pay for these things. Whereas a

product like what we are it is a PLG motion. it gives value to a single

motion. it gives value to a single developer but a single developer probably working inside of a of a company and so they will pay with their company's card which is very very very

different but you don't know when you start out so um those are definitely things that we um understood when we were creating this company and the difference we didn't get into detail but the difference between Daytona v1 which

was managing it was an infrastructure product for human engineers in very large enterprises it was an enterprise play whereas Daytona V to the sandbox

is a we can call it a neo cloud like it's a new cloud although neo clouds are usually for GPU clouds we did understand that there was an enterprise play to be

there so everything that we had learned of like onprem multicloud different ways of u managing observability audit logs all these things that you need for

enterprises we had already either baked in or understood that that would be needed so we prepared the product for that originally.

Great. You're also pretty amazing at just distribution in general and and then building a brand and then developers uh which is fascinating, right? Because that's uh one of the

right? Because that's uh one of the typical issues with very technical ventures. The people tend to be

ventures. The people tend to be excellent and deeply thoughtful about product and technology and then distribution comes as an afterthought.

How did you become good at it and what are some lessons you can share for technical builders? I mean it's all

technical builders? I mean it's all about like I'm I probably sucked at all that like terrible terrible like I was the were so let's take there's so many

ways to say how we did. So one thing is I think I very well understand humans at scale like my like what the

market wants and or needs and or feels.

Um and so when you do that it's like I I did not know that inherently but you sort of start learning that you understand humans. I it's very hard for

understand humans. I it's very hard for like single humans not so much but more like larger massate humans aggregate humans much better um so that's one thing but the other thing is I was like

super shy geeky whatever as as a child and the the stage fright terrible terrible like pitching my first startup like I would be so nervous like I would be I had to

like talk on stage five minutes before stage I'd go to the restroom like 10 times like just like of the pressure of these things and the thing that happened

quasi randomly is with our first venture code anywhere we did pitch around all these like conferences around the world and whatnot and it was such an interesting thing that I decided in like

with one of the founders of one of these conferences at the afterparty quite you know intoxicated probably he's like oh do you want to do one in Croatia where I was living at the time and he I'm like

yeah let's go do this and so I go do I set this up this conference it's in Croatia 250 people um which was really big for us at the time. And I had hired

an MC that had bailed last minute. And

so there was no MC. I have stage right.

You're it.

I'm it. I have to go. And so you I was literally the MC for two days in a row.

And you broke straight like you break it. Like you just have have to do it. Um

it. Like you just have have to do it. Um

so what I'm trying to say this is very different from the go to market but it builds on it's like okay now that I no longer have this stage fright the you start teaching start understanding what

interactions excite people less excite people how to bring people and whatnot and it's also a problem because when we said we're going to do a conference I didn't understand what a conference was and so it's like how do you break down what is a conference okay a conference

is it's entertainment first and foremost and so you have you know the show the show are the speakers how do you get the Then you have the this for the speakers you have to sell the audience. Who is

the audience? Who's coming there? How do

you get them there? What? And then some has to pay for everything. The audience

does pay for tickets, but the vast majority is under sponsorships. And then

how do you sell that to sponsors? And so

you break that those things down and then you start understanding incentives of all these different parties and you start putting that together. And so our go to market motion when we and we did

conferences for a decade more or less.

So you sort of like you have iteration cycles of a year then we started doing two a year and we started doing three a year and then every conference got better cuz the iteration cycle was was much faster to get the the feedback loop

was much faster and then when we decided to do like Daytona and our whole go to market strategy was originally around in real life events and so we did dinners

meetups drinkups hackathons but all of them were simpler versions of conferences and mind you the conference that we had was like 4,000 people so it's like it's a fairly big. It's not

100,000, but still fairly fairly big.

And I remember telling one of my teammates that works on the conference business with me now at Daytona. I'm

like, there's no way in hell I'm ever doing a conference ever. Not doing it.

That's the most stressful job in the world. Never doing it again. Never. But

world. Never doing it again. Never. But

we'll do these little things cuz it's easy. And then people will come up to

easy. And then people will come up to us, how do you guys do these events? How

do you do these meetups? Well, when you understand how to do a big conference, like what are the interested parties?

Then you know how to do a like very small meetup. It's the same things

small meetup. It's the same things apply. It's just like quite a lot

apply. It's just like quite a lot smaller, a lot easier to do. And we

ended up doing a bunch of these. They

were all We didn't sell obviously these events do on sell, but sold out in the sense of like there's no more space in the rooms that we're doing. We now like attract like partners that you know co-sponsor these events for us. Just a

great motion for us. And then at some point my my my colleague was like we have to do a conference like no we have to do it. And so we ended up doing that in the Chase Center, but we ended up doing in the Chase Center in San

Francisco two months ago. I think you were there as well. You helped out and the the whole which was uh incredible by the way. So when you think about marketing as a you know an effort

to make a company I mean create a brand and make a company look you know big and powerful. Um that was a

powerful. Um that was a you know a masterass in how to do that.

Thank you. But all of it all the entire GTM that we have we have no other things that we do like Twitter is a go to market um we don't have we have zero sales people and whatnot but it is definitely so the way I think about this

and I stole this from or paraphrasing it from David from century which is like there's basically three ways that people pick your product and one is awareness do they even know you exist like if that

doesn't happen there's no way they can pick you two is preference which is you know the the pricing the brand, the person, the different features, whatever

like it's it's preference. And the third thing is like is there a deterministic thing that you offer that no one else has? So the easiest example for the

has? So the easiest example for the third one is like do you have fed ramp right? Do you have that certificate? If

right? Do you have that certificate? If

you have like I can only the customer can only use you and no one else. But

the two above are are quite interesting which is like how to make sure that everyone knows who you are and then you work on the um then you work on the

preference. And so for me the all I

preference. And so for me the all I don't it's not all I think about a large part of I think about is if all things were equal. So if our product is equal

were equal. So if our product is equal to everyone else's product what is the differentiator to that? And so like one can more people know about you than

others like is the branding there is the the the um the experience there. uh

experience is a nuance which p some people don't think about, some people do think about, but it's like do you prefer the feel of this product versus that product? And these are all things that

product? And these are all things that have nothing to do with the actual technical capabilities of the product.

And so my co-founder Verran, our CTO, like his job is mostly to make sure the product is better than anything else in the market. And my

mandate is to make sure that even if his if our product is equal that we can supersede that and so that's how I think about the go to market in general.

Do you think of uh customer support and customer service as all of that it's all go to market all all that is go to market and and we've seen this we've chatted about this where

we we've been getting users and customers just because we are so good at that and so all of it is an experience.

So if you think of any experience as a human you go to like store restaurant whatever it is the entire experience it is from your the way what is a brand it's the

perception of the that brand itself is just the perception and the perception is like if you go into whatever store pick your brand you want the the smell the music the people the smile that

whatever you get all of that together is the perception of that brand and so if you think of that through the lens of a product which might sound counterintuitive I don't know or nonobvious to people like I think about

that alto together let's say we were selling sneakers right like we don't sell sneakers but the the this sneaker which we won't me won't say other brands but if you do you can yeah always pivot to

GPU exactly like if you go to the store here in New York it's like a beautiful store the people are very nice every everything's aesthetically pleasing and

you just like enjoy that entire experience and it's a good sneaker right and so you have to have that altogether and so that's how I think about this as well which is you know you have to have a good product you have to have all

these things but all these other things have to coalide with that now the risk is and we've seen this with a bunch of startups like there's no sustenance so the product is not good and you have everything else and that is sort of

that's when you get into trouble but if the product is good or at least as good if it's better it's amazing and you have all these things for for me my belief is that is that is a key driver to continue growth

great uh you mentioned Twitter and X uh a minute ago. To which

extent is that part of the whole u the whole plan?

It's hard to measure. Yeah.

Like I've worked in bigger companies and if someone if I was working for my former company they're like how do we measure that? Like I have no idea that

measure that? Like I have no idea that we measure that. But what I can say is that I was never active on Twitter very I have an account since 2009 but never very active until like this holiday

season where there was like this semi viral tweet that that went out. Um,

what did you say again?

I So the the tweet was if you're taking a break these holidays, you're NGMI.

You're not going to make it.

Yeah.

Which I honestly believed.

Yeah.

Like the tweet was basically I wasn't even thinking about there's like a typo in the tweet. Like it's not people like you're wage bating. It's like no. I was

my thought is we are we are a part of this like super cycle right now and the super cycle does not last forever. And

so if you're going to pause by the super cycle, you are steing market. like that

is what you are doing right and also it's like it's very much towards you know founders and executives and tech leaders it's less about the individual person that you know that can't have an impact on

in that like people have to take their breaks and so people took that in all different ways or like two poop too it's like you should die you're a capitalist whatever all these things and the reason why it became so popular like it was

kind of popular which was some person said dude you never I've never heard of you or whatever and then I said basically that's why not to keep working and that

perfect and I'll again not I was like instant reply on that and so basically not talk too much about that is that from then I had noticed that

people even if they like your tweets or don't or are completely opposed or not has no bearing on I should say it has

that positive bearing on their thoughts of your company. So we have found that people that even are completely opposed

to the posts end up being customers assuming that they need the product line. Not everyone is there. So it was

line. Not everyone is there. So it was quite interesting to me that oh just because someone doesn't agree does not mean that they won't like that because it's all generally awareness.

And so that has been something that I've spent a bunch of time trying to catch up to you on um on the Twitter versse.

Yeah. No, that's super interesting, right? For any um AI builder or AI

right? For any um AI builder or AI founder. So the the the PLG motion

founder. So the the the PLG motion ultimately like to create inbound is is a combination of all the things. So we

talk about conferences and meetups. Um

Twitter is important. Is there anything else that people uh should know? We talk

about customer service. You mentioned no salespeople as of now.

We have no sales people at all. Yeah. So

I think like the how do you experience the the product, right? So like once you've seen the product, how do you experience the product? It's like your door to the product like the website, the login, the whatever. We can fix a lot of these things to be very clear.

I'm not saying we're the best at these, but there's that. And then what are the feature sets are in there? Can I get things easily? Our SDKs are really

things easily? Our SDKs are really really really good. Like people really like like the ergonomics of them. So

it's like really good. That part is great. And then the thing that and this

great. And then the thing that and this is even public on Twitter. All our case studies that we've done and we outsource the case studies to third parties. we're

not part of this is that we reply very very fast and so this is a very public thing and it's something just core to who I am and how I learned to work cuz

one of the let's call it first real jobs I had was a system admin so my job was like to fix the printer and computer and whatever and so one thing that I learned and I try to talk to my entire team is

like one thing you have to do is like one is the first response very fast just the first response very fast like people are calm. They know they have

are calm. They know they have transferred their problem to someone else and someone has acknowledged that.

And so when they do that, they feel rested, right? And then you just have to

rested, right? And then you just have to promise that you will solve or get back to them at x amount of time, whatever that is. And they were calm till that

that is. And they were calm till that moment. And the thing that you have to

moment. And the thing that you have to do is one either solve the problem until that given time or call them, message them, whatever interact them before that

time and state a new time. That is the solution to support. That is it. There's

nothing more than that. There's

obviously there's like key things. If

you're actually down and don't work and the person can't work, that's a completely different thing. But every

other non-critical problem and you have the most happy customers in the world because they don't have to think about their problem anymore. You think about their problem. And so you can like keep

their problem. And so you can like keep that on until you get it done. But the

key part is if I said that something's going to be fixed or deployed or done or whatever in 2 days, a day and a half later, if it's not going to be in two days, a day and a half later said, "Hey, this is going to be delayed two more

days." And they're fine. You thought

days." And they're fine. You thought

about it before they thought about it.

And it's not magical. It's not I mean, it's a magical experience, but it's not very it's not a complex thing, but I found that people don't understand that intuitively. And so, that is what I

intuitively. And so, that is what I learned back in the day, and that is what we do in the company today. And

that's why we are we have very very happy users and customers.

Okay. Fascinating. Now let's switch back to the the more technical uh stuff. So

we talked about the concept of sandboxes. Uh just walk us through what

sandboxes. Uh just walk us through what a sandbox is technically.

Yeah, there's a lot of things there's a lot of things there we can talk about.

The way I think about uh sandbox is the ergonomics of consumption of compute.

And so because there's a lot of different layers on that I basically put it into three different layers which is the infrastructure the primitive and the tooling those three things together. And

what I mean by infrastructure is like is does it spin up very very fast? Can you

spin so like we spin up in 60 milliseconds? Can you spin up a lot of

milliseconds? Can you spin up a lot of them at once so the the rate of creating them. And so we can spin up 50,000 in 70

them. And so we can spin up 50,000 in 70 seconds. Um so little less than a minute

seconds. Um so little less than a minute and a half. And then once they're up, how many can you keep running? Like we

can have we have customers that have billions a day. Um so those are like the infrastructure parts that are non-trivial.

Why does it matter uh how quickly you can initialize a new sandbox and how many again it depends on the user and the use case. So if you're like a long running

case. So if you're like a long running background agent again everyone prefers it to be fast like no one wants to wait.

Like you don't want to wait for a reply.

Like everyone wants to be fast to be very clear. So the faster the better,

very clear. So the faster the better, but generally there's an actual reason why you want it very very very fast. And

that is especially if you so for I was going to say if for a background agent a background agent might work for like 10 minutes or an hour or whatever. So the

incremental millisecond might not matter. But I still believe that from a

matter. But I still believe that from a user perspective even a second of waiting is kind of uncomfortable. You

don't want that. And so is 60 or 90 maybe less so. But there you want that one two seconds for sure under that. But

the interesting the more interesting part where that is really really important is for the researchers where when you're doing reinforcement learning you basically have a lotment of GPUs and

you want the GPU is more expensive than the CPU. So the vast majority of

the CPU. So the vast majority of sandboxes are CPU boxes to be clear. So

they're the computers that we all work on. There might be a graphics card in

on. There might be a graphics card in there but basically it's the compute the RAM the CPU um and the hard disk that's in there. And they are cheaper or less

in there. And they are cheaper or less expensive and easier to to get at least for now. We'll see for how long that

for now. We'll see for how long that lasts. Then GPUs, which means you want

lasts. Then GPUs, which means you want your GPUs always to be at maximum utilization and the CPUs can then idle if need to be idled, but you want them, you don't want the GPUs to idle. And so

what that means is you want to make sure that the CPU machines, the sandboxes spin up so fast because you don't spin them in a training run. You don't spin them all up. You spin them on like

depending on how many you have like a thousand at once. They do the task, then do the next one, the next one, the next one. And so between turning off and on

one. And so between turning off and on the CPUs, you want that time to be as short as it can so that the GPU utilization does not go down, right? And

so that's why that's very very very important. And obviously the number that

important. And obviously the number that you have concurrent so depends on so on the background agents let's say just for the sake of people know lovable. So the

amount of users that they have is astonishing. And so each user for every

astonishing. And so each user for every task and they can have multiple tasks, multiple agents, they need a sandbox.

And so imagine I don't know their user number in the millions, whatever. So you

have to have millions of sandboxes up and running. Um on the RL side, you can

and running. Um on the RL side, you can have people smaller labs that will have concurrent 5,000 or 10,000, but we have a request today for 5 million concurrent look. So 5 million at one point in time,

look. So 5 million at one point in time, right? So being able to handle those

right? So being able to handle those types of things is part of that infrastructure segment. The other two

infrastructure segment. The other two are the primitive and the tooling. And

so the primitive is essentially let's call it the computer itself, the isolation, the VM, the container, the microVM, the isolate, the whatever. We

can get into details what those are, but there's different shapes of them. And

also what feature set do these things have, right? And so for the most part an

have, right? And so for the most part an a VM that you would find in you know AWS or whatnot is usually much slower to

start much harder to get those uh spikes but also when you get a certain size they're usually that size forever and forever and then we just give one one example

whereas in Daytona you can define a size the CPU the RAM the disk and then while it's running you can resize that so if an agent gets to you know use the entire

memory or 100% CPU, the sandbox would or VM would die. In our case, we can expand that. And there's other things. It's not

that. And there's other things. It's not

for us, it's not just a Linux CPU box.

It could be a Windows, a Mac, an Android. It can be, you know, they can

Android. It can be, you know, they can have a GPU in there. It can not have a GPU depending on what you need. And so

that's the primitive. And the last thing is the tooling. The tooling is the tooling. Tooling is either there to

tooling. Tooling is either there to support the agent to be better at its job or to be guardrails on the agent to stop it from doing dumb stuff basically.

So you can think of it, we have a bunch of tools, so headless, you know, terminal and uh fi uh file operations and other things that enable it to use

less tokens, get the job done faster, but also guardrails like secrets manager and a firewall and all these other things. And so the combination of those

things. And so the combination of those three, the infrastructure, primitive, and tooling essentially creates what we call a sandbox. So what's ultimately what's the different between a sandbox

or a container VM microVM all the things all the joy so all most sandbox providers are

firecracker VM microVMs most remind people what firecracker is firecracker it's an isolation priv so it is essentially a type of VM or virtual

machine that's very stripped down it was made by the uh AWS team it's used inside of Lambda and so the idea which are like functions um and so the idea was to have

something very very fast um that can spin up and stateless that that that was the entire time and they were very very ephemeral and so they were used for you

know when your website has a large um if it's Black Friday a bunch of people hitting your website you can spin up a lot of these very very fast like handle the load and enable all these humans to

to look at the website and buy whatever they were buying, right? And so that technology is there and it's a very stripped down version of a full-on VM.

So it has less features there, but the things that it does, it does very very very very well. So it can spin them up fast. It does that because it can sort

fast. It does that because it can sort of lazy load things in into memory. You

can do point in time snapshots. You can

do all these nice things. The things

that it can't do is it can't run a let's call it sandbox now. It can't run a sandbox with a GPU. It just doesn't work. So that you can't have a

work. So that you can't have a firecracker. So if you want a GPU, you

firecracker. So if you want a GPU, you have to do something which is a cloud hypervisor or a Kimu spelled Q E M U which are two different types. Q Kimu is almost a full VM. So it has all these

different things in inside of there. Um

so you can't do that. But let's for example if you need to run we were solving this for one customer earlier today is they need a machine that also has an Android device inside of it. And

so the only way we could solve that was inside one of these key moves. Like it

can't work in a firecracker, it can't work in a container, it can't work in anything else. And so there's different

anything else. And so there's different types of there. These are like the microVMs of the world. There's also

containers. And so container, most people know Docker, which um is there.

Daytona originally started running Docker containers. We do have them. The

Docker containers. We do have them. The

problem with Docker is that they're much less secure than a VM. The thing that we do in Daytona is we harden that with

SISBOX, which is um VM like isolation that wraps around that. um it's really good for handling density of these machines. It's very fast. It allows us

machines. It's very fast. It allows us to run Docker and Docker. There's a

bunch of features that are very that it's very very good for. Um and so there's differences there. There's also

like isolates which we've talked about or like other app containers which is abstractions of these containers just you're running a single app. And so these different

single app. And so these different things all exist in the world and they can all be theoretically sandboxes with these other two things that are there.

And our original idea was to get back to the original conversation. Most sandbox

providers started as firecrackers. But

as we start seeing that agents have different needs and different use cases, they are going to need all these different shapes consumed through one

interface. And so we at Daytona now

interface. And so we at Daytona now support containers and all the microVMs depending on your use case. The user

doesn't know it's the same ergonomics.

It's like, oh, I need a Windows, it'll spin up this one. I need a Linux, I'll spin up that one. And so we will continue to add these things inside of the same infrastructure. Sometimes it'll

be slightly faster or slower, but that the concurrency will be there. All the

um the the tooling will be there. And so

everything that you would come to know and like about a Daytona will be there, but it'll be different sizes and speeds and configurations depending on your use case.

Why are snapshots and ors important?

There's a lot of reasons. Let's get into the the commercial one, which is probably the the one that people most think about, which is pausing a sandbox.

So if you are an app layer company and you have 10 million users and your 10 million users spin up let's just say 10 million sandboxes just to make the math easier. These things cost right cuz

easier. These things cost right cuz they're running they're using CPU RAM and hard disk the entire time. The most

expensive thing is the CPU second their RAM disc is almost free. It's very

inexpensive and the user sends the agent to do something. The

agent does something and now it's waiting for reply. It could be waiting for the human or it could be waiting from a service depending on what it's trying to do. You ideally don't want that sandbox to run idle because you are

now pay regardless if you're a customer of Daytona or running your own but like there is a cost to running these things.

And so what you want to do is pause that and wait for a reply either from a service or for a human and then resume and the feeling and experience is that it never turned off. So you feel like it

never turned off but it actually did um turn off. And so that one is from a from

turn off. And so that one is from a from a compute management perspective if not from a cost perspective is probably the first reason. The second the second

first reason. The second the second thing is you can enable your agent to take multiple paths. So your agent can say oh at this point in time I'll take a

snapshot and then I will either continue and be able to roll back to this point like a point in time or at this point in time I will replicate the sandbox and have two sandboxes and I can try two at the same time. Obviously it can be more

but right but those are the reasons why you would have that there.

You mentioned uh uh performance and speed um and in connection with that you said that you had to rebuild your own scheduleuler.

Y so what is it first of all what does a scheduleuler do and then how did you go about it? Every cloud that exists today,

about it? Every cloud that exists today, NeoCloud, hypers scale or whatever, they are all built on servers, right? Like

metal machines, I don't know, like historically way back in the day, we actually stack these data the these data centers. Um, me and my co-founder a long

centers. Um, me and my co-founder a long long time ago, but they're all just like servers like CPU, RAM, disc, they're computers basically. Um, and the on top

computers basically. Um, and the on top of these computers, there is a software stack that everyone has built for their own reason. And so AWS has their

own reason. And so AWS has their software stack. Um, Cloudflare has

software stack. Um, Cloudflare has theirs which they're very different.

Everyone has has their own on top of that. And so basically what you're

that. And so basically what you're trying to do when you think of these machines, these servers, basically what we do is we cut them up into small little machines and then give you that

sandbox. And so you have these small on

sandbox. And so you have these small on these big servers, you have these small little machines that can run for a minute, a second, 3 hours, whatever. And

you don't have to worry about this. And

so basically the scheduler or the orchestrator is the one that that basically says, "Oh, after you send me a request, I send you to this server and turn it on that sandbox or little

computer there and then I turn it off or I kill it or I snapshot it or it's the management of all these things there.

And most of our other companies in the space basically have off-the-shelf schedulers. So it could be like

schedulers. So it could be like Kubernetes or Nomad or what whatever.

And when we decided to build Daytona the sandbox product, we inadvertently with very naive were like oh this stuff doesn't work cuz we had worked with all we had built our own then we had used

Kubernetes like we've seen all these different things and we knew what was good and was bad or what was use case or not. None of these were made for these

not. None of these were made for these like super fast staple longunning machines and so we're like we have to we have to do this again. we have to build it again because the way we thought

about it which was not known at the time is cuz at the time sandboxes were very ephemeral similar to a lambda function and we're like no why would your sandbox

be ephemeral by default like your laptop you don't want it to die like you want it to work until it's done and it has to be very fast it has all these things and so my co-founder mostly built this sort

of initial version of our scheduler and thatuler of ours is the basis of everything we do and it gives us a lot of things like outside of just like the performance. It also enables us to do

performance. It also enables us to do things like have four different isolation provide like we are the only company right now that you as a user don't know but like we have depending on

your use case we will spin up any one of these firecracker cloud hypervisor whatever um to get the job done. So

whatever is needed we'll get there. The

other thing the benefit is we built this we have collocation providers so we have like bare metal machines so you can think of us as our own cloud but we're more and more achen to now like the

neoclouds like the base 10s and like the fireworks because for us and we've got to this question yesterday because we have a large request of number of CPUs

is like we can't get enough and so how do we solve that problem well we've already solved it where our scheduler can be attached to any CPU machine, any

server that we think is good enough and it becomes part of our cloud essentially. And so, so why I say base

essentially. And so, so why I say base 10 and fireworks is that both of them run on more than a dozen compute providers depending on what we're going to call them. And so we can do something

similar because we've created this in such a fashion. So that has given us I believe that has given us sort of um a advantage there. And is there a

advantage there. And is there a fundamental technical difference between ephemeral and long running? So if you have a an agent that runs for 24 hours

uh how does that translate in terms of sandbox requirements?

The reason most sandbox environments do not run forever or even is because it's a technical problem. If you think about servers underneath these servers also

have to be managed right and maintained.

And so if your sandbox can run forever, that means that you can never reset, you can never reboot the underlying server.

You can't update it, you can't patch it, you can't do all these things without turning off all the sandboxes. And so

the way you solve that, the easiest way to solve that is having sandboxes that have a termination time. It's like they will only last an hour, 24, it doesn't matter. secure time and then if you

matter. secure time and then if you decide that you have to do something with the underlying machine, you just become you just flag that machine as non-scheduable.

And so at some point in time, there's nothing else on that machine. You can do what you can fix it. You can like reboot it. You can do whatever you want. Easy

it. You can do whatever you want. Easy

peasy done, right? And so because historically most of the workloads were ephemeral, you didn't have to try to solve that problem cuz you didn't care.

Like most workloads like a lambda function usually runs what five minutes 10 like whatever it's not a problem right you never had that restraint or constraint now that you do to have

something that can run forever you have to be able to live migrate the sandboxes itself between the machines so that you can reboot and manage these machines and I understand that most people it's

interesting even technical consumers are like oh all comput is elastic well yes your consumption of it from us or from AWS is elastic someone actually has to like screw together a server, turn it

on, boot it, make sure it works, right?

And have enough of that there. Um, so

that is the difference from from our perspective and why most start off emerald is just it's an easier way to do it. We believe and we've seen this I

it. We believe and we've seen this I think 2.5% of our revenue now comes from or 2 and a half% of our sandboxes run longer than 24 hours, but it's a large

percent. It's like 20% of revenue. So

percent. It's like 20% of revenue. So

like it's not an insignificant part to be there just because it can run for a much much much um longer time on the user perspective. Just to finish on that

user perspective. Just to finish on that sometime users actually want it to be ephemeral one is they don't want any data retention. So they want it to run

data retention. So they want it to run and die like whatever was run inside of that they got the data they wanted and they want that data dead. And so they

flag it with us as ephemeral which means that we won't force it to die but when they kill it it's no longer in it goes into the ether. It does not exist anymore.

Listening to uh this whole uh technical deep dive part to the conversation the the thought crosses my mind that a lot of people seem to think that they can create their own sandbox and it is not

that hard but uh again listening to all of this I'm like good luck. No, so that that we've seen this multiple time and I'm sure you've seen this across other companies as well where you know everyone's like, "Oh, I can spin up a

firecracker on a machine." Yes, you can spin up one, but spin up a million is a problem. Adding all these features is a

problem. Adding all these features is a problem. Having throughputs, different

problem. Having throughputs, different use cases, they're all different problems. And what we already see is like companies that were like, "Oh, we'll do ourselves come back 3 months later, 6 months later, 8 months later."

It's like, "Oh, actually, actually now we can't do X and Y." And so there's a bunch of things on technical side which we can like address and I think we can

finish with that is that the thing that Daytona does is we if you think of most sandboxes this a performance thing most sandbox and most

VMs actually they use the CPU RAM from the server and then they use the hard disk from a network drive.

You do that for a bunch of reasons. Your

life is so much easier if you manage that. Why is it easier? Well, it's

that. Why is it easier? Well, it's

easier because if a server dies, then all the data is on a shared drive and I can reboot that server really fast without maybe even the user not noticing and there's no data loss. Maybe

something in the memory, but nothing there is is lost. So, it's very very easy to manage. Whereas what we do is we actually use the CPU, RAM and hard disk of the machine.

What which means we have so much more overhead of if that machine dies, how can we reboot it back? like you have to do backups in the in that users don't see. You have to do all these things

see. You have to do all these things that happen there. But what that means is that the the IOPS the speed which with which you can um move data to the

hard disk um in which the CPU and RA RAM interacts with from a network drive just to give people like numbers is in the hundreds of thousands. Um if it's a

local drive it's in the tens of millions. So just like it doesn't matter

millions. So just like it doesn't matter if you know what the numbers are. It's

just like extraordinarily large, right?

It's very very different. And so you have use cases that no one really cares about that speed, which is fine. We have

new customers that have a use case.

They're like, it has to be that fast, right? And so it when you get to the

right? And so it when you get to the point, it's like, oh, I can use this, but wait, now I need this performance.

Oh, now I can't do that. Right? And so

to the complexity of sandboxes if when people are starting out their use cases are like oh I just need to run code you can run that on anything it's very easy to do except scale and then when you get to scale and then you need

performance because now oh agents can do a lot of things then it starts like breaking that sort of mold and security. Yeah. And so we didn't

and security. Yeah. And so we didn't even touch the security part, but yeah.

Great. Zooming out as we uh close this conversation. Um you mentioned something

conversation. Um you mentioned something that that caught my attention. So we

have been in a very well doumented GPU shortage. Uh but it uh seems that we

shortage. Uh but it uh seems that we might be heading towards a CPU shortage.

Yeah, it might be happening. So one of your former guests and was at our conference Dylan Patel like semi analysis they wrote the report and I believe it's somewhere like October we

have no more CPUs and people hadn't thought about it like it's it's all GPUs all GPU intensive then memory but basically now now that agents need all

these computers like it is very much needed now that RL is the way that we've gotten most of the progress in models over the last 18 20 months hunts you

need all the CPU machines to do this.

Now that the GPUs are more powerful, they can do in parallel more of these CPUs, CPU boxes. And then you see this, there was a tweet that I put a while

back and it's like you should definitely invest, not financial advice, you should invest in Intel and look at their stock price, right? And so like there's

price, right? And so like there's definitely need for that and it's something that people didn't understand or intuitively that that you would need there. So something that we

think about quite a bit is like can we alluding to also how our product is created how do we make sure that we can match the demand of customers for the

CPU that they have because I don't know it goes to the extreme to where GPUs are because that is very very very extreme. Uh but it is quite highly

very extreme. Uh but it is quite highly high probability that there will be shortages of CPUs going forward.

How do you think all this uh agent stack evolves? Does it feel like we have all

evolves? Does it feel like we have all the core pieces uh together or do you think like in two years the overall architecture uh may look very different?

So we talked about the the stack there and things that have to be done. The um

the identity part does need to be solved. Again it's basically solved but

solved. Again it's basically solved but not solved. So there there's a lot of

not solved. So there there's a lot of things to do there. I'm actually also very wary or think about people think that the models that we have the technology for the models that we have

is the end state and I really really don't think that is true like I think and that would probably be the most surprising thing is like we have a new type of model that is just better or

different than what we have now that either one needs less compute or doesn't use GPUs or doesn't like I don't know whether there's things that we've seen

where, you know, we've seen things with wetwware where people can have like fake human brains and it learns how to play Doom. You have the um what was it the

Doom. You have the um what was it the fly brain that was replicated inside of a computer that then works like a fly?

Like can you replicate a human brain?

And I say this not to replicate myself, but can you a generic human brain and then it's like an it's an AI that is essentially equal to a human and AI. And

so what does that mean for like all of technology? I mean, I'm saying I'm now

technology? I mean, I'm saying I'm now saying extremities for people, not getting me wrong, I don't think that happens tomorrow or like that. I'm

completely crazy, but like I don't think that this is the end all of the state.

The question is does that happen sooner or later? Do we keep our transformers

or later? Do we keep our transformers the the the vast majority of intelligence going forward? And if it if it is, then it continues probably going directionally where it does. But is

there something that happens that changes that fundamentally? something

that I think about because then all our bets, yours and ours are like very very different right?

Okay. Well, Ivan, that was fabulous.

Thank you so much for spending time with us today.

Thank you for having me. We're great.

Hi, it's Matt Turk again. Thanks for

listening to this episode of the Mad Podcast. If you enjoyed it, we'd be very

Podcast. If you enjoyed it, we'd be very grateful if you would consider subscribing if you haven't already, or leaving a positive review or comment on whichever platform you're watching this or listening to this episode from. This

really helps us build a podcast and get great guests. Thanks and see you at the

great guests. Thanks and see you at the next episode.