Document in, AEM page out
“It’s been three months since I last touched AEM. I can never remember where the meta description goes, and last time I forgot the teaser entirely.”
I have heard variations of this more than once. Communications people aren’t full-time AEM authors; they touch the CMS a few times a month, which is long enough between releases to forget where each field lives, which tags belong on a media release, and what the SEO metadata is supposed to look like.
The problem isn’t really speed. It’s that the published pages end up inconsistent: one ships with an empty meta description, another with the wrong taxonomy facet, another without the teaser the author didn’t get to. Multiply that across a year of releases and the site quality drifts, one little gap at a time.
So I built a small PoC to attack that head on.
A quick disclaimer before going further: the idea came from one of our clients, and the implementation is customized for their setup. It works in production-like conditions on their side, but for that same reason I can’t share the source code here. What I can share is the shape of the solution, which is what this post is about.
What if….
…the AEM page model was no longer the author’s problem to remember?
The starting point doesn’t change. Communications teams already prepare a media release as a document (Word, PDF) long before anything touches the CMS. It is reviewed, approved, signed off, and that artefact is the source of truth.
The author is still in charge: they read the result, decide what is good enough to publish, and own the page. They just shouldn’t have to hold the full structure of the CMS in their head to do that. The AI does the filling-in from the document; the author does the validating.
The idea, in one line: Document in, AEM page out.
A user drops the prepared press release into a web tool. An LLM reads it and fills every field of the media-release page — title, description, teaser, body, SEO metadata, publication date, language, and tags. The user reviews, adjusts what needs adjusting, and clicks publish. The page lands in AEM, ready for the usual review and approval flow.
If something still needs tweaking, the tool also lets the user ask in plain language (“shorten the teaser”, “add a location tag”, “rewrite the lead in a more neutral tone”) and the AI applies the change directly to the page.
That’s the whole loop.
Why it actually matters…
Speed is not the interesting part. Consistency is.
Authors don’t need to remember the page model. Every required field is filled from the source document, so no one has to recall that the teaser is a separate field from the description, or that there’s a navigation title at all. SEO metadata and tag facets (division, location, thema) get the same care on every release, instead of being skipped because someone was in a hurry, and the taxonomy stays clean across releases instead of drifting per author.
The tool also flags missing pieces before publish, and double-checks that the published page actually renders before reporting success. Nothing important silently goes blank.
Governance is untouched. Editors still finish in AEM and the existing approval and activation flow does not change. The tool just front-loads the boring, easy-to-forget parts. And with the chat refinement step, an occasional author can adjust a published page in plain language without ever opening AEM.
Get Nicolas Hirrle’s stories in your inbox
Join Medium for free to get updates from this writer.
Time savings come along for the ride, at least in my experience. They’re real, but they’re not the headline.
Under the hood…
For the curious, the moving parts are deliberately small.
- Next.js + TypeScript for the UI and the server routes.
- Vercel AI Gateway as the LLM entry point — one integration, the choice of underlying model abstracted behind a single endpoint.
- Zod for the extraction schema, so the LLM’s output is parsed and validated before any field reaches the UI or AEM.
- AEM Sling POST servlet to create the page, followed by a verification GET on the rendered URL — only a real HTTP 200 counts as success.
The interesting piece is the prompt. The extraction step is not “summarize this document.” It is a tightly scoped instruction that names every field, the exact format expected, and the closed list of allowed tag IDs. A trimmed excerpt:
Extract structured content from this media release. Return ONLY a valid JSON object
with these keys (omit keys you cannot confidently determine, never guess):- title (string, the main headline)
- teaserDescription (string, short teaser for social sharing, 1-2 sentences)
- bodyText (string, the FULL main body as HTML.
* The FIRST paragraph is the LEAD. Wrap it as:
<p><span class="lead-text">DD.MM.YYYY – LEAD TEXT</span></p>
* Subsequent paragraphs are plain <p>…</p>; subheadings are <h5>…</h5>.
* EXCLUDE any contact/boilerplate section at the end.)
- divisionTags (array of tag IDs from the Division list below, 0-3 items)
- language (string, one of: "de", "en", "fr", "it")For tag fields: use ONLY IDs from the lists below. Do NOT invent new IDs.
That level of specificity is what lets the schema on the other side parse the response with confidence — and what keeps the taxonomy clean across hundreds of releases. The LLM picks from a closed vocabulary, not whatever feels right that day.
Not just AEM…
The pattern is CMS-agnostic.
A typed schema describing the content model, an LLM that fills it from a source document, a review step that flags gaps, and a verified write to the CMS — those four pieces work against anything that exposes a content API. Sling POST is just how AEM accepts writes. Swap that adapter, and the same pipeline lands content just as cleanly in Contentful, Strapi, Sitecore, or a homegrown headless CMS.
What’s next…
The PoC is intentionally narrow. Natural next steps: pushing embedded images into the DAM, broadening template coverage beyond media releases, and hardening document ingestion across more source formats.
It’s worth noting that Adobe is moving in the same direction. At Adobe Summit 2026, Adobe unveiled Adobe CX Enterprise, an end-to-end agentic AI system built around the Experience Platform Agent Orchestrator — agents, reusable skills, and MCP endpoints with an intelligence and governance layer on top. On the AEM side specifically, the Experience Production Agent brings this directly into authoring, with a Content Create job that generates new pages from a marketing brief, a template, and a natural-language prompt — which is more or less the same job description as the PoC, just bolted into the platform. At the time of writing, that job is still in Limited Availability and not yet generally released.
What I take away from it is that an LLM plus a well-modeled CMS payload makes every occasional contributor produce the same polished, fully-tagged release as the most seasoned editor. The boring, easy-to-forget parts of content operations turn out to be exactly the parts that benefit most from being automated.
Does your team have an “occasional author” problem like this? How are you handling it today?
