A few months ago, I wrote about what I called the “new” AEM stack: Universal Editor for authoring, Edge Delivery Services for delivery, and AI agents for modernization and development. Read the previous article here.

The architectural direction was already clear:

• SPA Editor had been deprecated.
• Universal Editor was emerging as the forward path for visual editing.
• AEM Edge Delivery Services was becoming the modern delivery layer for new content-led implementations.
• Adobe was beginning to introduce AI agents into the AEM development workflow.

That direction has not changed, but the architecture is expanding.

Edge Functions change the architectural conversation

The biggest addition to the EDS architecture is AEM Edge Functions. Adobe describes them as a public beta capability that allows JavaScript to execute at the CDN layer, closer to the user and without a round trip to the origin.

Documented use cases include:

• Personalization based on geolocation, device type, or user attributes
• Middleware between the CDN and origin systems
• Aggregation and transformation of third-party API responses
• Server-side HTML composition at the edge
• Credential-protected calls to backend services

Edge Functions can be used with both Edge Delivery Services and Java-stack AEM as a Cloud Service projects for AEM Sites customers. They introduce a new option for dynamic behavior while preserving the core strengths of EDS: CDN-first delivery, Git-based development, block-based pages, fewer moving parts, and a lightweight frontend model.

They also provide an execution layer for focused request-time logic that does not need to run in AEM Publish or client-side JavaScript. Product data, pricing, availability, segmentation, API orchestration, and backend composition can quickly move a project beyond a static content model. Edge Functions are not intended to solve all of those problems, but they give architects another place to assign selected responsibilities.

Consider a product detail page. The core content can be authored in AEM and delivered through EDS, while product data comes from a backend platform. Pricing or availability can be resolved closer to the user, and the final response can be composed before it reaches the browser. This can improve performance, reduce client-side orchestration, and support SEO and generative engine optimization by providing crawlers with composed HTML.

The result is not a traditional application server at the edge. It is a focused execution layer for low-latency, request-level logic that allows EDS to support a broader range of content-led experiences.

Edge Authentication moves another boundary

Edge Authentication is another notable addition. Adobe describes it as a beta capability that restricts access to EDS pages to users authenticated through an identity provider, using an OpenID Connect configuration defined in YAML.

Because it is still in beta, production assumptions should remain cautious. From an architectural perspective, it expands the range of potential EDS use cases beyond anonymous public websites.

Possible use cases include:

• Partner portals
• Internal knowledge hubs
• Authenticated campaign experiences
• Controlled-access customer content
• Read-oriented employee or dealer portals

Highly transactional, state-heavy, or deeply personalized applications will still need suitable application runtimes and backend systems. Yet some authenticated experiences are primarily content-led, read-oriented, and performance-sensitive. Those are the areas where an edge-first model could become increasingly relevant.

Universal Editor remains the authoring foundation

As Edge Functions and Edge Authentication expand the delivery model, Universal Editor remains the authoring foundation. It provides a framework-agnostic, in-context editing experience across different frontend technologies and rendering approaches, while preserving one of AEM’s core strengths: allowing business users to manage experiences without depending on developers for every content change.

Without a strong authoring layer, EDS could become a developer-led delivery architecture that loses part of what has historically made AEM valuable to marketing and content teams.

Recent Universal Editor improvements are incremental but practical. Better undo and redo, ordered lists in inline rich-text editing, drag-and-drop section reordering, and improved properties-panel usability are the everyday capabilities needed for broader enterprise adoption. If Universal Editor is to become the standard authoring surface for new AEM implementations, the authoring and delivery models must mature together.

The AI story is becoming operational

The AI side of AEM is also becoming more concrete. AEM agents were previously discussed mainly as an emerging roadmap direction, but Adobe now documents capabilities including the Brand Experience Agent, Content Advisor Agent, and Governance Agent.

Within the Brand Experience Agent, Adobe describes capabilities for:

• Experience modernization
• Experience production
• Development assistance
• Website and content updates
• Form and communication creation
• Troubleshooting
• Build automation

For technical teams, the larger shift is that AI is moving beyond content generation into development, modernization, troubleshooting, and platform operations.

The Development Agent now supports Cloud Manager questions and pipeline troubleshooting, including Web Tier Config Pipeline issues. Adobe has also introduced a beta AEM Code Assessment and auto-fix IDE agent skill for environments such as Cursor, Claude Code, Visual Studio Code, and IntelliJ.

Documented assessment areas include deprecated APIs, Sling Model modernization, outdated Maven dependencies, missing HTTP timeouts, unbounded queries, schedulers, resource change listeners, replication patterns, and JCR or OSGi event handling.

