Lovable can now create subagents to help it research, explore, and search your project in parallel. The result is faster builds, sharper answers on bigger projects, and often a lower bill since lighter work gets routed to cheaper models. You don't have to do anything different. They just show up when Lovable needs them.
But what exactly is a subagent?
Picture a head chef in the middle of a dinner rush. Tickets are printing faster than they can read them and the pans are hissing. To get every plate out on time, the chef can’t be the one chopping, plating, and running to the pantry. If they did, they would need to do these things sequentially: chop first, plate next, then go check stock. They are only one person, so they can’t do them all at once. In reality, that head chef has a team with them in the kitchen. To maximize the speed and quality of the operations in the kitchen, the chef sends somebody to do each task: one person is chopping, one person is plating, and one person is grabbing stock. The chef stays at the center calling the shots, while the work happens all around them in parallel.
That's roughly what just shipped in Lovable today. We are introducing subagents.
In the analogy above, the Lovable agent as you know it (the head chef) can now create subagents (the chopper, plater, pantry runner) to do work in parallel. The exact number depends on what the task needs, but it's usually more than one at a time. Each one gets a specific job, like looking through part of the project or researching something online, and comes back with what they found. Subagents can dig deep, through your whole codebase, across the web, into whatever the task calls for. The one thing they can't do is change your code. That part stays with the main agent. We designed it this way on purpose: it means subagents can move fast and explore freely without any risk of touching your app.
Why subagents
The problem was that on large projects, Lovable can be slow. You've probably felt this. You send a message and watch it churn for a while before anything starts happening. A lot of that time is spent on the discovery process: reading through your codebase (all the files that make up your app) and understanding the code before making changes. On larger projects, there's just more to look through: more files, more features, and more places a change could ripple to. You have to wait for all of that before Lovable can do anything. And the more Lovable has to hold in its head at once, the harder it is to stay sharp. Things can get muddied and details from earlier in the conversation can slip.
With subagents, that discovery happens in parallel instead of one step at a time. Multiple tasks at once means faster builds, especially on the projects where it used to hurt most. And because subagents are read-only, your project never changes during this process. They look, they report back, and the head chef decides what actually gets cooked.
A peek under the hood
Under the hood, all that's happening is the main agent is sending the subagent a prompt, the same kind of thing you type when you give Lovable a task. It's saying "hey you, go research this part of the codebase," and to another one, "you go research this deeply on the web." Obviously the real instructions are a lot more intricate, detailed, and thorough, but that's the gist. The subagent then goes and does its work.
The other big benefit is that each subagent gets its own context window. A context window is basically the agent's short-term memory: everything it's currently thinking about, all the files it's read, and all the back-and-forth so far. Every AI model, including the ones powering Lovable, has a limit on how much it can hold in its head at once. The more an agent stuffs into it, the harder it is to stay focused, kind of like trying to follow a conversation in a noisy room.
A subagent starts with a fresh one. It's not carrying around the main agent's history or the other subagents' work. It can focus entirely on the one task in front of it. The subagents don't talk to each other, either. They each just report back to the main agent. The main agent waits while they work, then gets a summary from each one. Think of it like a research note: "here's what I found, here's where it lives, here's what matters." Just the findings, not the whole research process it went through to get there.
So the main agent's own context window stays clean. It gets the answer it needs without absorbing all the work that went into producing it, and it can keep going.
What this changes for you
And the best part: you don't have to think about any of this. Lovable will spin up subagents for you automatically, in the background. Nothing changes about how you use Lovable, and there's no extra cost. Subagents are just part of how Lovable works now. In fact, builds may end up a little cheaper: lighter work gets routed to faster, cheaper models, so the most powerful ones are saved for what actually matters. You'll see them show up in the activity view alongside the usual reads, searches, and edits, so you can watch what they're doing in real time, and trace any decision back to the subagent that made it. You'll just notice that Lovable feels faster on complex tasks, gives better answers when your project gets big, and seems to "know" your codebase more deeply.
That said, if you know you're about to ask for something big, like a deep exploration or a serious piece of research, you can tell Lovable to "use subagents" and it will.
When to ask for them
Here are a few examples of when you might want to ask for subagents directly. Each one shows off a different angle of what they're good at:
**1. Exploring an unfamiliar codebase
**
"Use subagents to explore my project and tell me what's going on. I haven't touched this app in two months and I forget how half of it works."
**2. Implementing a new feature with research
**
"I want to redo my pricing page. Send subagents to research what makes a great pricing page work, and have another look at my current page to see what's landing and what isn't."
**3. Debugging some issue
**
"Users are saying my dashboard is slow, but only sometimes. Use subagents to look through the dashboard and anything connected to it, find what might be causing it, and tell me how to speed it up."
**4. Planning a bigger change before committing
**
"I'm thinking about adding comments and likes, my app's getting some traction and people keep asking for it. Let’s use subagents to research how social features are usually built into apps, go through my current pages to figure out where it would fit, and tell me what I'm signing up for before I start."
I hope these examples are helpful.
This is the first version of subagents. Read-only is where we're starting, because it's where the biggest gains were, and it's where we wanted to build trust first. More is coming if you, the community, want it.
Lovable just got a little less alone in the kitchen. Same chef, but more hands!
