UI DESIGN LAB Agent Deep Dive

Last updated: 2026-05-20

2026-05-20 Update

The creation workspace now presents the workflow as a PM-led Agent Team with a merged PM Hub / Overview. The bottom composer is only for input, assets, model choice, and sending; agent progress reports live inside their own canvas workspaces. Designer owns Design System, Content Architect owns site structure and copy, Skill Manager owns Skills, Programmer owns the Preview Code tab, and QA Reviewer owns Prompt QA and preview review status.

Ordinary briefs are now planned through role-specific model calls inside the same backend workflow: PM, Designer, Content, Skill Manager, and QA. This is stronger orchestration than a single planning JSON call, but it is still not a persistent multi-subagent runtime. The planner also blocks internal template phrases from leaking into user-visible Design System, Content, or Full Prompt output, and adds dashboard-specific handling for requests such as ecommerce data dashboards.

2026-05-18 Update

The Agent is no longer a black-box generator. It now exposes Intent Map, Decision Board, Capability Fit, Design System Hub with panels, Prompt Template, and Prompt QA before code generation. Discussion mode pauses at plan confirmation; Auto mode continues only after Prompt QA passes.

Who This Is For

This document explains the UI DESIGN LAB project creation Agent for readers who are new to AI agents and frontend systems. It is not only an API note. It explains what the Agent looks like, what it does behind the scenes, how generation becomes a draft, and why the user must explicitly save before a result appears in My Projects.

In one sentence: the Agent is a visual UI-generation workspace. It accepts text, links, code, pasted images, dropped files, model choice, and Skills; then Website mode turns them into a PM Hub plus Agent workspaces for Skills, Design System, Site Architecture, Prompt QA, Full Prompt, and a tabbed Preview window before the user publishes the result as a saved work.

2026-05-17 update: the fixed left Agent panel remains chat-first, while the right side is a React Flow infinite canvas. Website mode starts with Overview, Skills, Design System, Site Architecture, section-level Content Input, Constraints, Full Prompt, and a large right-side Preview window. Code is now a tab inside Preview: the run switches to Code while code is generating, switches back to Preview when the iframe artifact is ready, and users can toggle afterward. Skill selection moved from the composer into the right-side Skills card. Site Architecture can add selectable common sections, Design System and Full Prompt use section blocks by default, and edges start translucent, animate while generating, then turn solid white when complete.

Mental Model

The Agent behaves like a small production team:

• The PM Hub summarizes the brief, intent, missing information, plan confirmation, and PM reports.
• The unified composer accepts text, links, code, file selection, dropped files, and pasted images.
• Compact Agent workspaces show avatar, status, latest report, and a summary; expanding a workspace opens its scrollable details.
• The Skills workspace combines Agent recommendations with user selection.
• Website mode lays out the PM Hub, Skills, Design System, Site Architecture, Prompt QA, Full Prompt, and Preview before generation starts.
• The intent step decides whether enough information exists and, when needed, asks option-based follow-ups.
• The planning step prepares PM overview, Skills, Design System, Site Architecture, content input, and Prompt QA through role-specific calls.
• The prompt step compiles those planning nodes into the reusable Full Prompt.
• The code step generates single-file HTML or a React/Vite source artifact and shows it inside the Preview window's Code tab.
• The preview step renders the HTML in the same Preview window's iframe tab with scripts allowed but same-origin access disabled.
• The save step publishes the draft into generated_pages; My Projects can then delete the saved work or publish it to Community.

Where It Lives

Important routes:

• /(locale)/create/new: Agent workspace.
• /(locale)/create: saved works.
• /(locale)/create/[id]: saved work analysis.
• /(locale)/create/new?work=<generatedPageId>: reopen a saved work in the Agent.

Website Nodes