The AEM stack is therefore changing not only at the authoring and delivery layers, but also in how teams inspect, migrate, build, troubleshoot, and operate the platform. The developer workflow is becoming more agent-assisted, not only more cloud-native.

The Dispatcher MCP server is a small but useful signal

Another interesting development is the local Dispatcher MCP server included with the AEM SDK and packaged with the Dispatcher tools. Adobe describes it as a way for AI tools to validate Dispatcher and Apache HTTPD configuration, trace request handling, and inspect caching behavior against a local Dispatcher instance running in Docker.

This may look like a niche developer feature, but it points to a broader direction. Adobe is creating AI-accessible interfaces around AEM infrastructure and operational tooling, not only around content creation and authoring.

Real-world AEM complexity has never been limited to components and templates. Many difficult issues sit in Dispatcher configuration, caching rules, redirects, headers, pipelines, deprecated APIs, environment differences, and Cloud Manager configuration. Giving AI tools structured access to these areas could make troubleshooting more efficient, especially when they are grounded in a real local runtime rather than general documentation alone.

Hybrid architecture is the realistic enterprise model

FFor most enterprise customers, the answer will not be to move everything to Edge Delivery Services. A hybrid architecture is more realistic.

Some routes may use EDS, some may use Edge Functions, and others will continue to use traditional AEM Sites rendering. Additional responsibilities will remain in commerce platforms, customer portals, API layers, integration platforms, and backend services outside AEM.

Large AEM estates contain different types of experiences: campaign landing pages, content hubs, product pages, logged-in customer areas, support portals, commerce journeys, and transactional applications. They do not all need the same rendering model, runtime, caching strategy, or deployment architecture.

The practical modernization path will often be route by route. Teams can begin where EDS provides a clear advantage:

• High-traffic public pages
• Performance-sensitive content
• Campaign sections
• Regional or brand microsites
• Content-led product pages
• Pages where the existing rendering model is disproportionately expensive
• Areas that can be modernized independently

From there, architects can evaluate where Edge Functions add value through controlled dynamic behavior, lightweight personalization, API aggregation, routing, or server-side composition.

This avoids two extremes: treating traditional AEM as the answer to every requirement and treating EDS as a universal replacement. A stronger architecture gives each layer a clearly defined responsibility.

Caching becomes application architecture

Caching is one of the key design topics in this model. Edge Functions can reduce origin load and improve response times, but only with deliberate cache design.

Edge Functions are not a full application server

Edge Functions expand what can be done within an AEM edge architecture, but they do not turn the CDN into a traditional application server.

Adobe documents constraints around resource consumption, execution time, heap size, artifact size, and the number of backend requests allowed within a single invocation. These limits define the workloads edge execution is designed to handle well.

The edge is suitable for:

• Routing
• Lightweight personalization
• Header manipulation
• API response shaping
• Geolocation-based behavior
• Server-side composition
• Credential-protected backend calls
• Low-latency middleware
• Controlled request enrichment

It is not the right place for:

• Long-running workflows
• Heavy transaction processing
• Complex state management
• Deep business orchestration
• Large numbers of dependent backend calls
• Stateful application sessions
• Processes requiring strong transactional guarantees

The design principle should not be to move business logic to the edge, but to move the right request-time logic to the edge. Deep business logic should remain in systems designed to own it.

A practical responsibility model

The emerging AEM architecture can be summarized as follows

The architecture still requires human judgment. AI can accelerate implementation and troubleshooting, but it does not decide where responsibilities belong.

Summary

A few months ago, I would have summarized the emerging AEM stack as Universal Editor for authoring, Edge Delivery Services for delivery, and AI agents for modernization.

Today, I would refine that view:

• Universal Editor is becoming the authoring layer.
• Edge Delivery Services is becoming the performance-first delivery layer.
• Edge Functions introduce focused dynamic execution at the CDN.
• Edge Authentication begins to open controlled-access use cases.
• AI agents are moving into modernization, development, troubleshooting, and operations.
• Traditional AEM Publish remains relevant for deep runtime use cases.
• Backend systems remain responsible for complex business logic, transactions, and state.

EDS is no longer only the static, fast option. It is becoming part of a broader edge-first AEM architecture for content-led experiences.

The strongest architecture will not move everything to the edge. It will place each responsibility where it fits best: authoring in AEM, performance-first delivery at the edge, focused request-time logic in Edge Functions, deep business logic in backend systems, AI assistance across development and operations, and human architectural judgment across the complete experience.