How a Chat Becomes an App

This document explains how a single sentence like "Show me equipment uptime as cards" becomes a deployed screen. Understanding the internals determines why the first response takes tens of seconds, why the preview pauses briefly, and where to look when something goes wrong.

  당신 ──① 말한다──▶ 에이전트 ──② 고친다──▶ 프로젝트(진짜 리액트 코드)
                         │                        │
                         │                   ③ 세션 컨테이너가 띄운다
                         │                        └──▶ 프리뷰 (고치는 즉시 반영)
                         └──④ 스스로 검사한다 (타입 검사 + 화면 보기)

                    ⑤ 배포 ──▶ 버전 보관 ──▶ /container/… (동료가 본다)

One Project = One React Project

What the Studio creates is not screen configuration data, but real source code. When you create a project, a React project is copied into the server, and every conversation afterward is essentially modifying those files.

This is where it diverges from no-code tools.

	Screen Configuration Tools	Studio
What is created	Configuration data	React source code
When you request something the tool can't do	You're blocked	It usually works, because it writes code
Conversation history	Separate	Automatically committed each turn—reversible

Why "Undo" Works

The agent automatically commits after each turn. This lets you revert any unwanted change to the previous state, and leaves a record of what changed and when. If you want to review and accept changes, turn on Review Mode — Developing Apps with the Builder

① You Speak—There Are Two Modes

Same chat window, different functions.

Mode	What It Does	Does It Modify the App?
Query	Reads platform data and answers with tables/charts	No (read-only)
Builder	Modifies project code to create screens	Yes

"How many alarms on line 3 yesterday?" is a Query; "Make that into a screen" is where the Builder starts. → Querying Data via Chat · Creating Apps from Home

② It Modifies—The Agent's Tools Are Limited

The agent doesn't do anything it wants. It uses only the defined tools.

Tool	What It Does	The Guardrails
File read/write/list	Modifies project source	Cannot leave that project's folder
Command execution	Package installation and builds	Runs only inside the session container (not a server shell)
Platform query	Reads equipment, tags, and alarms	Only items in the read-only list

🔴 The agent has no server shell. Commands run inside that project's container, and file tools cannot reach outside that project's folder. Even if an app is built incorrectly, other projects and the server are safe.

③ Preview—A Container Starts for Each Project

Opening a project starts a dedicated container for that project, and a development server runs inside it. The preview screen simply displays that dev server, so changes are reflected the moment the agent modifies files.

	Default Value	Why
Container memory	2 GB	1 GB causes builds of apps with 3D widgets to die from out-of-memory (measured)
Idle stop	30 minutes	Prevents unused projects from holding memory indefinitely

Idle Stop Is Not "Deletion"

If a project is unused for 30 minutes, the container is stopped, but the project files and conversation history remain. Reopening it starts the container again—that's why projects you haven't opened in a while have a slow first screen.

How many you can run concurrently is essentially your server memory requirement → Installation Requirements

④ It Self-Checks—Hence the Slow First Response

The agent doesn't just modify files and finish.

1. It runs type checking. If it fails, the agent reads the errors and fixes them again.
2. Then it actually renders the screen. It looks at the rendered output and catches misalignments.

This round trip can happen up to 24 times per request. This is the answer to "why is it so slow," and simultaneously why you get a working screen each time.

For Large Screens, Request an "Outline" First

For a large screen, don't ask it to build it directly—ask for an outline first, which is faster. See a list of the widgets and data to be placed, fix any issues, then have it build it. This reduces round trips.

⑤ Deployment—Preview and Deployment Are Different

The preview is the development server, and what gets deployed is the built output. What your colleagues see is the deployed version.

	Preview	Deployed Version
Who sees it	The developer	Anyone with the link
When it changes	Immediately when the agent modifies files	Only when you click Deploy
Address	/preview/…	/container/…

Each deployment increments the version (default 10 retained). If a new deployment is faulty, you can roll back to a previous version.

🔴 Private apps can only be opened by the owner, administrators, and those they've shared with. Having the link does not grant access—you must specify who it's shared with. → App Catalog and Sharing

Where to Look When Something Goes Wrong

Symptom	Where to Look First
Chat can't answer	AI provider settings—Configuration
Preview won't load	Session container—close the project and reopen it
Data is empty	Platform connection and API key—Configuration
Only the deployed version shows an old screen	You haven't deployed. Preview differs from deployment

For more details, see Troubleshooting.