Lovable detects sessions where users get stuck, extracts solutions from cases that later recover, and injects that context into future agent sessions.
2
A vent tool lets the agent report missing tools, confusing documentation, and platform failures directly to Slack when those problems block its work.
3
Vent spikes can reveal production incidents, while another agent deduplicates reports, investigates them, and creates pull requests for engineers to review.
Summary
Benjamin Verbeek describes two continuous improvement loops at Lovable. The first finds sessions where users became stuck and later succeeded. Lovable clusters similar cases into reusable knowledge entries, evaluates whether the entries help in production, and removes them when models or product features make them stale. A holdout group shows whether injected context actually improves project success. The second loop gives the agent a vent tool. It can report missing or unsuitable tools, unclear schemas, broken platform behavior, and repeated failures caused by environment limits. These reports go to Slack, where an automated agent removes duplicates, investigates issues, and opens pull requests. Verbeek gives a file-copy bug as an example: reports about filenames containing spaces exposed a failure that had not appeared in logs, including a later bug involving non-breaking spaces. Vent volume also rose during platform incidents, making it a useful operational signal. The talk argues that continuous learning requires feedback tied to real user outcomes and fixes that return to production.
Lovable can learn from long-running project sessions
Verbeek frames continuous learning as making a mistake once and avoiding it afterward. Lovable's users often stay with one project for a long time, unlike users of short-lived chat agents. That gives the company more context about the user's goals and the point where work breaks down. The product targets people who cannot code, so a technical block can make them abandon the project entirely. Verbeek says the system must reduce these red-bar moments because nontechnical users generally cannot repair configuration, environment, or API-key problems themselves.
Lovable uses recovery after a stuck session as a high-signal training case
The system looks for signs that a user is stuck, such as repeating a request, explicitly complaining, or abandoning a session that would otherwise have continued. It separates problems that can be solved with better prompting from problems that the current product cannot solve. A strong example is a laggy website. The agent first claims to fix the problem, makes it worse, and then eventually discovers that individual gradients on overlay text are causing poor performance. The transition from stuck to successful gives Lovable a concrete problem and solution pair.
Clustered recovery cases become reusable context for future agents
Lovable turns recovered sessions into Stack Overflow-style knowledge entries. It clusters similar problems so the resulting advice does not overfit one exact prompt. An external reviewer, usually an agent and sometimes a human when the case is uncertain, generates the entry and runs a quick evaluation against the examples. A lightweight model detects when an entry may apply and injects it into the main agent's context. This gives future users a chance to reach the solution without repeating the earlier failure.
A holdout group measures whether injected advice helps real projects
Lovable sometimes detects that context should be injected but sends nothing. That creates a comparison between projects where the advice was used and projects where it could have been used but was withheld. The team compares overall project success and shows the entry more often when it helps. Verbeek says this is needed because knowledge becomes stale when a model or product feature changes. Old entries can cause context rot, so the system must rebalance the collection and discard advice that no longer works.
The agent can report platform limits through a vent tool
For problems that are not solvable within the current setup, Lovable gives the agent a way to complain directly to its creators. The vent tool is intended for missing or unsuitable tools, unclear names or schemas, conflicting documentation, broken platform behavior, and repeated failures caused by environmental limits. The agent has more context than the user about what it tried, so its report can identify the underlying obstacle. Reports are sent directly to Slack, where engineers can understand them as concrete workflow complaints.
Lovable's copy tool appeared to work when engineers checked it, but the agent reported repeated failures when filenames contained spaces. The team received about 20 complaints in the first hour after launching the tool. The initial fix handled ordinary spaces, but screenshots from WhatsApp or a Mac could contain non-breaking spaces, which the regular expression did not replace. Further reports exposed other special characters until the team fixed the issue properly. Verbeek presents this as a failure that logs did not reveal clearly, while the agent described both the condition and the needed workaround.
The vent flow sends an agent's complaint to Slack, and a second agent now monitors the channel, removes duplicate reports, investigates issues, and creates pull requests. Engineers still review and often merge those changes into production. Verbeek shows that event counts spike when sandboxes or other platform components break. The agent complains more during these incidents, and its reports generally point toward the affected area. The same automation now sends review requests for generated pull requests, moving the process from detection toward a loop that detects a shortcoming, merges a fix, and evaluates the result.
