AI Engineer Code Summit · Wed 11 Nov 2026 · Continental 4–6 (Mainstage)

The output is a business

Lovable's agents now work for ten hours or more, at over a billion tokens a minute. Fabian Hedin shows what that took: a runtime that survives seven hundred deploys a day, computers that start and fork in a fraction of a second, and two loops of verification. The outer one is the one to watch: because Lovable owns payments, email and analytics, the agent can learn from how the product is doing, not just whether the code builds.

Fabian Hedin, Lovable · 19 min · Links and further reading
The premise

Outcomes, not code

The recording opens on the history: early multi-agent systems, then a simpler single-agent design that was responsive and reliable, and now agents again, at scale.

“over a billion tokens per minute on this system that I'm going to talk about.”00:00:00

The interface hasn't changed since 2023: a chat where people describe what they want, a preview showing the result. What's changed is how complex the result can be. Lovable's thesis:

“You won't have to care about the code in the same way that you had to do before”00:00:42
“But in the end, what matters is actually not the code.”00:02:04

What matters is the outcome, and for users that means

“Is creating a business and monetizing and creating value for others in some type of way.”00:02:04

So the platform has three parts: the agent, which builds, verifies and pushes to GitHub; the cloud, hosting primitives it can inspect; and the business part, because the output isn't code. Payments, emails, SEO, Google and Meta ads, analytics on conversions,

“and the agent is in the loop. In all of this, right?”00:02:29
From the notes: “i like the business functionality that lovable has built in, that's a key part of the system”. It's key for a reason the talk only reveals at the end: owning payments and analytics is what lets the agent's outer loop see real business results. The reading: most coding agents stop at the pull request. Lovable's can see whether the change sold anything.

Evidence: transcript 00:00:00, 00:00:42, 00:02:04, 00:02:29

The change

From 30 minutes to 10 hours

“we used to limit our agents to work for only thirty minutes.”00:04:32
“Because we thought they weren't reliable to work for longer amount of time.”00:04:32

Now there's no limit:

“And so you can imagine agents working for ten hours.”00:04:32

Three pieces made that possible: the runtime, which has to keep going that long; the computer, where each agent runs a web server and checks its work; and verification, because

“If you want an agent to work for a long amount of time, you need to make sure that you have these feedback loops in place”00:05:00
From the notes: “lovable used to limit agents to 30 minutes but now its 10+ hours”. It's the horizon Simon Willison described the same evening for Fable-class models: set up the goal and the tools, and twelve hours later it's solved (It doesn't get easier). This talk is the infrastructure side of that.

Evidence: transcript 00:04:32, 00:05:00

The runtime

An inbox per agent

An agent hears from three kinds of sender: a human, other agents, or a system on a schedule waking it up.

“And the way we chose to architect this is that for each agent, we have a separate inbox.”00:05:39

Messages such as “What's the status?” land while the agent works. When it finishes a step, a request, a tool call and its result, it takes them in:

“Since anyone can drop a message into his inbox, the agent then can copy that itself.”00:05:39

It copies them into its own task history, which Lovable calls the trajectory.

From the notes: “there is an inbox concept”. The design choice is that nobody writes into an agent's history directly: humans, agents and schedules all post to the inbox, and the agent decides when to take messages in, between steps. That's what makes an always-on agent interruptible without derailing it.

Evidence: transcript 00:05:39

The memory

A trajectory modelled on Git

“And we designed this trajectory with really Git as inspiration”00:06:56

It's an append-only log in which each event points to its parent. Two events can share a parent, which makes a fork, so parallel agents can be spun off from any point without copying the history they share. Merging is another matter:

“Semantically, it's a bit unclear what would happen if you merge this.”00:06:56
“So unlike it, we cannot merge agent trajectories”00:06:56

The forked agents talk to each other instead. The log holds everything, and the prompt is built from it, not equal to it; compaction depends on the model's context length.

“And so, by separating the prompt from the actual task history.”00:08:00
“We're able to render problems for any type of model or any type of task.”00:08:00

(“Problems” is the transcript's prompts.) His debug tool re-renders the UI at any of 156 events as he drags a slider. And the process running an agent is almost stateless: after each turn it writes to the history, so any process can pick up the work. That matters because

“As a whole, this system we deploy to it 700 times per day.”00:09:49

including urgent fixes such as a Linux kernel vulnerability, and a ten-hour agent can't restart each time.

From the notes: “the trajectory is an append only log but it can be forked/split like git”. The reading: it answers two talks from the same afternoon. Yegge warned that agent memory becomes a garbage dump (Every problem is a fuel problem); Lovable keeps everything but never feeds the raw log to the model. Diogo asked why parallel agents can't share what they've learned (Too good to be true); forks share their whole history up to the split. An append-only log is good evidence; the prompt is the working memory.

Evidence: transcript 00:06:56, 00:08:00, 00:09:11, 00:09:49

The computer

Computers from a golden checkpoint

“And we've been through a lot of situations and a lot of vendors”00:11:24

They landed on their own system: checkpointing whole computers. A golden checkpoint holds the OS and system services, common tools and a dev server ready to start, including memory and running processes.

“all of them you copy it over in about 230 milliseconds.”00:11:24

Each project gets its own checkpoint, saved after every agent turn, so a computer can sleep and come back in moments. The same trick forks running computers, which Lovable's Drafts feature uses to try several versions at once:

“we can also port the computer.”00:13:02

(“Port” is the transcript's fork.) Memory is copy-on-write, so

“Creating one of these forks of a computer is. It's basically free in terms of the RAM that it's using.”00:13:38

and memory streams in, so a machine boots before all of it has arrived. Then they forked the JavaScript dev server and rewrote it in Rust:

“We went from getting this preview from 40 seconds to three seconds”00:14:48
“That made the memory footprint be 6.5 times less in these machines.”00:14:48
From the notes: “they went through a lot of computer providers/sandbox providers”. In the end they built their own, at around a million sandboxes a day. The transcript's “Niteshift” for the dev server comes from the transcription prompt; the dossier identifies it as Vite, forked into OJ, which is open source (see the links page). The reading: fast, forkable computers make parallel exploration cheap: agents can try several fixes and keep the one that works.

Evidence: transcript 00:11:24, 00:13:02, 00:13:38, 00:14:48

The spine

Two loops: fix it now, improve it later

After every action, the agent needs to know whether it was a good one.

“You can think of it as this inner loop and this outer loop.”00:16:03
“So this inner loop is during the turn of the agent.”00:16:03

Within the turn: does the build work, linters and type checkers, runtime errors in the preview, a headless browser exploring the app. His slide adds judges, domain scanners, backend logs, guardrails, and fixes the user triggers.

“but then you also have this outer loop, which is. Between each turn”00:16:03

Between turns, information arrives from production: how visitors behave, what users say online, automatic A/B tests on a change of copy. And because Lovable runs the payments, transactions and conversions too, the agent can

“help you optimize not only. The code right, but the business strategy around your product.”00:16:03

His slide's footnote draws a line: production outcomes reach the agent only as next-turn findings, never as a training signal.

From the notes: “the lovable inner and outer loops are super interesting”, the note marked as the key one. The reading: this is where the business functionality pays off. The inner loop checks the code; the outer loop checks the product, and only a platform that owns payments, email and analytics can close it. It answers Diogo's line between assistance and automation: the inner loop makes one turn reliable, and the outer loop gives a ten-hour agent a reason to change course. It also fits two Cognition notes from this morning: teach agents how to test the codebase, and use sessions for self-improvement. For a client: what is their outer loop, and can their agents see it?

Evidence: transcript 00:16:03, 00:17:54