Skip to content
Quilium Docs
Back to site
How-to guides

Let AI generate your content

Give an agent one page that shows every block your site already has, and it composes new pages out of them instead of inventing a structure.

An agent asked to "add a page about our workshops" produces something plausible and off-brand. The same agent, shown a page where every block of the site appears in context, produces something you can publish. The difference is the material you hand over, not the prompt.

The material is a content kit: a real page, on the real site, that uses every reusable block at least once. Not a document about the blocks — the blocks themselves, rendered, with real content in them.

Live example: Cairn. Cairn carries a /kit page — active, hidden from the navigation, robots: noindex, nofollow — holding 14 blocks across 10 content-types. Agents read it before composing anything new.
This guide is about composing with the blocks that exist. Letting an agent write raw HTML into a page is a different and considerably harder problem — it needs a design system the agent can be held to, and a template that constrains what comes back. It is not covered here.

1. Build the content kit page

Three properties make it work, and each one is doing a job:

  • Active, so it renders. The agent reads a real composition through the CMS, not a description of one. A page left inactive is a page it cannot see.
  • Hidden from the navigation, and noindex, nofollow. It exists for the people and agents building the site, not for visitors. On Cairn it also carries an explicit meta description saying so — the next person to open the CMS should not have to guess what the page is for.
  • Never deleted, never put back in the menu. It is infrastructure. Treat it the way you treat a .env.example.

One block per variant, not per content-type

This is the part that is easy to get wrong, and it is visible in Cairn's numbers: 14 blocks for 10 content-types. The surplus is deliberate.

mediaText appears four times — once for each value of its layout field: image right, image left, image full-width, text only. collectionRef appears twice — once filtered by difficulty, once with explicitly chosen items, because those are two different things an editor can do with the same block.

A kit that shows each content-type once teaches an agent that the block exists. A kit that shows each variant teaches it what the block can do. Only the second one stops it from reaching for something else when the layout it wants is already available.

What belongs in it

Everything reusable: the hero, rich text with each of its styles, media-and-text in every layout, a feature grid, a gallery, a quote, an FAQ, a collection reference in each of its modes, a call to action, a form. On Cairn that is exactly the list — and the four content-types that arrived with the kit (richText, gallery, faq, collectionRef) are a fair sign of what building one reveals: gaps you did not know you had.

Put real content in the blocks. Lorem ipsum tells an agent about structure and nothing about register, and register is most of what makes generated copy feel foreign.

2. Point the agent at it, once and for all

A kit nobody reads is a page that rots. The instruction to read it belongs in the site's AI custom instructions, not in each person's prompt — that way it applies to the integrated assistant, to an agent over MCP, and to whoever joins the project next month.

Something as short as this does the work:

Before composing or modifying any page, read the /kit page and reuse its blocks. Do not invent a structure, and do not add a content-type without asking.

See Use the integrated AI agent for where those instructions live.

3. Write the request

Everything the agent needs, named:

Add a "Workshops" page.
Read the /kit page first and reuse its blocks — do not invent a structure,
and do not create a content-type.
Content comes from workshops-brief.md. Keep the page out of the menu for now.
Show me the block plan before writing anything.

The rest of the technique is in Prompting well for Quilium.

"Show me the block plan before writing anything" is the line that earns its place. A block plan is three lines of text and takes a second to correct; a written page is fourteen MCP calls and a review.

4. Review what came out

Generated content deserves the same check as generated code, and the fastest checks are structural:

  • Does it use blocks from the kit? A page that invented its own shape is the failure this whole technique exists to prevent.
  • Did it create a content-type? That is an architecture decision, and it is yours. See Content-type schema.
  • Are the images real media, or placeholders? An agent cannot invent an image; it can very easily leave the field empty and move on.
  • Does every interface string go through the dictionary? Hardcoded copy in a template is invisible until someone adds a second language.
  • Does the page render in the other locale? On a bilingual site, an untranslated page is a page half-built — see Run a multilingual site.
Composing a page is not publishing it. A page an agent composed is a draft until a human publishes it, and that stays true no matter how good the result looks. See Publish and go live.

Related


Last updated September 6, 2026.