> ## Documentation Index
> Fetch the complete documentation index at: https://docs.frontic.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Building an experience
Everything about an experience happens on one screen: chat on the left, canvas on the right. This page covers what the canvas can do, how work moves through stages, and the settings that shape what the design agent builds.
## Waking the workspace
An experience opens **static-first**. You land on the latest saved version, rendered from storage with no sandbox running — fast, and cheap enough that browsing your experiences costs nothing.
Click **Start editing** to open a live session. Frontic wakes the workspace, connects the design agent, and the canvas switches to the live build. From then on, every change the agent makes appears as it happens.
Workspaces don't stay up forever. Leave an experience alone long enough and its workspace goes to sleep; the card on the Designer overview shows the state.
| State | What it means |
| ------------------------------- | ----------------------------------------------------------------------------------- |
| **Ready** | Running and serving the live canvas |
| **Sleeping** | Idle — start editing to wake it |
| **Starting** / **Provisioning** | Coming up; the chat shows the two steps (reserving the workspace, waking the agent) |
| **Archived** | Moved to cold storage; reopening restores it, which takes a little longer |
| **Error** | Provisioning failed — the chat offers a retry |
Sleeping never costs you work. The workspace keeps everything the agent authored through both sleep and archive, and saved versions live outside it entirely — so waking one back up brings the experience back exactly as you left it.
## The canvas
The canvas renders your real storefront with the experience mounted in place of the container it replaces. The toolbar above it controls what you're looking at.
### Viewport and zoom
Switch between **desktop** and **mobile**, and toggle between auto-zoom (fit the frame) and actual size. The agent checks its own work at phone, tablet, and desktop widths before calling anything done — this is how you check it yourself.
### Staying on the experience
The canvas is a real browsing session, so clicking a link in your shop's header navigates away from the experience. The **track** toggle governs what happens next:
* **Pinned** — the canvas snaps back to the experience whenever you drift off it
* **Browsing freely** — you can click through the shop; the toolbar shows where you are and offers a one-click way back
When the experience replaces existing shop content, **Show original** swaps the experience out for the markup underneath, so you can compare the two directly.
### Selecting elements
Turn on **Select elements** and click parts of the canvas to hand them to the agent as context. Selected elements show up in the chat input, so "make this tighter on mobile" refers to something specific instead of something described.
You can also attach a **comment** to a selection — a short note pinned to that element. Comments stay visible while you're selecting and can be toggled on and off from the toolbar.
Selection works against the **live build** only. Pick a saved version in the version picker and select mode switches off — a pinned version renders different markup than the one the agent is holding.
### Build status
A status pill next to the version picker reports the current build: the build number and how long ago it landed, or the failure message when a build is red. The canvas keeps showing the last good render while a build is broken, so a failure never leaves you staring at a blank frame — but it's worth checking the pill before you publish.
## Where the experience lives
Two settings decide where an experience renders. Open them from the settings button at the left of the toolbar.
The page on your shop the canvas loads. Defaults to your project's
first domain; set it to the actual campaign URL so you're building
against the right page.
The container on that page the experience takes over. Empty means
the page's main content area.
When you save a preview URL, Frontic checks it first and tells you what it found — reachable, redirecting somewhere else, or blocked. A redirect gets a one-click fix that stores the final URL, so the canvas loads directly instead of bouncing.
To set the slot without knowing CSS selectors, use **Pick the slot in the preview**: the canvas switches into picking mode and you click the container you want. The toolbar warns you when the configured container isn't on the page (the experience falls back to mounting on the page body) or when the container holds no content of its own — a sign the experience isn't actually replacing anything.
Experiences created from Shopware come with both settings filled in — the CMS slot is the container, and the preview URL points at the layout's storefront route. See [Frontic Experiences in Shopware](/connectors/shopware#frontic-experiences-in-shopware).
## Working with the agent
The chat is a normal conversation, with a few structured moments.
* **Questions** — when the agent needs a decision only you can make, it asks as a structured choice rather than a wall of text.
* **Plans** — for larger work the agent writes a plan and waits. **Approve** to let it build, or **Request changes** to send it back.
* **Approvals** — a few actions pause for a yes rather than proceeding on their own. You get **Allow** or **Deny**; most of a session runs without ever hitting one.
* **Interrupting** — **Stop** halts the agent mid-run. Use it freely; steering by interruption is the intended way to work.
### Adding images
Click **Add Images** in the chat input to browse your shop's media library, search it, and attach one or more images to a message. The agent uses them directly rather than sourcing stock imagery.
The media browser reads from the shop connected to the project. Without a connected shop, attach images the agent can reach, or let it work with what's in the catalog.
## Stages
Every experience carries a **stage** — where it sits in your team's workflow, independent of whether its workspace is running and independent of whether it's published. It's a label you and your team maintain, not something the system derives — an experience can sit in **Complete** with a sleeping workspace and a published version, and all three are saying different things.
| Stage | Meaning |
| ------------------ | ------------------------------ |
| **Draft** | Created, not really started |
| **Working** | Actively being built |
| **Needs input** | Waiting on a decision from you |
| **Needs approval** | Waiting on a sign-off |
| **In review** | Handed over for review |
| **Complete** | Done |
| **Archived** | Parked |
**Archived** means two different things depending on where you see it. As a *stage* it means you parked the work. As a *workspace state* it means the sandbox moved to cold storage. Neither implies the other.
Move the stage from the badge on the experience. Not every move is allowed — **Working** is the hub, so most stages route back through it, and **Archived** is reachable from anywhere but only reactivates to **Working**. Only the experience's owner can move the stage.
One transition happens on its own: send a message or answer a plan while the experience sits in **Draft**, **Needs input**, or **Needs approval**, and it advances to **Working**. Everything else is a deliberate move you make.
## Ownership and read-only viewing
Each experience has one **owner** — the person whose workspace runs the live build. Everyone else on the team opens it read-only.
As a viewer you still get the full canvas: the latest saved version, every earlier version in the picker, and the share link. What you don't get is the chat — two people can't drive one agent.
When the owner's workspace is running, viewers can click **Switch to live preview & follow edits** and watch the build happen in real time, then drop back to the saved version. When the owner's workspace is offline, the toolbar says so.
## Designer settings
**Designer → Settings** holds two project-level documents that shape every experience in the project. They're the Designer's counterparts to [Studio's Prompt and Project Rules](/studio/settings) — same idea, separate documents, so the two surfaces can diverge.
How the Designer builds for this shop — visual direction, campaign
voice, and what it must never do. Appended to the Designer's
system prompt in every session.
What the Designer should know about the project — business context,
assortment, terminology, and the rules that apply to every
experience. Synced into the workspace on every boot.
Each has an enable toggle, so you can switch one off without deleting it. Both start empty; [Initialize](/context-base/initialize) writes the first draft of both from your storefront, and you edit from there.
These are **project-scoped, not per-user** — everyone building experiences in the project gets the same prompt and the same rules.
Rules that should apply everywhere an agent works — the styleguide, tone of voice, accessibility baselines — belong in [Context Base rules](/context-base/rules), not here. Those reach the Designer, Studio, and your IDE agents at once. Reserve Designer Project Rules for things that only make sense while designing an experience.
## Related
Saving versions, going live, rollback, and sharing.
The brand tokens every experience is built from.
Guardrails shared across every build surface.
What experiences are and how to create one.