Getting started
How it works
Four steps, and one rulebook that makes the third one possible.
The four steps
| Step | What happens | Where |
|---|---|---|
| Describe | You say what the page is for in plain sentences. | Agent panel, or any MCP client |
| Build | The agent writes HTML, CSS and JavaScript against the Webflow rulebook. | HTFlow |
| Convert | That code becomes native Webflow elements with their own classes. | HTFlow, on export |
| Finish | You import, refine styling, and componentise what repeats. | Webflow Designer |
Why the agent writes code
A visual builder stores a page as a structured representation, not as markup. Generating that representation directly means the model is producing a platform-specific data shape at the same time as it is making design decisions — more context to hold, more tokens per element, and more pressure toward layouts it is confident will import.
Plain HTML and CSS is the format models have seen most. Letting the agent work there, and moving the platform-specific problem to a conversion step that runs afterwards, is the whole idea.
What keeps it convertible
Ordinary code is not automatically Webflow-compatible. The gap is closed by a rulebook the agent is held to: BEM class names, Webflow's own three breakpoints, semantic elements that map onto Webflow's, and no frameworks or external dependencies at all.
Those rules are not advice. Section writes are machine-checked, and a violation rejects the write with HTFLOW_WEBFLOW_RULES_VIOLATED — the section is not saved.
Sections are the unit of work
A Flow site is pages, and a page is an ordered list of sections. Each section is a self-contained fragment: one root <section> carrying a BEM block class, its own CSS, and its own JavaScript.
That granularity is what lets the agent edit one part of a page without rewriting the rest, and what the audit checks run against.