AEM Edge Delivery Services (EDS) represents a fundamental shift in how Adobe Experience Manager delivers content moving from server-side rendering to a document-based, edge-first architecture. When you layer AI capabilities on top of EDS, you get a stack that is both blazing fast and genuinely intelligent. This guide walks through how developers can wire AI into an EDS project today.
Understanding the EDS Architecture First:
Before adding AI, you need to understand what makes EDS different from classic AEM:
- Content lives in Google Docs or SharePoint – authors write there, not in the AEM Sites editor
- Franklin blocks (now called EDS blocks) – These are the rendering unit plain HTML/CSS/JS, no HTL, no Sling
- Delivery happens at the edge via Fastly CDN – your origin is main <repo><org>.aem.live
- JavaScript runs in the browser or in edge workers – no Java, no OSGi
This matters for AI integration because your extension points are different: you are writing vanilla JS, working with fetch-based APIs, and potentially deploying edge functions rather than OSGi services.
Use Case 1 : AI-Powered Block Generation at the Edge
The Problem
Authors create blocks by writing structured content in Google Docs. Complex blocks, comparison tables, FAQ accordions, product summaries still require hand-crafted markup. AI can generate that markup from natural language.
The Approach
Create a custom block called ai-block that accepts a plain-text prompt from the document and calls an LLM at render time. Note the use of DOMPurify to sanitise AI output before injecting it into the DOM
// blocks/ai-block/ai-block.js
import DOMPurify from 'dompurify';
export default async function decorate(block) {
const prompt = block.querySelector('p')?.textContent?.trim();
if (!prompt) return;
const response = await fetch('/api/ai-generate', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ prompt }),
});
const { html } = await response.json();
// Sanitise AI output before DOM injection to prevent XSS
block.innerHTML = DOMPurify.sanitize(html);
}Your /api/ai-generate endpoint (deployed as an AEM App Builder action) calls the LLM server-side so your API key never reaches the browser:
// api/ai-generate/index.js (App Builder action)
const Anthropic = require('@anthropic-ai/sdk');
async function main(params) {
const client = new Anthropic({ apiKey: params.ANTHROPIC_API_KEY });
const message = await client.messages.create({
model: 'claude-sonnet-4-6',
max_tokens: 1024,
messages: [{
role: 'user',
content: `Generate semantic HTML for the following request.
Return only the HTML, no explanation.\n\n${params.prompt}`,
}],
});
return { html: message.content[0].text };
}Use Case 2 : Automatic Metadata Enrichment via Sidekick Plugin
AEM Sidekick is the browser extension authors use to preview and publish EDS pages. You can build a custom Sidekick plugin that runs an AI pass before publishing automatically generating SEO metadata, Open Graph tags, and structured data.
// tools/sidekick/plugins/ai-seo.js
// Wait for the Sidekick custom element to be available
const sidekick = document.querySelector('helix-sidekick, aem-sidekick');
sidekick.addEventListener('custom:ai-seo', async () => {
const pageText = document.body.innerText.slice(0, 3000);
const res = await fetch('/api/ai-metadata', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ content: pageText }),
});
const { title, description } = await res.json();
// Render result inside your plugin panel UI
document.getElementById('ai-seo-result').innerHTML = `
<p><strong>Title:</strong> ${title}</p>
<p><strong>Description:</strong> ${description}</p>
`;
});Register the plugin in your tools/sidekick/config.json. The plugin loads as an iframe panel inside the Sidekick:
{
"plugins": [{
"id": "ai-seo",
"title": "AI SEO",
"url": "/tools/sidekick/plugins/ai-seo.html",
"isPalette": true,
"paletteRect": "top: 50px; right: 20px; width: 300px;"
}]
}Use Case 3: Edge Worker Personalization
EDS pages are static HTML at the CDN layer. To personalize without sacrificing performance, use a Cloudflare Worker with HTMLRewriter to safely inject AI-generated content
based on request context geo, device, UTM params, or a cookie-based persona.
// cloudflare-worker/personalize.js
class CTARewriter {
constructor(newText) { this.newText = newText; }
element(el) { el.setInnerContent(this.newText); }
}
export default {
async fetch(request, env) {
const origin = await fetch(request);
const country = request.cf?.country ?? 'US';
const persona = request.headers.get('x-persona') ?? 'default';
const aiRes = await fetch(env.AI_API_URL, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
prompt: `Rewrite this CTA for a ${persona} in ${country}: "Get started today"`,
}),
});
const { text } = await aiRes.json();
// HTMLRewriter streams and transforms safely
return new HTMLRewriter()
.on('#hero-cta', new CTARewriter(text))
.transform(origin);
},
};Use Case 4 — Smart Tags via Adobe Sensei
| Smart Tags setup requires the Adobe Developer Console and Smart Content Service API integration as it is not a settings toggle. |
Adobe Sensei’s Smart Content Service automatically tags AEM Assets with relevant metadata. The setup requires integration via the Adobe Developer Console:
- Create a project in the Adobe Developer Console and add the Smart Content Service API
- Generate a service account (JWT) credential and note the API key, client secret, and technical account ID
- In AEM as a Cloud Service, navigate to Tools -> Cloud Services -> Smart Tags and configure the Adobe IMS integration using your Developer Console credentials
- Run Tools -> Assets -> Smart Tags Training with a representative set of tagged assets to calibrate the model to your taxonomy
- Once trained, Smart Tags apply automatically on every new asset upload
| Smart Tags training requires a minimum of 30 tagged assets per tag to achieve reliable auto-tagging. Plan a tagging sprint before enabling this in production. |
Architectural Diagram:
Layer 1 – Authoring Layer
What it is: Where content is created by human authors. No servers, no code deployment just documents.
Components:
- Google Docs / SharePoint – Authors write page content directly here using structured tables to define AEM blocks. This is the core EDS authoring model – no AEM Sites editor involved.
- Sidekick Event API (aem-sidekick v6+) – A browser extension authors install. Your custom AI SEO plugin hooks into it via custom:ai-seo events to run AI checks before publishing.
- AEM Cloud Service – Monitors the connected Google Drive or SharePoint folder. When an author clicks “Publish” in Sidekick, AEM picks up the content and triggers the delivery pipeline.
Key point: Authors never touch a CMS interface. Everything happens in familiar office tools.
Layer 2 – Build & Publish Layer
What it is: Where content and code are processed, compiled, and prepared for delivery. This is the backend infrastructure layer.
Components:
- GitHub Repo – Holds all EDS block code (JavaScript, CSS), the config.json for Sidekick plugins, and market configuration files. When authors publish, the content syncs from Google Docs and is served using the code from this repo.
- Adobe Developer Console – Required setup step for Smart Content Service (Adobe Sensei). You register your project here, generate API credentials, and connect them to AEM Assets for Smart Tags to work.
- App Builder – Adobe’s serverless function platform. This is where your AI API actions live, the server-side code that calls the Claude API. API keys are stored here as environment params, never exposed to the browser.
- Claude API – The LLM that receives prompts from App Builder and returns generated content. Scoped strictly to approved inputs never called directly from the browser.
Key point: The App Builder acts as a secure proxy between your EDS pages and the LLM. API keys never reach the client side.
Layer 3 – Edge & AI Layer
What it is: Where content is cached, personalized, and enriched at the CDN level, closest to the user. This is where performance meets intelligence.
Components:
- Fastly CDN – Serves the static HTML EDS pages from the aem.live origin. Extremely fast because pages are pre-built static files, not server-rendered on every request.
- Cloudflare Worker (HTMLRewriter) – Intercepts every page request before it reaches the browser. Uses Cloudflare’s streaming HTMLRewriter to inject personalized content (e.g. different CTAs per country or persona) without rebuilding the whole page.
- Edge Cache – Stores AI-generated responses (block HTML, metadata, summaries) at the CDN level with a TTL per block type. Prevents repeat LLM calls for the same deterministic content critical for keeping pages fast.
- Adobe Sensei – Runs in the background on AEM Assets. After training on your asset library via the Adobe Developer Console, it automatically applies Smart Tags (category, audience, content type) to every newly uploaded asset.
Key point: Personalization and AI enrichment happen here at the edge so the browser gets a fully tailored response without any additional round trips.
Layer 4 – Browser Layer
What it is: What the end user’s browser receives and renders. Everything visible to the visitor happens here.
Components:
- EDS Page (Browser) – The static HTML page delivered by Fastly. EDS blocks are rendered by calling their decorate() JavaScript functions. This is vanilla JS, no framework, no build step, no hydration overhead.
- AI Block (Lazy) – An EDS block that fetches AI-generated HTML from the Edge Cache after the page’s LCP (Largest Contentful Paint) element has already rendered. Uses DOMPurify.sanitize() before injecting any AI output into the DOM to prevent XSS.
- Personalized CTA – The call-to-action element whose text was already rewritten by the Cloudflare Worker’s HTMLRewriter before the response arrived. The browser simply renders what it receives, no extra JavaScript needed.
Key point: The browser does as little work as possible. Heavy lifting (AI calls, personalization, caching) happened upstream at the edge. The result is a Lighthouse 100-scoring page that is also intelligent.
How the Layers Connect
Author writes in Google Docs
↓
AEM Cloud picks up on publish → GitHub code serves the blocks
↓
Fastly CDN serves static HTML → Cloudflare Worker personalizes it
↓
App Builder calls Claude API → result cached at Edge Cache
↓
Browser renders fast static page + lazy-loads AI block after LCP
Each layer has a clear single responsibility like authoring, building, enriching, rendering, which is why the stack is both maintainable and scalable across hundreds of markets.
5 color-coded flows with solid lines for critical path and dashed lines for async/optional paths
