Lovable Subagents: Parallele Recherche, ein orchestrierender Head-Agent

Was Lovable heute angekündigt hat

Am 27. Mai 2026 hat Lovable Subagents eingeführt (Original-Announcement von Tyler Bruno). Der Lovable-Agent, den ihr kennt, kann ab sofort mehrere spezialisierte Helfer-Agenten parallel loslassen – um Codebase zu durchforsten, im Web zu recherchieren, Zusammenhänge zu rekonstruieren. Jeder Subagent ist read-only, hat einen frischen Context-Window und meldet nur das Ergebnis zurück.

Das klingt nach einer technischen Detailoptimierung. In Wahrheit ist es der Schritt, der Lovable vom Single-Thread-Agent zum orchestrierten Multi-Agent-System macht – und damit eine der Voraussetzungen, die wir in unserem Recap der Lovable-Reise als "Lovable wird zum Agent-Framework" beschrieben haben.

Die Küchen-Analogie (von Lovable selbst)

Tylers Bild ist treffend: Stellt euch einen Head Chef in der Dinner-Rush vor. Wenn er chopt, plattiert und in den Vorratsraum rennt, geht alles sequentiell – ein Chef, eine Hand. Echte Küchen funktionieren anders: Der Head Chef ruft die Shots, ein Team erledigt die Tasks parallel.

Genau diese Architektur hat Lovable jetzt eingezogen:

• Head-Agent = der Chef. Sieht alles, entscheidet, schreibt Code.
• Subagents = die Crew. Recherchieren, lesen, durchsuchen – aber kochen nicht selbst.
• Eigene Context-Windows = jeder Subagent arbeitet auf einem sauberen Schreibtisch, ohne die ganze Konversation mitschleppen zu müssen.

Drei technische Punkte, die wirklich zählen

1. Read-only ist Feature, nicht Limit

Subagents können keinen Code schreiben. Das ist Absicht. Lovable wollte zuerst Vertrauen aufbauen und genau dort den größten Hebel holen, wo er liegt: bei der Discovery. Auf großen Projekten verbringt der Agent den Großteil seiner Zeit damit, eure Codebase zu verstehen, bevor er überhaupt etwas ändert. Genau diesen Schritt parallelisieren Subagents – ohne Risiko, dass etwas kaputtgeht.

2. Eigene Context-Windows = kein Lärm im Kopf

Jeder Subagent startet mit einem leeren Context-Window. Er trägt nicht die Historie des Head-Agents mit sich rum, nicht die Arbeit anderer Subagents. Er fokussiert sich auf genau eine Frage. Zurück kommt nur das Ergebnis – wie eine Research-Notiz: "Hier ist, was ich gefunden habe, hier liegt es, das ist relevant."

Der Head-Agent bleibt damit schlank und konzentriert. Das ist exakt das Pattern, das Anthropic mit Claude Code etabliert hat – jetzt nativ in Lovable.

3. Smartere Modellzuteilung = oft günstiger

Lovable routet leichtgewichtige Subagent-Tasks auf schnellere, günstigere Modelle. Die teuren Top-Modelle (Opus 4.7) bleiben für die Aufgaben, bei denen sie wirklich nötig sind. Effekt: bei großen Builds eher niedrigere Kosten, nicht höhere – obwohl mehrere Agents gleichzeitig laufen.

Wann ihr Subagents aktiv anfordern solltet

Subagents springen meist automatisch an. Aber bei vier Szenarien lohnt es sich, sie explizit zu adressieren ("Use subagents to..."):

1. Unbekannte Codebase erkunden. "Use subagents to explore my project and tell me what's going on." Klassisch nach 2 Monaten Pause auf einem alten Projekt.
2. Feature mit Recherche planen. "Send subagents to research what makes a great pricing page work, and have another look at my current page." Best-Practice-Suche + Status-Quo-Analyse parallel.
3. Debugging mit Streuverlust. "Users say the dashboard is slow, but only sometimes. Use subagents to look through the dashboard and anything connected." Mehrere Hypothesen parallel prüfen statt sequentiell raten.
4. Größere Änderung vor dem Commit verstehen. "Use subagents to research how social features are usually built and figure out where it would fit." Architektur-Recherche + Ist-Analyse, bevor irgendwas geschrieben wird.

Faustregel: Wenn die Antwort mehrere unabhängige Recherchefäden braucht, sind Subagents der Hebel. Bei einfachen Edits bringen sie nichts.

Was das strategisch bedeutet

Subagents sind nicht nur ein Performance-Patch. Sie sind der architektonische Übergang vom "ein Modell macht alles" zur Orchestrierungs-Schicht, in der Lovable selbst entscheidet, welcher Task auf welches Modell mit welchem Context geht. Drei Konsequenzen:

• Lovable wird zum Multi-Model-Hub. Routing zwischen Opus, Haiku und kleineren Spezialmodellen passiert unsichtbar – das ist genau, wofür das Lovable AI Gateway gebaut wurde.
• Skills bekommen einen neuen Wert. Skills sind die natürliche Form, um Subagent-Instruktionen wiederverwendbar zu machen ("Subagent X soll bei Frontend-Recherche immer X, Y, Z prüfen").
• Self-Healing kommt näher. Kombiniert mit dem Vent Tool und LSO entsteht ein Loop, in dem Subagents Fehler diagnostizieren, der Head-Agent fixt und die Erkenntnis in den Trainings-Loop zurückgeht.

Praktisch: Was wir bei AI First Builders ab heute ändern

Wir bauen bei AI First Builders seit Monaten mit Lovable auf großen Projekten – und genau dort haben wir die Discovery-Zähigkeit gespürt, die das Announcement beschreibt. Drei sofortige Workflow-Änderungen:

• Große Refactorings beginnen mit einem expliziten "Use subagents to..." – damit die Recherche-Phase parallel läuft.
• Code-Reviews vor größeren Releases: ein Subagent prüft Security, einer Performance, einer Konsistenz mit dem Design System.
• Onboarding auf alten Kundenprojekten: Subagent-Recherche statt manueller Walkthrough.

Quellen

• Lovable: Introducing subagents (27.05.2026)
• Recap: Die komplette Lovable-Reise in 6 Thesen
• Vent Tool & LSO: Lovables Self-Improving Loop
• Skills in Lovable