Actionist System Map
First-principles working model · 27 Aug 2026 Task graph
Editable architecture conversation

Understand every moving part before we build the machine.

This map breaks Actionist into separable systems: visual components, taste learning, curated software capabilities, autonomous repo conversion, client discovery, deterministic assembly, host services, editing, verification and continuous learning.

15moving parts mapped
8,515joined UI identities
500prioritized OSS candidates
118builder product surfaces
17target industry models

Why Lovable loses

Not because they build badly. Because they made an architectural commitment — generate the whole application from a prompt — and every structural weakness below follows from it. A company can fix a bug. It cannot fix a commitment without becoming a different company.

Ceiling

They generate. We assemble.

A generated app is bounded by what one model can write inside one context window. An assembled app is bounded by the best software that already exists, plus the quality of the joins. Where proven code exists, proven code wins, and the gap widens every year the open-source estate grows.

They are good at layouts and CRUD and break on multi-step business logic — shipping wrong arithmetic.
Durability

Their apps dissolve. Ours hold shape.

With no architecture underneath, edit 30 can quietly undo edit 5; the app has no structure to defend itself. Our changes are typed intent records bound to semantic anchors, so an edit either survives an upgrade or fails loudly. Silent regression is designed out, not tested out.

The #1 2026 complaint is credit burn on the model's own mistakes — 60 to 150 credits lost to AI-introduced bugs. Users pay to repair the generator.
Compounding

Every build of theirs starts at zero.

Pure generation has no memory: the thousandth app is produced by the same model against the same blank context as the first. We attach adaptation cost, workflow success and incident history to stable reusable units, so each build ranks the shelf for the next one. This is the advantage they cannot copy, because the thing that would learn is the thing they do not keep.

Their self-improvement loop tunes the generator. Ours improves the parts inventory.
Security

Constraining the problem deletes their worst liability.

Their generated apps talk near-directly to Postgres through PostgREST with row-level-security policies written by an LLM — a known data-leak class, with no dev/prod separation and everything publicly addressable. When the platform owns schema and policies, that risk does not get mitigated; it stops existing. Generality is what forces them to let the model write security rules.

ML6's architectural critique of the Lovable Cloud stack.
Taste

House style versus a learned design system.

Pre-build style selection and even generation-time enforcement are table stakes — Lovable already scans every generation and auto-retries on token violations. The open ground is upstream and downstream of that: learning a client's actual preferences through structured comparisons rather than asking them to author a design system, and making an off-token value fail the build rather than trigger a retry.

Generic visual convergence is a reported Lovable outcome; no competitor found fails a build on token violation.
Speed

A lookup is faster than a generation, and already coherent.

Their two-minute first render is a generation, so its quality is a sample from a distribution. Ours is a lookup into pre-baked stock under an already-chosen token pack, which is both faster in the limit and coherent on arrival. We are not trying to out-generate them; we are removing generation from the hot path.

Build and run credits were unified in June 2026, so a live app drains the build pool and users cannot attribute spend.
The honest competitive frame: Lovable is the reference point, not the threat. Manus already ships the full-stack-app-from-one-prompt combination inside a cloud VM, at $100M+ ARR and roughly twelve months ahead architecturally, and free app-building bundled into Airtable and Zapier removes builder-as-premium-anchor entirely. The arguments above hold against generation-first builders as a class. They are the reason to benchmark against Manus rather than to feel comfortable.

The end-to-end loop

The client experiences one conversation. Underneath, several independent systems exchange typed outputs.

01Know clientExisting Actionist context + public business signals
02Discover outcomeConversation becomes a bounded ProductSpec
03Recommend capabilitiesNotion-like notes? Calendar? CRM? Portal?
04Choose experienceArchetype, layout, components and taste profile
05Solve compositionCompatible blocks fitted without model improvisation
06Bind hostData, identity, settings, connectors and runtime
07Normalize designSemantic tokens make independent pieces coherent
08Preview and editClient changes wording, layout, modules and behavior
09Verify and learnShip, observe, rerank assets and improve recipes
Composition is not code generation. The planner selects compatible capabilities and bindings; deterministic tooling installs and joins them; AI writes only the remaining semantic adaptation and glue.

The moving parts

Select a part to inspect what it owns, what research already tells us, what remains unresolved, and what a dedicated agent lane would work on. Notes are stored only in this browser.

Words that must stay distinct

Most architecture confusion came from using “block,” “repo,” “component” and “template” interchangeably.

Repository

A source container. It may contain one product, many capabilities, patterns, infrastructure and assumptions.

UI component

A visual/interaction primitive such as a sidebar, hero, footer, table, card, picker or form state.

Capability block

A bounded outcome-bearing function with declared inputs, outputs, state expectations and host requirements.

Packaging profile

How a capability is delivered: service, module, transplant, package, adapter, generated pattern or custom delta.

Archetype

An app-level workflow skeleton such as case management, client portal, CRM, scheduling or finance operations.

Assembly plan

The exact compatible capabilities, bindings, components, routes, data resources and glue required for one app.

Current decisions and live bets

DECIDED

Components ≠ taste

The gallery supplies visual pieces and inspiration. The preference learner discovers the client's design DNA.

DECIDED

Repos ≠ blocks

A repository must be understood and assigned a reuse shape before it enters the reusable shelf.

DECIDED

Postgres ≠ universal interface

Use typed data capabilities; keep Postgres as the default for new transactional state we own.

DECIDED

Solver before model

Compatibility, dependency and authority elimination should be deterministic before AI chooses alternatives.

LIVE BET

Hand-curated top 100

A deliberately chosen first shelf may teach us more than another million metadata records.

LIVE BET

Case/portal pilot

Demand appears stronger and reusable supply thinner than for generic dashboards, making it a better test.