# What it takes to set intelligence free — Fabian Hedin — session 2026-11-12T00:30:00.000Z → 2026-11-12T00:50:00.000Z _58 transcript lines · 39 slides_ ## Transcript 2023 as it is today. To the left, we have a chat where humans come in, and they kind of describe their their intent to to build or whatever they wanna do. And to the right, you have a preview, which is the output or or the outcomes of, of what you're building. And this, back in '23, you could do simpler things with. Right? But now we've really seen... Working at this layer of abstraction, you're able to build very complex things. Right? And I think we've even seen a lot of Tooling meant for for developers, for example, moving to this type of interface where you're not really looking at the code every day and so on, and you're getting, kind of abstracted and working on on beat architecture, or looking at some kind of output of of what you're doing. And this is something that we've always believed in, and it's been kind of a core thesis behind Lovable that you won't have to care about the code in in the same way, that you had had to do before. And I think today, we're kind of in this almost a bit in I think in the industry where, you know, some people might say, oh, you don't have to care about code at all, and some people might have different opinions. I, of course, like, growing up coding and these things, you get a bit attached, but in the end, what matters is, it's actually not the code. Sorry if we remove that last part, but what what matters is is the outcomes. Right? And so, the outcomes, what is that? Well, for for our users, the outcomes Is creating a business and monetizing and creating value for for others in in some type of way. And I'll kind of quickly go over, what we build as a platform to to enable this before I go in kind of on the on the technical side of this talk. So if you if you look at Lovable, the first thing that that you can say about the platform is that we have this agent, and like any other agent, it can do quite arbitrary things, and it's quite specialized at at building Software, and it has access to a browser, so it can verify what it's building, and, it connects to to GitHub, and, you know, it writes code that, and you can do whatever you want for that code, so on. So that's, kind of your basic, coding coding agent. And the the other pieces of the platform is this kind of cloud and and business piece of the platform. And so, the cloud part of the platform is is about just giving kind of these, hosting primitives just seamlessly to to this agent. And so we we built out databases, authentication, storage, all types of back end compute and security scanners and, like, backups and logs for all of these things, and all of it can be introspected by by the agent. And this just makes it seamless to to build things. You don't have to kind of, go to different services to this together. We just kind of provide you, these primitives. So that's still around building software and hosting this. Right? But then the last piece is around, these business capabilities where Again, the output of what our users are doing on Lovable, we don't see that output as code. The output is a product or or a business, and if you wanna succeed as a business, you need to do more things than just write code, right? And so we we we help our users with, receiving payments, sending emails, optimizing SEO, doing ads on on Google and Meta, and kind of analyzing what is happening with the product through, through analytics, and you can look at kind of Conversions and and optimize these sort of things, and the agent is in the loop in all of this. Right? So that's kind of our, capability offering, you could say. And again, the core part of this is an agent that all of these capabilities are built for. And at some point in Lenovo's history, we used to limit our agents to work for only thirty minutes because we thought they weren't reliable to to work for a longer amount of time. But, now we've changed this to really be Without any any sort of bound in terms of the length an agent can work, and so you can imagine agents working for for ten hours plus. And so I'll I'll go into some of the things that we've done, in our architecture to to enable this. And so the first piece is really around the agent run time itself, and how how we enable that to to run for a long amount of time. And the second piece is the computer where, each of these agents are actually doing their work, running a dev server. And then actually verifying what it's doing. And so so the last piece then, it's the verification itself, where if you want an agent to to work for a long amount of time, you need to make sure that you have these feedback loops in place so that it's not kind of going off, in in in the wrong direction. And so if we start by looking at the agent runtime itself, you can imagine that, you have really three different sources that can interact. An agent. So it can be yourself kind of prompting this or or a human. It could be other agents, and it could also be just a system on on a schedule waking up. And the way we chose to architect this is that for for each agent, we have a separate inbox, where, any of these sources would kind of send in messages. And so you might have a message here, like, what's the status? And you can imagine you have this agent, and this agent is kind of an always on agent that that might be working. Right? And so, you can imagine it has done. Like, free actions here, I request a tool call, and it got some some result. And then at this point, the agent is ready to actually receive, messages. So, since anyone can drop a message into this inbox, the agent then can copy that itself into its own, what we call it, trajectory. Basically, it's a task history. And this type of interaction that I think you're familiar with if if you're using agents overall. So that's kind of the the first design principle behind this agent runtime. I'll go through a a few more here. And so, the the trajectory in which the the agent is working in, which is kind of the history of what has happened so far, and really the basis for any sort of, of memory, for for for the agent. Right? And we designed this trajectory with, really, Git as inspiration. And so the trajectory, what is it? It's an append only log, where each event, points towards a a parrot. The previous event. And because of this, you get a nice capability just like in Git where you can fork things. Right? So you can have two events pointing to the same parent, which essentially creates a fork. And because of that, you can kind of spin up parallel agents at, at any point of time in the history without having to duplicate all of the, kind of the shared history. And, semantically, it's a bit unclear what would happen if you merge this. So unlike it We cannot merge agent trajectories, but we can kind of, spawn them out. Right? And these agents can can talk to each other. The other thing that, we made sure to design for is that this, agent trajectory, it includes kind of the full history and and everything that happens, with the agent, and so every tool call, a bunch of other things happening on the platform, if a tool call, like, failed or succeeded, and a bunch of them. What we've done is make sure that we have this, append only log, and and from that, we can Actually build a prompt that we would feed into into the actual LM. And, you might ask why why would you wanna do this? Well, one one reason is that, when you build a prompt, you... If you have a long history, you probably want to do some sort of compaction, and you wanna summarize part of that history, in in the earlier steps, for example. But this summarization would differ, for example, if you use different models with different context lengths, you would probably think differently about when you should summarize or not. And so by separating the the prompt from the actual task history, we're able to Under prompts for for any type of model or or any type of task, that, that that we can kind of find the best and optimal prompt for. So to show this event history in in progress, we have this debug tool here. So here it's just recording of me dragging this slider in our UI, and you can see on the right that, the UA is kind of updating as I'm as I'm dragging this along, and you have 156 events here, and one... Each of those is an event in this event history. And you can See how how the UI can render kind of any point in history. And this is just showcasing that, at any point in time, we have full control of, of, say, the UI or or anything else happening on the... This platform, thanks to, this history kind of detailing everything that has happened. The the last piece I'll go over here on the on the runtime itself is that, the process that is running these agents, they're separate from from the actual task history. And so The process is, almost entirely stateless in that, between each each call, each tool call, each turn, it will actually just persist into the task history, and so you can have a process come and go. And and and then the question is, why why do we care about this? This? Well, at Lovable, this system, we deploy to it, 700 times per day. So that's about once every two minutes. And you can imagine if you have a agent working for For ten hours, you want to, not disrupt that agent when it's working. Right? This this agent is doing something for for a customer. But at the same time, we want to make sure that this agent is running on the latest deploy. And it might be a new feature or something like that, but it might also be, like, a security vulnerability in in the Linux kernel, and it's like, okay, we need to update this ASAP. And and so to do that, thanks to this separation between the actual history and and the processes, we can actually, make sure that we have One one agent that is working on one task, but we can have different processes, taking up and actually doing the compute behind that work. So so this task can keep on working while we have, different deploys working on it, be it for ten hours or or even longer. Right? So that's the agent run time. The second piece of, of this platform, right, is the is the computers. This is where the work is actually happening. And we've been through A lot of iterations and, a lot of vendors kind of working with, providing these sandboxes for for the computer for, for the agent to work in. And we've landed in in the system that we've worked really hard now to develop, which is, checkpointing a computer, and so you can imagine you're comfortable, you start a new project. We have this common, what we call a golden checkpoint, which contains the OS and the system services. It has common tools installed, and Server that is ready to start. And this checkpoint, it it includes everything on disk, memory, and also running processes. And and so when you start a new project, you get all of that for free, and, all of that copied over in about two hundred and thirty milliseconds. And so once you start a project, you you might have some specific code and and some dependencies within that project, and, that is also check pointed as you go. And and so each time the the Is running and, it finishes a turn, we will actually save a checkpoint of that computer. And and from that, we're able to, again, like, very quickly, sub second, spin that computer up whenever you need it. That means we can save on on resources by kind of spinning this down. If you leave for, say, ten minutes or or so and come back, we can just spin it up extremely quickly so you don't even notice this. And even, kind of requests, in transit will will not even be dropped in in this setup. The other thing we can do, thanks to, this checkpointing, is that just like the trajectory itself, in the agent run time, we can also fork, the computer. And when we do this, we have... For example, we have, a feature in in level that is called draft where you kind of work in different environments of what you're doing. And and to support that, we need to fork the computer that you're working in. And, here we have, kind of, the example of Two at the same time, and, you can imagine doing hundreds of these. Right? And so we've we've had to do some optimizations to make this feasible to to actually run. So one of these optimizations is copy on write on the RAM itself. And so creating one of these forks of a computer is, is basically free in terms of, of the RAM that it's using, but, as soon as you start writing, in in a process to to RAM, we will kind of copy that page over, and Then will you start having to allocate new memory. And and there's another optimization here also, which is that, each of these sandboxes require a few hundreds of, megabytes of memory, but... And that would take a few seconds to stream in if you have it in, like, cold storage, and then it has to go to disk, and then then into memory of this, this VM. But thanks to, being able to stream the memory, we can actually boot up the The machine before all of the memory is, is actually, ready on it. So, the the memory they always use comes first, and then, like, some processes and so on will will start to work as soon as the memory gets there, and this also shaves off, some some extra startup time. And then we started asking ourselves, how can we make this even more efficient and even more faster for our users? And so you might be familiar with Vite. It's this great dev server that most of the meta frameworks out there in the JavaScript ecosystem is using. And so we We took that, and we forked it, and we rewrote it in in Rust. And, that made our cold stars, two times faster, and we went from getting this preview from fourteen seconds to to three seconds. And the main, kind of thing that we made faster here is that Vite uses Node JS, and we're able to, like, drop that dependency off Vite itself and just have this Rust binary. So, that made the memory footprint be 6.5 times less, in these machines. And by taking control of the applications that we're running in these computers, we're also Able to control kind of how we write to memory. And so when we control how we write to memory, we're even more optimizing if you remember back to the kind of the copy on write solution when we're drafting different, different computers. And so we're able to, run this extremely efficiently so that we can run, lots and lots of agents in in parallel and kind of have agents explore different solutions to solving a bug or improving the performance of of your applications and and so on. And so this has been fun. But the last piece now is is about verification. And, of course, this kind of computer and this dev service is a big piece of being able to verify what an agent is doing. And if you look at verification, you can think of these feedback loops. Right? That the agent needs to get information, it took an action, was this a good action, or was it a bad action? And, you can think of it as this inner loop and this outer loop. So this inner loop is, during the turn of the agent, and you have kind of With things such as, like, the, is the build working? Do we have lint errors or type errors in the code that we're running? And then you can check for runtime errors in in the preview that you're running. You can also have, within this computer, a headless browser where the agent can go in and kind of explore, the the web app it's it's building or whatever it's building. Right? And and a bunch of other things that we're using to help verify within the turn of an agent. But then you also have this outer loop, which is, you know, between each turn, and the turn you can think of, like, when Agent is yielding to you as a user. And between each turn, you might get some info on on the product itself, from from production from your users. Right? And so you can look at how your visitors are behavior are behaving, what users are are telling you online, you can do automatic AB tests, and actually see, change some copy and see if it's improving conversion and so on. And then you can also take these business metrics, and and remember, this goes back to kind of the capabilities I showed you. By having, control over these things We can make sure that we can optimize how the agent is is getting this out of feedback loop. So we can make sure that if you're running payments, we can actually, track those transactions and conversions, and make sure that, the agent can actually help you optimize not only the the code, right, but the the the business strategy, around around your product. And so those are really the the three things that, that we've been working for, and we'll continue to kind of build up Out, these, these capabilities and this architecture around really orchestrating these LMs into into agents. And so, this agentic system that we're building, it's running billions of tokens per minute, and these computers, right, we can spawn up with each agent, and we can have multiple agents use one computer. And now we're kind of back to this, quite beautiful setup where we have agents talking to agents, and they're orchestrating. And and this time, it's, it's actually work. And it's working at scale, thanks to some of these optimizations. And so if you're curious to try this out, you can head to level.dev, and you'll you'll see our our preview spinning up and and so on, but you'll get a very simple and, a nice interface, and you won't have to care about all of this stuff. Thank you so much. It's been a pleasure, and, yeah. Hope you hope you learn something. Thanks so much. Building a coding agent is one thing. Building an engineering culture around it is another. To share how agent driven development is transforming the way teams work, please welcome Zach Brueggemann, principal software engineer at Ramp. Thank you so much. So let's get a second here. Any forty niners fans? Okay. You know, that's a better reaction than I've gotten to other events this year when I've asked, you know, about their local sports teams. I've gotten a lot of just, like, muted science. I've hit the, you know... Well, wrong audience for that type of joke, but glad at least they can hit this. Time. Do you need help? Do you wanna just go for it? Okay. I'm fine about that. Current slide on this and then... That works. Yeah. Yep. Yep. ## Slides ### 00:00:23 # We're back (This time agents actually works.) ### 00:00:54 # The UI is a chat and a preview Type what you want. The app changes in front of you. ## What it takes to set intelligence free Fabian Hedin / CTO Lovable [Screenshot of a UI mockup showing a chat interface on the left and a preview area on the right] [QR code for live translation] ### 00:01:23 # The UI is a chat and a preview Type what you want. The app changes in front of you. ### What it takes to set intelligence free Fabian Hedin / CTO ### 00:01:54 # The UI is a chat and a preview Type what you want. The app changes in front of you. ## What it takes to set intelligence free Fabian Hedin / CTO **Lovable** [https://lovable.dev](https://lovable.dev) [Diagram of a user interface showing two main panels: a "CHAT" panel with example chat messages and an input field, and a "PREVIEW" panel displaying a wireframe layout of an application] ### 00:02:20 # What matters is outcomes. [Gradient background with a blurry organic shape] ### 00:02:55 # What it takes to set intelligence free ## Agent - Full-stack apps - Build, run and test - Browser verification - GitHub + code ownership - Generate MCP servers - Connect tools + APIs ## Cloud - Database + authentication - Storage + realtime - Edge functions + jobs - Hosting + custom domains - Security scanners - Backups + logs ## Business - Payments + subscriptions - Emails - SEO + AI search - ### 00:03:21 ## Agent - Full-stack apps - Build, run and test - Browser verification - GitHub + code ownership - Generate MCP servers - Connect tools + APIs ## Cloud - Database + authentication - Storage + realtime - Edge functions + jobs - Hosting + custom domains - Security scanners - Backups + logs ## Business - Payments + subscriptions - Emails - SEO + AI search - Google + Meta ads - Analytics + conversions - Growth plans + outreach What it takes to set intelligence free Fabian Hedin / CTO Lovable [https://lovable.ai](https://lovable.ai) ### 00:03:54 # AI Engineer Code Summit ## Presented by Google DeepMind ### What it takes to set intelligence free ### Agent - Full-stack apps - Build, run and test - ### 00:04:21 ## Agent - Full-stack apps - Build, run and test - Browser verification - GitHub + code ownership - Generate MCP servers - Connect tools + APIs ## Cloud - Database + authentication - Storage + realtime - Edge functions + jobs - Hosting + custom domains - Security scanners - Backups + logs ## Business - Payments + subscriptions - Emails - SEO + AI search - Google + Meta ads - Analytics + conversions - Growth plans + outreach ### What it takes to set intelligence free Fabian Hedin / CTO Lovable [https://lovable.ai/](https://lovable.ai/) ### 00:04:54 # What does it take to run an agent for 10+ hours? ### What it takes to set intelligence free Fabian Hedin / CTO **Lovable** [https://lovable.ai/](https://lovable.ai/) ### 00:05:26 # What does it take to run an agent for 10+ hours? ## 1 Pick up and plan its work - Read the history - Call the model - Run ### 00:05:55 # The agent runtime: Always-on Agent control plane (ACP) · Starts agents, and wakes one up when its inbox gets a message - **Inputs to Inbox**: You, ### 00:06:27 # The agent runtime: Always-on Agent control plane (ACP) · Starts agents, and wakes one up when its inbox gets a message - You - Other agents - Scheduled wake- ### 00:06:49 ## Fork the task history at any step Main - Improve performance - Start - Read file - Edit file - Test: ok - Done Fork - Rewrite it in Rust - Edit file - Test: ok Each event points to the one before it. A fork points to the same parent and copies nothing. ## What it takes to set intelligence free Fabian Hedin / CTO Lovable [https://lovable.ai/](https://lovable.ai/) [Flowchart showing a main task history path with steps: Improve performance, Start, Read file, Edit file, Test: ok, Done. A fork branches from "Read file" with steps: Rewrite it in Rust, Edit file, Test: ok.] ### 00:07:23 # Fork the task history at any step Each event points to the one before it. A **fork** points to the same parent and copies nothing. ### What it takes to set intelligence free ### 00:07:59 # We build every prompt from the task history ## Task history - every event, in order - **Add discount codes** - Read `checkout.ts` - Edit `discount.ts ### 00:08:30 # We build every prompt from the task history ### Task history - every event, in order - Add discount codes - Read `checkout.ts` - Edit `discount.ts` - Expired code accepted - Fix the expiry check ### What the model sees ## Prompt for this step Instructions - **System instructions** - **Selected knowledge** Earlier steps, summarized Recent steps, in full - Edit `discount.ts` - Expired code accepted - Fix the expiry check ### What it takes to set intelligence free Fabian Hedin / CTO Lovable [Flow diagram illustrating how a prompt is built from a task history, showing a sequence of task events on the left leading to the prompt structure on the right.] [QR code linking to https://lovable.ai/] ### 00:09:03 # Replay a run, event by event ### Documentation feature overview Can you research our docs, and give an overview of the different features. Make extensively crawl the docs. Write results ### 00:09:30 # Replay a run, event by event ## Documentation feature overview - Can you research our docs, and give an overview of the different features. Make extensively crawl the docs. Write results ### 00:10:00 # The task history lives outside the process ## Process running the agent **Can come and go** - Read the history - Call the model - Run a tool - Write the result ## Task history - kept outside **Every event, in order** - Add discount codes - Read checkout.ts - Edit discount.ts - Expired code accepted - Fix the expiry check A run can stop between steps. Another process picks it up from the record. ### What it takes to set intelligence free Fabian Hedin / CTO Lovable [https://lovable.ai/](https://lovable.ai/) ### 00:10:35 # 700+ deploys a day. Agents keep working. ## Task history - one run, hours of work The process changes. **The task keeps going.** ### What it ### 00:11:03 # 700+ deploys a day. Agents keep working. ### Task history - one run, hours of work The process changes. **The task keeps going.** ## What it ### 00:11:34 # New computers start from a golden checkpoint A VM resumes in **230 ms** ## Golden checkpoint Prepared once: - OS + system services - Common tools installed ### 00:12:02 # New computers start from a golden checkpoint A VM resumes in **230 ms** ## Golden checkpoint **Prepared once** - OS + system services - Common tools installed - ### 00:12:35 # AI Engineer Code Summit ## PRESENTED BY Google DeepMind # We save the running computer, then resume it ### Agent turn: Running - Edited files - Installed packages - App ### 00:13:03 # Try different approaches from one snapshot ## Latest snapshot: One saved computer - Files - Running app - Local database - Memory ## Draft A Reschedule inside the app - **same start** + **its own changes** ## Draft B Reschedule by email - **same start** + **its own changes** Two approaches, tried side by side. **This is how Drafts work.** ### What it takes ### 00:13:34 # Drafts share memory until they change it ## Shared snapshot memory - **Draft A** - Reads the shared pages - Keeps its own copies of the pages it changed - **Draft B** - Reads the shared pages - Keeps its own copies of the pages it changed **Legend:** - Shared, unchanged - Original page, left as it was Drafts share every page they haven't changed. A page is copied only when a draft writes to it. ### What it takes to set intelligence free Fabian Hedin / CTO Lovable [https://lovable.ai/](https://lovable.ai/) [Diagram illustrating memory pages, some shared and unchanged, one copied on write, and how Draft A and Draft B interact with them] ### 00:14:03 # Load only the memory needed to resume A Lovable computer - dev server + database ## Hundreds of MB So a computer **streams in only the memory it needs** to keep ### 00:14:33 # Load only the memory needed to resume A Lovable computer - dev server + database Hundreds of MB So a computer **streams** in only the memory it needs to keep running. What it takes to set intelligence free [Grid of squares with a diagonal pattern of highlighted orange squares, representing memory blocks] [QR code linking to https://live.deepmind.com/ for live translation] ### 00:15:07 # Meet OJ: Vite, rewritten in Rust - **2x** faster cold starts - **14s → 3s** to get a ready preview Every preview runs a real dev ### 00:15:35 # OJ uses less memory, so more previews fit **6.5x** less dev-server memory than Node + Vite Measured before the app loads. More previews fit on the ### 00:16:06 ## 03 · Verification ### Agent runtime 1. Pick up and plan its work - Read the history - Call the model - Run a tool - Write the result ### Computer 2. A place to do its work - Saved - Files - Running app - Local database - Memory ### Verification 3. A place to check its work What it takes to set intelligence free Fabian Hedin / CTO Lovable [Flow diagram illustrating three ### 00:16:34 # Two loops: fix it now, improve it later ## Inner loop - during the turn ### The agent sees it and fixes it right away - **Build, lint + type errors**: Automatic ### 00:17:06 # Two loops: fix it now, improve it later ## Inner loop - during the turn **The agent sees it and fixes it right away** - Build, lint + type errors: Automatic - Runtime errors: Automatic + tools - Browser + visual checks: Tools - Judges in the turn: Automatic - Domain scanners: Tools - Backend logs + usage: Tools - Guardrails + notices: Automatic - User-triggered fixes: User ## Outer loop - between turns **The horizon between turns is long** ### Product metrics - Production signals: Automatic - Visitor behaviour: Automatic - What users tell you: Explicit - Automatic A/B tests: Automatic ### Business metrics e.g. payments: signups + conversions - Transactions + conversions: Automatic - Findings fed back: Next turn Production outcomes reach the agent only as next-turn findings, never as a training signal. ### What it takes to set intelligence free Fabian Hedin / CTO Lovable [https://lovable.ai/](https://lovable.ai/) ### 00:17:30 # Two loops: fix it now, improve it later ## Inner loop - during the turn ### The agent sees it and fixes it right away - **Build, lint + type errors** Automatic - **Runtime errors** Automatic + tools - **Browser + visual checks** Tools - **Judges in the turn** Automatic - **Domain scanners** Tools - **Backend logs + usage ### 00:18:06 # The foundations for agents to take on more ambitious goals ### FIG. 1 • A HUNDRED AGENTS, ONE GOAL ### What it takes to set intelligence free Fabian Hedin / CTO Lovable [Network diagram showing multiple interconnected clusters of nodes. Orange circles represent computers, small white circles are agents, lines are messages, and purple shapes indicate verified agents. One computer node is labeled "MOST CONNECTED COMPUTER".] [QR code] ### 00:18:31 # The foundations for agents to take on more ambitious goals FIG. 1 • A HUNDRED AGENTS, ONE GOAL ## What it takes to set intelligence free Fabian ### 00:19:00 # Code Summit ## AI Engineer ### 00:19:31 # AI Engineer Code Summit ## AI Engineer Code Summit 2026 Corey Quinn / Chief Cloud Economist duckbill 🦆 ## How to build an agent that builds the culture