There used to be two separate AI chat surfaces with two separate memories — a small docked helper and a separate full-page assistant. They're now one assistant with one shared memory: start a conversation in one place, continue it in the other, and it remembers everything either way.
The assistant can actually look things up and draft real changes now, not just answer questions. But anything that changes real data — like creating a product — shows you a summary card first. Nothing is saved until you click Confirm.
Building a store with AI isn't one big, unpredictable request. A first pass turns your answers into a clear creative brief; a second, separate pass turns that brief into the actual store. Splitting creative decisions from mechanical execution makes the result more consistent.
Before this, the assistant could only answer questions — it couldn't actually do anything for you. The real upgrade was giving it the ability to look things up and take real action, safely.
When the AI builds a store, it writes the exact same kind of theme code a human developer would — same structure, same limits, same validation. There's no separate, looser set of rules for AI-generated content.
Every plan has a real monthly AI budget. An active paying user is never cut off once they cross it — the system quietly shifts to a more efficient model instead of stopping.
The assistant can look things up right away. But when it's about to change something real — like creating a product — it always drafts the change and asks you to confirm before saving anything.
Merchant impact: A merchant can ask the assistant to draft a new product conversationally and still gets the same review step they'd get editing it by hand — the AI never silently writes to the live catalog.
Developer impact: Every tool is one of three kinds: read (runs immediately), confirm (drafts a change, requires explicit approval), or requires-client (needs the browser to do something, like open a picker). `loop.ts`, `executor.ts`, and `registry.ts` are cleanly separated, so adding a new capability is a new tool file plus one registry line.
Example: `product.create.v1` drafts a new product from the conversation and shows a summary card — name, price, category, vendor, image count, status — that only creates the real product on confirm.
When the assistant creates or edits a product, it goes through the exact same process as editing it by hand in the dashboard — it's not a separate, lookalike shortcut that could behave differently.
Merchant impact: A product the assistant creates behaves identically to one created by hand in the dashboard, because it's the same underlying process, not a lookalike.
Developer impact: Every product tool runs through the same code the actual Products UI uses (`createStoreProduct`/`updateStoreProduct`, `payloadFromForm`) — one code path to maintain and test, not two that could silently diverge.
Example: `product.update.v1` diffs against a product's real current values before drafting a change, so the confirmation card only shows what's actually changing — not a full re-description of the entire product.
When a product needs an image, the assistant opens your real media library — the same picker you'd use in the product editor — so you always choose a real image, instead of the AI guessing or inventing one.
Merchant impact: Product images stay real and correct — no risk of a broken or fabricated image URL landing on a live listing.
Developer impact: Media selection is a `requires-client` tool by design, not a read or confirm tool, since only the browser can actually open that picker.
Example: A merchant says "use our logo for this product," and the assistant opens the real picker instead of guessing a URL from context.
A quick chat about your store name, what you sell, and the look you're going for turns into a genuine creative brief, which then gets built into an actual starter store — not a generic template with your name swapped in.
Merchant impact: A new store gets a real, personalized starting point — not a generic template — and the result lands as a draft theme to review and publish, never live unreviewed.
Developer impact: A Planner call synthesizes onboarding answers into a detailed Design Brief (genuine creative reasoning, on Pro while budget remains, Flash once exhausted). A separate Builder call, always on Flash, executes that already-finalized brief into real theme sections — splitting creative judgment from mechanical code generation, and keeping the most token-heavy call off the expensive model on every run.
Example: A user can close the tab once generation starts and gets emailed when the store is ready; if they stay, they watch it finish live via server-sent events.
AI usage is tracked against a real monthly allowance tied to your plan, refreshing every month — so it's a predictable part of what you're paying for, not a cost that can spiral unexpectedly.
Merchant impact: AI access is a real, gated part of a plan tier, not an unmetered cost center that could spiral unexpectedly.
Developer impact: `StoreAiUsage` tracks one document per user, per calendar month, lazily rolled to a fresh period on read — decoupled from the user's own billing cycle, since a yearly-paid plan still gets a monthly AI allowance. Nothing about usage is shown to the end user today; the Pro→Flash fallback is completely silent.
Example: A dev-only model override lets an internal reviewer force both Planner and Builder stages to the same model for a side-by-side quality comparison — the server independently re-checks it's actually a dev environment before ever honoring it, so a forged override in production is silently ignored.
Every layer feeds the next: AI sits inside this chain rather than bypassing Commerce Engine's data contracts.
`loop.ts` decides what to call next; `executor.ts` runs it after checking permissions; `registry.ts` lists available tools — a new capability area is additive, not a core rewrite.
`AssistantConversation`/`AssistantMessage` replace what used to be two separate models (`DomainHelpChat` and `StoreAssistantConversation`/`StoreAssistantMessage`), served through one `/api/assistant/*` group.
`OnboardingSession` (one per draft theme, not per user) tracks step/answers/chat history/design brief. `synthesizeDesignBrief` (Planner) and the Builder's blueprint-generation call are separate steps; `applyBlueprintToThemeDraft` writes only into a draft `StoreTheme.data`, never the live `Store`.
The generation route validates, gates on AI access, flips state to `generating`, responds immediately, and an unawaited background job does the actual model calls — deliberately built to survive the user closing the tab, which assumes a persistent Node process rather than a serverless/edge runtime that would freeze after the response.
AI Store Builder produces an actual, personalized draft theme from real onboarding answers, grounded in the merchant's own catalog data when they already have products, not invented placeholder products.
Both systems land changes as drafts — a confirmation card for the assistant, a draft theme for Store Builder — never writing directly to a live storefront.
Because the assistant reuses the actual product create/update code path, there's no risk of AI-created products behaving subtly differently from hand-created ones.
AI access ties to a real per-plan monthly budget, so usage doesn't become an unpredictable cost line item.
Collections, menus, discounts, shipping zones, orders, and store settings are all named as natural next capability areas, each following the same read → confirm split every product tool already establishes — additive, no changes to the loop/executor/registry core.
The Builder's output goes through the same Zod-schema-plus-size-cap validation as any other theme write, so there's no separate "AI theme" format to special-case elsewhere in the platform.
`resolvePlannerModel(userId, requestedOverride?)` is the one real entry point every route calls — honoring a dev-only override first, deferring to the real access/budget check otherwise — a clear pattern for any future AI-gated feature to follow.
No retry-with-feedback loop for bad model output, no abandoned-draft cleanup, no "your AI builds" list, and no prompt-injection hardening beyond standard message-role separation are all named directly as open work, not discovered later by a user.
A merchant starting a store answers a few onboarding questions about their niche and creative direction instead of starting from a blank theme.
Outcome: A real, personalized draft theme to review and publish — not a generic template requiring extensive hand-editing first.
An operator wants to add or update a product without navigating the full product editor form.
Outcome: A conversational flow that drafts the change and shows exactly what's changing, with a real Confirm step before anything is saved.
An agency wants a faster way to stand up a client's initial store structure.
Outcome: AI Store Builder's Planner/Builder pipeline as a starting point, still fully editable by hand afterward since the output is ordinary Bit source.
A CTO wants to know whether Prebit's AI is real tool-calling or a chatbot skin.
Outcome: A specific, verifiable answer: real read/confirm/requires-client tool-calling reusing production code paths, plus a real Planner/Builder generation pipeline — with the honest caveat that neither has been run end-to-end against a live OpenRouter key in this environment yet.
Store generation is fire-and-forget by design specifically so a user closing the browser tab doesn't kill the in-progress work — they get emailed when it's ready instead.
The Builder stage — the single most token-heavy call in the feature — always runs on the cheaper Flash model regardless of remaining budget, which is where the deliberate cost-control decision actually lives.
The generation-progress stream polls session state server-side and forwards it as events — safe to never open, safe to disconnect from, since the actual background job in the POST route is unaffected either way.
Nothing in this feature has been run against a real OpenRouter key or a live Mongo/SMTP setup — type-checking and linting catch syntax and type errors, not prompt quality or whether the model reliably returns parseable JSON in practice.
Because the Builder writes real Bit sections under the same schema and validation rules a human author follows, AI-generated pages carry the same semantic markup and metadata capabilities as any other Prebit theme.
When a merchant already has products, the Builder's prompt includes a real, capped catalog summary so generated sections reference actual products rather than fabricated placeholders that would need replacing before launch.
Since AI Store Builder output always lands as a draft, a merchant reviews content quality and accuracy before anything reaches a URL a search engine could index.
A direct, factual read on where each platform is strong, and where Prebit takes a different approach.
Directional and factual. Validate against your own catalog complexity, channel strategy, and budget before deciding.
Plain answers to what merchants, agencies, and developers actually ask.
Start free. No credit card required. Explore the rest of the Prebit platform once you're in.