1. PM Hub / Overview: user brief summary, intent, missing information, plan confirmation, and PM report.
2. Skills: recommended prompt skills from the library plus user-selected skills.
3. Design System: visual direction, colors, typography, layout, components, motion, and rules.
4. Site Architecture: page modules, navigation, section order, section copy, CTA labels, SEO/alt copy, and responsive structure.
5. Prompt QA: prompt quality score, blockers or warnings, and whether code generation is allowed.
6. Full Prompt: the compiled website-generation prompt used for code generation.
7. Preview Code tab: generated artifact. Ordinary runs show single-file HTML; DeepSeek full-prompt runs can show a React/Vite file pack.
8. Preview tab: iframe rendering of the final htmlCode with sandbox="allow-scripts". React/Vite artifacts are built by the server and inlined back into iframe-compatible HTML.

The frontend and backend both use these nodes as a shared language. The backend sends SSE events, and the frontend turns those events into node states, connector animations, and content updates.

Full-Prompt React/Vite Mode

When a user pastes a complete React/Vite/Tailwind implementation prompt and selects a DeepSeek model, the Agent now uses a real React/Vite artifact path instead of compressing the prompt into a brief.

• The model receives the original full prompt directly. By default the server asks DeepSeek for smaller component files (Hero, ContentSections) and index.css, while the server writes the tiny App.tsx composition shell. This avoids one oversized DeepSeek response while still avoiding a brief.
• The server accepts src/App.tsx, src/index.css, src/data.ts, and src/components/*.tsx.
• The server owns the Vite shell files and uses only fixed whitelisted dependencies.
• vite build runs in a temporary server directory.
• The built CSS and JavaScript are inlined into htmlCode, so the existing iframe Preview, saved-work pages, and Community publishing path keep working.
• Source files, build logs, and QA metadata are stored with the workflow version and saved page.
• Build or QA failure gets one model repair attempt. If it still fails, the Agent shows the real error instead of a fake local page.

This makes full implementation prompts closer to what a frontend engineer would do locally while preserving the current draft/save product model.

Creation Modes

Website mode is the current production workflow. It starts with a translucent-edge Website node framework, then the Agent animates edges as it moves through planning, Full Prompt, and the tabbed Preview window.

PPT and Mobile App modes are visible as future entries but disabled for now. They will eventually own different workflow nodes and card types.

Revision starts after a version already exists. The user enters a change request in the same composer, and the Agent creates a new workflow version while preserving the existing product intent.

End-to-End Flow

Why Draft First Matters

The Agent separates draft output from saved work.

• Drafts live in workflow_run_versions.
• Saved works live in generated_pages.
• A generated preview does not appear in My Projects until the user clicks Save work.
• Saved works can be deleted from My Projects or published to Community as templates records.

This keeps experimentation separate from the user's formal project library.

Key Code Map

• src/app/[locale]/create/new/page.tsx: page entry and initial data loading.
• src/components/project-workflow.tsx: main frontend state machine and UI.
• src/components/project-workflow.tsx: React Flow canvas, website cards, composer, SSE state, saving, and Preview.
• src/app/api/generate/assets/route.ts: asset intake.
• src/app/api/generate/workflow/stream/route.ts: main Agent SSE route.
• src/lib/generation/workflow.ts: orchestration, intent, brief generation, HTML generation.
• src/lib/generation/llm.ts: model provider abstraction.
• src/app/api/generate/workflow/save/route.ts: publishes drafts into saved works.
• src/app/[locale]/account/actions.ts: deletes saved works and publishes saved works into Community templates.
• src/lib/data.ts: reads saved works and restores workflow drafts.
• supabase/migrations/202605140001_workflow_agent_assets.sql: workflow tables, RLS, and private storage.
• supabase/migrations/20260514104547_workflow_explicit_save.sql: links workflow versions to generated pages.

Data Model

Beginner translation:

• workflow_runs: one Agent session.
• workflow_run_versions: draft versions inside that session.
• workflow_run_assets: assets used by the session.
• generated_pages: saved works shown in My Projects.
• generated_page_skills: links saved works to Skills.
• templates: public Community records created when a saved work is published with the stable community-<generatedPageId> slug.

Review Summary

Strengths:

• Clear separation between frontend UI, SSE orchestration, generation logic, asset intake, and saving.
• Draft-first product model keeps experimental generations out of My Projects.
• My Projects now has a first community loop: saved works can become public templates without leaving the account page.
• input_snapshot makes saved works reopenable.
• Ordinary brief planning is split across PM, Designer, Content, Skill Manager, and QA role calls before code generation, which improves reliability and reduces template leakage.
• Owner-only RLS protects private workflow data and assets.
• SSRF protections block local and private-network link fetching.
• Visual nodes and connectors make the Agent easier to understand.

Risks and next steps:

• Planning confirmation is visible but still needs to become a true second-generation gate.
• Frontend and backend duplicate workflow event and artifact types.
• Saving spans multiple database writes and is not yet a single transaction.
• There is no quota ledger for model usage.
• PDF, Word, and images are stored but not deeply parsed or read through vision.
• Auth, SSE generation, save, and draft restore flows need E2E tests.
• Some user-facing status messages can be more localized and beginner-friendly.

Development Roadmap

The next goal is not to make the Agent more chatty. It is to make it a more reliable design production system: it should understand assets, make staged decisions, observe its own output, repair obvious problems, and be measurable in tests, usage, cost, and version history.

Phase 1: Stabilize The Current Flow

1. Share workflow types

Move duplicated node, event, and artifact types into a shared module such as src/lib/workflow/types.ts.

1. Make saving transactional

Move the multi-step save across generated_pages, generated_page_skills, and workflow_run_versions into a Supabase RPC or database function.

1. Finish localization

Localize save success messages, error messages, planning confirmation messages, and asset parsing failures.

1. Add E2E coverage

Use Playwright to cover auth, SSE generation, planning confirmation, saving, and reopening saved work in the Agent.

Phase 2: Make Planning Confirmation Real

Website mode now has planning nodes, but the next version should make the planning stage a true production gate:

1. Generate only Overview, Skills, Design System, Site Architecture, Content Input, and Constraints first.
2. Let the user edit architecture/content nodes or answer missing-information options.
3. Generate the Full Prompt and code only after the planning nodes are confirmed.
4. Store each planning revision as a workflow version.

This turns planning confirmation from a display step into a real production gate.

Phase 3: Add Observation And Self-Repair

The biggest gap compared with mature agents is that the current Agent does not inspect its own rendered output. Add a QA node after Preview:

Start with console errors, blank iframe detection, and obvious text or layout overflow. Later, pass screenshots to a vision-capable model so the Agent can judge whether the result matches the brief and style.

Phase 4: Improve Asset Intelligence

• Parse PDF and Word documents into useful sections, tables, lists, and key passages.
• Use vision models to summarize uploaded images, including subject, layout, color, typography, and reusable UI clues.
• Track which generated decisions came from which asset.
• Cache asset summaries so repeated use is faster and cheaper.

Phase 5: Productize Version History

• Show workflow version history.
• Compare prompt, style, and HTML across versions.
• Let users roll back to a previous draft.
• Let users name important versions, such as "dark option" or "mobile refinement".

Phase 6: Add Usage, Cost, And Operations

• Create a usage ledger with runId, versionId, userId, model, tokens, cost, duration, and status.
• Add quota limits for generations, asset parsing, and vision reads.
• Build admin views for failure rate, latency, model cost, and save conversion.
• Warn users before high-cost actions such as vision, multi-pass repair, or large document parsing.

Phase 7: Govern Skills And Evaluation

• Version Skills and record which version each generation used.
• Add Skill fit and conflict hints.
• Maintain a fixed evaluation set for common briefs such as dashboards, portfolios, mobile apps, and landing pages.
• Run that evaluation set after major orchestration or prompt changes.

Recommended order:

1. Real planning confirmation gate.
2. QA and self-repair loop.
3. Transactional save and shared workflow types.
4. Playwright E2E tests.
5. Vision plus PDF / Word parsing.
6. Version compare, rollback, and named versions.
7. Usage ledger, cost dashboard, and evaluation set.

Plain-English Summary

The UI DESIGN LAB Agent is not just a prompt. It is a recoverable, versioned, visual generation system. It connects user input, reusable Skills, assets, model output, workflow drafts, saved projects, and analysis pages into one loop.