AX is the only Experience that Matters - Ivan Burazin, Daytona

Channel: aiDotEngineer

Published at: 2025-07-24

YouTube video id: e9sLVMN76qU

Source: https://www.youtube.com/watch?v=e9sLVMN76qU

[Music]
the number of agents in the world I
believe won't just match number of
humans but they will basically be the
number of humans to the power of n and
what is the power of n I have really no
idea but we can see already today that
we are using multiple of them more are
spinning up more and so it will be a
very very large number and this isn't
just hypothetical I mean we don't have a
lot of data around this I actually
researched a lot and try to find what we
have but the some key elements that we
do have is that the first one maybe not
that important but 25% of YC startups
say that AI writes 95% of their code but
the second part is actually quite
interesting whereas 37% of the latest YC
batch are actually building agents as
their products. So they're not building
co-pilots, they're not building
autocomplete, they're not building
legacy SAS companies. Like agents are
the new product.
And I think that's actually quite
interesting and aligns with what we're
looking at. But the most uncomfortable
truth for people building tools for
agents which we are and I know a lot of
people are as well is that most of the
tools that are built today
uh break the the moment you remove a
human from the loop
as we're not entering a world where like
agents are assisting developers. Agents
will definitely be the developers. I
mean they will be the number one people
using that. So basically,
if you're not building dev tools,
if you're building dev tools for humans,
you're basically building for the past.
And what I think about when we build our
things, and I think we all should do is
like what does it mean to actually build
tools for the future? And I think it
means building for agents. And the term
for building for agents um is agent
experience. And a good friend of mine,
Matt, which I guess a lot of you know
here, who's the co-founder of Netifi,
coined the term agent experience. And
it's supposed to be or continues the
evolution of like a user experience, a
customer experience. And most mostly a
developer experience. But the division
the definition that I sort of found that
works the best or defines it the best
was the one from Sean that works at
netlefi. not M not necessarily which
says how easily can agents access how
easily can they understand and how
easily can they operate within digital
environments to achieve the goal that
the user defined
and I think that's a really good
definition and looking at this I wanted
to see like who is actually implementing
agent experience who is looking at this
definition is who is building their
tools like this and I found some
companies and there's more than the ones
I put in here of course. So like if you
guys are building something like this
and I didn't put you, I'm very very
sorry. Like I just wanted to put a few
that I've talked to and looked at. And
so I think seamless authentification is
a really really important one. Um and if
your agent if you give an agent a task
to do when it has to log in for the most
part it will break. And moreover you
don't want to give your passwords to the
agent. That is definitely not a good
idea. And so company a company like
Arcade which randomly if he's around I
met the founder yesterday I had not met
him before that he was ready in the talk
um what they solve is if your agent
tries to au authenticate into like Delta
or Booking.com or wherever it is it can
fall back to the user the user can log
in and the agent can go off to its job
moreover you can also add credentials
inside of arcade before that so your
agent can go and do what it's mean to be
done so authenticate once agent goes off
does their job. A second one is this is
the most this easiest one which I'm sure
pretty much all of you do here is agent
readable docs and stripe does a great
job of this. Basically any doc URL just
appended md and you'll get a clean
markdown file no fluff the agent can
consume it as easy as very very easily.
Um but moreover the llm's.txt standard
I'm sure all of you have seen it. It's
actually on the website as you can get
um the conference website. So if you
don't have an LM llm's.txt in your docs,
you definitely should. Makes it super
easy for the agent to go um and read
what you all are doing.
The third thing we found was API first
design. And I think this is actually the
most critical. Um basically if an agent
can't see the functionality, it's really
hard for it to do. And I strongly
believe that the best way for an agent
to interact with any tool is through a
machine native interface. And I put API
here and I won't talk about MCP. I'm
sure a lot of people talk about MCP.
Will MCP be here or not here? I don't
know. But basically an API is the
underlying tech that you have to have
have to be exposed so the agent can
access uh what they want the most
efficiently.
And so Neon and ETFI and Superbase and
these companies do this a really good
job of this. As far as I know, like all
the key things that an agent needs to
use their services can be accessed via
an API.
And now all these things are really
great and I think this is all a right
direction. But is there more? Is that
it? Is like is it just an API? Is it
just like a make your docs more
readable? Um
and so what I wanted to think about is
the first definition of Shaun's and I
think there's missing one key part for
all of us who are building tools to
think about. Um and that's the word
actually autonomously.
So how easily can an agent autonomously
access, autonomously understand,
autonomously operate within this
environment? And I think this word is
actually quite important and it makes
you sort of think about what you're
doing in a different way because if you
know you give your agent a task and it
can do a lot but it always has to fall
back to you to achieve its task. I don't
think that is the future and I think we
should all go back to the drawing board
and think about this basically. you know
what happens if there are no humans
around to click the buttons to debug
errors to whatever it may be I think
that's where our work starts as tool
builders like
and so if you're not actually solving
that then I actually think you are just
porting for the past and just as a note
um
Swix basically um coerced me into doing
this talk because he said that devel
that agent experience doesn't exist it's
just a wraparound developer experience
and so I think if you're not thinking
about how an agent can autonomously do
his task, then you basically are doing
that. And I don't think everyone's doing
that. Um, and just really quickly, I
sort of skipped off who I am and why the
hell I'm talking about these things. Um,
and why I might know something, might
not. Well, we'll see at the end of it.
So, first company in the early 2000s, so
am dated, very old person. Um, started
by building like data centers and server
rooms, HP servers, IBM's, hypervisor,
VMware, all these things. So actually
screwing in servers and running cables
and and installing Windows servers via
CDs. Um yeah, exactly. Some people
remember CDs. And after that sort of
sold that uh created the very first
browserbased ID in 2009. So replet
whatever 15 years ago. Um that was super
early. So we had to create our own you
know ids, our own orchestrators, our own
isolation. Um more recently led the
developer experience at a company called
Infob. It's a multi-billion dollar
company that competes with Twilio, which
you haven't really heard of probably.
Um, but basically, it's a communications
platform as a service. So, one API for
sending emails, SMS, voice, and all
those nice things. And as of late, uh,
working at Daytona with a bunch of
people that I've worked with in my older
companies, and I have to say, if anyone
has found is a founder or founding a
company, if you can work with people
that you've worked with historically,
you should do that. It makes it so much
more fun. Um so yeah, Daytona basically
is a secure and elastic infrastructure
purposely built for running AI generated
code. Basically that means we created an
agent native runtime. And what agent
native means I'll hopefully explain a
bit. Um or more simply like sandboxes.
So we as Daytona give agents a computing
environment that they can use to run
code, do data anal analysis,
reinforcement learning, computer use, or
more recently I've seen people use it
for agents to play video games like
Counterstrike and whatnot. So um people
are doing funny things with these
things. Um and so Daytona is basically
what a laptop is to a human. That is
what a Daytona runtime is for an agent
sort of. And so when we were starting to
build this new company or this new
product, we looked at what it means to
build something for agents and we took
the principles of what agent experience
is and these are the first things that
sort of we built through that. And so
one is speed. Basically, if you have a
tool for an agent and your agent is in
in interactive mode. So think of like
cloud or chat GPD. If you're the user,
you don't want to waste time for things
for tools to turn on. So we created
something that spins up in like 27
milliseconds. Um, obviously API first.
So, can an agent via an API turn on a
machine, turn it off, you know, clone
it, delete it, whatnot.
After that, we thought about what more
things can it do? So, like it's really
fast. The agent can spin it up, but what
happens when it gets inside? And so, we
thought it wasn't ideal for an agent to
parse an output from a terminal. So, we
re preloaded all of them with headless
tools. So, a file explorer, git client,
LSP, terminal, and all these things. And
so this sort of aligns with the original
definition is like we're helping agents
do things faster. And we thought like
that was it until we started getting
like really interesting users and
customers that said like oh like
our agent can't do this. And so we have
to put in a human in that. And so I'm
going to walk you through some of these
new primitives, maybe a bigger word for
that, but maybe not, were features that
we found with new customers building
agents on top of us. And these, just to
be clear, I don't think these features
are something that everyone can
replicate, but it's more of like how we
thought about solving these problems and
how we seen these problems and maybe
inspires you to think about how you're
building your tools for agents. So the
first thing is a declarative image
builder. So Daytona is a sandbox. It
uses any docker image off the shelf. Um
so as a template and then the agent can
you know spin up a sandbox with that
template. Obviously if an agent needs to
add a dependency it can use you know the
API terminal and just like pip install
whatever it wants. Great. But if an
agent has to now install like 20 new
things and do it over and over again,
that's just like a waste of time and
resources. And the way you would solve
that right now is like a human goes into
Daytona, you know, creates the new
Docker contain or goes to the laptop,
creates a new Docker container, pushes
to our container registry, and the agent
can do that, but that like takes time
and effort. The other option is like an
agent tries to build a Docker image on
its own and then push the container
registry um which is brittle, takes
time, breaks, and probably won't do very
well. So how do you think about that?
Well, we created something like a
declarative image builder where an agent
can say, "Oh, I need a net new one. This
is my base image. These are the things I
want installed. These are the run these
commands. We build it on the fly and
open up a sandbox." Basically, the agent
can now at any moment in time say, "I
need something net new, make it I can
make it on my own and I can launch it on
my own." Solves end to end for itself.
The second thing is what we humans take
for granted is if you're programming on
your laptop, your environments are
usually probably Docker containers on
your machine and you have if you have
this large data set, you can really
easily share it with all the
environments that you have on your
machine.
But if an agent and we found some users
that really need this, they need like
100 gigabyte data sets in every machine
that they have.
There is no local laptop context. Every
environment is isolated on its own. So,
how do you make it more efficient that
an agent doesn't have to download
something from or upload from S3 every
single goddamn time? And so, basically
created something called Daytona
volumes. The agent can invoke one of
these any size it wants, uploads it
once, and maps it as a network drive or
mounts as a network drive on every
single machine.
The last thing I'm just going to go
through and then we'll finish off on
these feature stuff is quite different
from the others, but I put it in here
because I feel it's very much unique to
agents and that is the ability to
execute things in parallel. So an agent
unlike a human, we as humans can work on
one machine, maybe two if we're super
dialed in. Um
an agent can try things in parallel all
at once. So instead of going try this
out outcome, it sucks, go back. Try it
again, it sucks, go back. It can
basically take a machine, fork it five
times, 10 times, 100,000 times, go
through all of these and then come to an
output. And so again, these are just
things that we have seen as we've worked
with users and that they need their
agents, what their agents need to get
their job done. And so if you ask like
what else is there in agent experience,
the the short answer is like I have no
idea. Um the the reason I say that is
because people that are building agents
are building them right now. And
you're only now or we are only now
finding out what they actually need to
get the task done. And so what I want to
instill you all with is if you haven't
thought about or if you have a tool that
at some point needs a human in the loop
then you probably haven't solved or
thought about how to solve this. So the
beginning of the talk is called
basically the agent experience is only
experience that matters and I say this
not because we as humans are
disappearing but agents by far will be
the largest user out there and less and
less we'll have people behind the screen
reading the logs clicking on butdding
buttons typing into terminals and lastly
just one thing I'll leave you with is
when we started Daytona basically we
wanted the best developer experience
that we could have um and we invested a
lot in like the terminal and there was a
talk earlier about here today about
someone that has amazing you know
terminal UI and I think that's great we
started with that as well but as a small
company you sort of have a focus on what
you need and on what's most important
and right now what's import most
important is yeah great to have a CLI
but can your agent do your task end to
end because basically if your agent
can't use your product in the future
absolutely no one will
so with that I thank you for your time
um we if anyone has any interest in
this, you can take a look here. Use our
GitHub. It's open source. Also, we have
a booth downstairs in Expo Hall. Thank
you so much.
[Music]