From an AI page preview to an editable AEM component

The recommendation looked right in the preview. It sat between two sections of the page, exactly where someone had chosen to put it. The challenge came when we had to save it: which AEM container owned that gap, and where should the new component go among its children?

We were working with a company building AI for enterprise customer experience. Its platform could take a page URL, inspect the rendered HTML, and show a proposed addition in its own UI. The requirement was to let a user confirm that addition and then find it on the same page in AEM Author, ready for an editor to review.

We first worked backwards from the visible page. If the preview could place the recommendation after a DOM element, perhaps the integration could use that element's selector when saving. But the browser sees HTML; AEM saves content as components beneath editable containers. A selector could identify the right visual location and still tell us nothing reliable about which AEM node to create or how to order it. It could also shift after an author edited the page.

Let AEM describe its insertion points

We made AEM the source of valid locations. For a given page URL, an Author endpoint resolves the corresponding AEM page and builds a slot manifest from its current component tree. Each slot is a gap before, between, or after children of an editable container. It carries an opaque slot ID, the container, the neighboring components, and a manifest version.

The platform uses the same URL to get the page HTML and its slots. That relationship matters. It keeps the AI preview tied to the page whose content will actually be edited, including when a public URL maps to an internal AEM path. The platform chooses a slot ID; it does not send AEM an arbitrary repository path to write into.

The first version of this idea had an obvious weak point: AEM resource paths alone do not tell browser JavaScript where to draw a preview. We extended discovery to render the page on Author, trace rendered elements back to their AEM resources, and return selectors for the actual container and neighboring wrappers. The preview can then show the recommendation at a location AEM knows how to save. If those anchors cannot be matched uniquely, we leave that slot out instead of guessing.

The gaps we nearly missed

Testing real pages changed our definition of a slot. Some visible sections contained nested editable containers. Looking only at the page's outer container missed the gaps between their children, so discovery had to walk the component tree and render those inner containers too. We also sorted the manifest in page order, so a user choosing from the slot list would see locations in the same sequence as the preview.

Other apparent gaps were misleading. A component that rendered no visible content could sit between two AEM siblings, producing two repository gaps that appeared as one location in the browser. We collapsed those duplicates. We also found components whose heading and text were rendered by a fixed template. Saving a new child between those fields would not make it appear, because the template rendered only named children. To support insertion there, that region would first need to become an editable container. A JavaScript generated product grid had a different limit: its cards were not AEM child components at all.

That was the useful boundary for the integration. It could offer gaps where AEM could both save and render a new component, including nested containers. It could not promise insertion at every point the browser could display HTML.

Confirming the choice on Author

When the user confirms a preview, the platform sends the page URL, selected slot ID, manifest version, a new request ID, and one HTML field containing the recommendation's markup, styles, and script. The Author endpoint resolves the page again and checks that the selected gap still exists. If an editor has changed the component structure, it returns stale_manifest; the platform must refresh the slots and let the user confirm the location again.

On a valid request, AEM creates one HTML component in the selected container and orders it before the slot's next component. It returns an Author link for editorial review. Repeating the same request ID returns the existing component instead of creating a duplicate, which matters when a network response is lost after AEM has saved the first request.

We initially isolated the generated content in an iframe. During testing, that prevented it from inheriting the page's typography and made taller content awkward. We changed the component to render inline so the recommendation could use the surrounding page styles and grow with its content. That decision also means its JavaScript shares the page context. The convention was for generated code to control its own component, but the browser does not enforce that boundary. The Author API therefore belongs behind restricted credentials and page write permissions, with the normal editorial and publication workflow after insertion.

What the tests showed

We exercised the revised manifest across six AEM page types. In the final local check, all 48 available slots placed the sample recommendation in the preview, and one recommendation was saved and rendered on each page through the Author API. We removed those test components afterward. The connector also had automated coverage for rendered selectors, nested containers, insertion order, and request handling.

That gave us a working handoff: a visual choice in the AI platform became an editable component at the corresponding AEM gap. Each adopting site needs its URL mappings, component policies, templates, permissions, and rendered selectors checked against its own pages.

The result depended on a precise handoff. AEM named each editable gap and supplied anchors for its rendered position. The platform selected one, and Author checked it again before saving. That is what turned a location in a preview into content an AEM editor could review.