The future of UX design
Constantine Gavrykov of Decathlon on designing for AI agents as users.
&w=3840&q=75)
Ivan Burazin, CEO and co-founder of Daytona.
Ivan started out in the early 2000s building physical server infrastructure. In 2009 he launched Codeanywhere, one of the first browser-based IDEs, then founded the Shift developer conference, which Infobip acquired. He sat on the executive board of Infobip, Croatia's first unicorn, before co-founding Daytona, which provides secure infrastructure for running AI-generated code.
Today Ivan runs Daytona, an agent-native runtime. In his words, it's the agent's laptop: secure sandboxes where AI agents run code, open browsers and desktops, and try the same task several ways in parallel. He splits his time between Split and San Francisco.
This was my first episode as host of DELIVERED. We got into what an AI agent actually is, the narrow, boring tasks where agents earn their keep, why most AI products today are a chat bar bolted onto old software, and what a tire shop can learn from all of it.
Watch Delivered with Ivan Burazin, Co-founder and CEO of Daytona.
An AI agent is software that connects three things: a large language model, a set of tools, and the person using it. Ivan draws a sharp line between the agent and the model. ChatGPT is an agent. OpenAI is a model company. The model is the brain, and it runs remotely. The agent is the software that lets you work with that brain and lets the brain reach out and do things. Tool calling is where it gets useful. Ask a model to work out a percentage difference in its head and it's slow and unreliable. Let the agent call a calculator and the answer comes back instantly. Ivan's simplest framing: an agent is a knowledge worker with a brain and a laptop, solving the problem you hand it.
Try this: list the tools your team opens to finish one routine task. That list is the toolset an agent would need.
Small, short, narrow and repetitive ones. The clearer the boundaries, the better the result. Ivan's favourite example from coding: switching one API endpoint for another across hundreds of places in a codebase. Humans hate that work. An agent does it well, because it's the same change repeated over and over. Updating thousands of rows in a database falls in the same bucket.
Try this: find one change your team has postponed because it's tedious and touches hundreds of places. That's your first agent task.
Long tasks, long-term planning and problems with lots of unknowns. Ivan is blunt about the gap between the demo and the real thing: demos work in boxed scenarios, and agents released into the wild do a lot worse. Long tasks fill up the context window, and the agent loses track of what it already did. He uses a meetup to show the difference. "Organise a successful meetup in a foreign city" leaves the date, venue and audience open, and the agent struggles. "A meetup in New York on May 29th in a bar" gives it constraints it can work with. He also says he has yet to see an autonomous coding agent that really succeeds on a large, multi-day build.
Try this: before you hand a task to an agent, write down every parameter you already know. If you can't fill half of them, the task isn't ready.
Break the work into narrow steps and keep a human directing it. Ivan's example is writing a long article. Ask an agent to write the whole thing and you get something wide, shallow and, in his words, really garbage. Split it up instead: the agent researches specific data points, a human writes the structure, and the agent fixes grammar and tone section by section. Done that way, a piece that would take him about a week came together over a weekend.
Try this: take one deliverable your team produces weekly and split it into 5 steps. Give the agent only the steps with a clear right answer.
Software that could only exist because agents exist. Ivan compares it to mobile. DoorDash and Uber needed a phone with GPS and a constant connection, so they couldn't exist before smartphones. Most AI products today are the opposite: a SaaS company adds a chat bar and calls it done. He points to a Notion-style tool as an early agent-native example. A user asks for analysis on their notes, and in the background an agent spins up a Daytona sandbox, crunches the numbers and shuts it down. He cites Y Combinator batches of roughly 200 companies where about 37% are building agents, and he expects most new software to end up as agents. He also says he hasn't seen one at massive scale yet.
Try this: ask what your product would look like if an agent did the work instead of the user clicking through it. If the answer is a chat bar, keep going.
Because they break things, and they need room to try. Ivan describes handing an agent a computer as being a bit like giving a young child a laptop. So the environment has to spin up fast, stay contained and be easy to throw away. Agents also don't need just one laptop. In a sandbox an agent can attempt a task 5 different ways in parallel, keep the best result and roll back the rest. Daytona adds the extras agents need for testing real applications, such as browsers and full desktops.
Try this: if you're testing agents internally, give them a separate environment with no access to production data until you trust the output.
With the job someone on your team does every day and finds boring. Ivan's example is a tire shop with 6 people sitting at computers entering names, car details and tire types. Classic RPA struggles there because no 2 customers are exactly alike. An agent can handle the variation. The win is the staff getting back to fitting tires. He makes the same point to agencies like Infinum: clients ask for web apps and mobile apps, and the next brief might be an agent.
Try this: ask each team lead one question this week. What do you do every single day that's repetitive and boring? Rank the answers.
Enough to check the work. Agents hallucinate, and they don't fail the same way twice, even on a task that should be identical every time. Ivan's model is Waymo: the cars drive themselves, and remote drivers step in for edge cases. One person can oversee several agents and still save a lot of time compared with doing the work by hand. He also mentions Klarna, which announced AI-only customer support and then rolled it back, keeping human agents and using AI internally.
Try this: for every agent workflow, name the person who signs off on the output and how long the check should take.
Experiment constantly, and don't wait for someone to sell you the answer. Ivan's view is that there's no off-the-shelf agent you can buy and be done, the way you'd pick an ERP or a CRM. Consultants can't hand you a solution that doesn't exist yet. His advice is to stay close to the tools, use ChatGPT and Claude every day, and come back to things that didn't work. Something that fails today might work well in 3 months. The mistake he sees most: people try something once, decide it's garbage and never touch it again, while competitors keep compounding.
Try this: keep a running list of tasks agents failed at. Retest it every quarter.
Ivan expects agents to augment people far more than replace them, at least at today's quality. He says he has never seen an agent live up to end-to-end task completion. He does point to a signal in coding: big tech headcount has barely grown over the last 3 years. He expects many fields to split into an artisanal end and a high-volume end. If every company has unlimited AI sales reps, cold outreach drops towards zero value, and a salesperson who shows up in person becomes worth more. McDonald's and Michelin-star restaurants both still exist. Genuinely new creative work, he says, stays human.
Try this: look at your own role and split it into high-volume work and work that needs you in the room. Hand the first to agents and spend the time on the second.
Checking how your message will land before you send it. Ivan pastes important emails into an agent and asks how it would interpret them. What's the emotional effect? Does it come off too strong? Is he being passive aggressive? He does the reverse with emails he receives, to check his reading matches what the sender meant.
Try this: before your next difficult email goes out, ask an agent how the recipient is likely to read it.
Your Majesty and Infinum help companies design, build and launch digital products, including agent-based systems.
DELIVERED is a production of Infinum and Your Majesty.