Skip to main content
A storefront agent can build your store using a plain-language prompt. The result is always a draft that goes live only after you publish it. On the agent canvas the step appears as Storefront Agent. You can use it to create or update store pages, write blog posts, and much more.

Example use cases

  • Daily best-sellers guide: a schedule trigger, insights ranks products, AI reasoning writes the article, the builder rewrites the page, approval gates the publish.
  • Launch page on publish: a product-published event trigger, AI reasoning drafts the copy, the builder adds the page as a draft for review.
  • Seasonal refresh: a scheduled rewrite of a landing section with current catalog highlights.

Configuration

configuration
object

Writing the prompt

Describe the change the way a store owner would. Name the page by its URL and pass the content in from upstream steps. The builder owns files, components, and styling.
  • Name the target page by URL: “Update the guide page at /guides/best-sellers, replacing what is there now.”
  • For recurring agents, say “replacing what is there now”. The page itself is the state between runs.
  • Pass content in from upstream insights and ai_reasoning steps. The builder renders content; it does not research it.
  • For SEO or editorial pages, end the prompt with /colossal-content-pages to load the content-page craft skill.

Output

output
object
Subsequent steps reference these as {{steps.<step_id>.summary}}, {{steps.<step_id>.files_changed}}, and {{steps.<step_id>.preview_url}}.

Review and publish

A typical flow is to run storefront agnet, approval node and then publish node. This way you will be able to check the results before publish them. The publish leg is optional. Without it, the draft waits in the storefront editor and you publish from there.

Constraints

  • One builder runs at a time per store. A step that arrives while another build or chat edit is running waits in a queue.
  • Builder steps cannot run inside map or parallel steps.
  • Builder steps are not allowed in workflows that return a synchronous response.
  • The build is verified before the draft is saved. A failed build fails the step and nothing changes.

Next steps