AEM 2026.10.0: Composite Fragments, Agents, Java 25

The 2026.10.0 release of Adobe Experience Manager as a Cloud Service went out on 29 October 2026. It adds a prerelease Composite data type for Content Fragments, better multilingual video handling in Dynamic Media with OpenAPI capabilities, a set of AI agent features for governance, troubleshooting and migration, and three platform notices that need an owner on your team. The next feature release, 2026.11.0, is planned for 19 November 2026, so the useful work is deciding what to test now and what to leave alone.

Key takeaways

• 2026.10.0 shipped on 29 October 2026. The next feature release, 2026.11.0, is planned for 19 November 2026.
• The Composite data type for Content Fragments is a Sites prerelease. Experiment in a sandbox and expect change.
• Dynamic Media with OpenAPI capabilities now supports multiple captions and multiple audio tracks per video, and can generate captions with AI.
• The AEM Governance Agent, CX Enterprise Coworker and Cloud Migration Agent skill help with triage and investigation. They do not replace human judgement.
• Assign owners for CDN egress IP allowlists, the New Relic to OpenTelemetry transition, and deprecated Java APIs.
• The AEM Cloud Service SDK supports Java 25 for local development, which is worth testing early.

What is in AEM 2026.10.0, and what is actually new for your team?

The release overview groups the work into four themes. First, more flexible content and media: the Composite data type for Content Fragments, multilingual video captions and audio tracks, branded video playback, and a GIF-based countdown timer for Dynamic Media email templates. Second, AI-assisted governance and troubleshooting: the AEM Governance Agent and new capabilities in CX Enterprise Coworker. Third, developer and migration tooling: the Cloud Migration Agent skill and the unified AEM MCP Server. Fourth, platform changes to prepare for.

Not all of that is generally available. The Composite data type sits under Sites prerelease. The notes also point to beta programs for agents, AEM Foundation, Cloud Manager and AEM Assets, and mention early adopter and Limited Availability programs. Adobe's own warning on betas is blunt: they may contain defects, are provided as is, and features and APIs can change without notice.

So the first job is sorting the list into three piles. Things you can use this month. Things you can try in a sandbox. Things you must plan for whether you like them or not. Most teams will find the third pile is the smallest and the most urgent.

How should teams approach the Composite data type for Content Fragments?

Carefully, and in a sandbox. The notes describe a Content Fragment model field type that groups related fields and lets them repeat as a list inside one fragment. The composite content is stored in the fragment itself, so GraphQL and the OpenAPIs return it in a single response without having to resolve references.

Think about a product fragment with a list of specification groups, each holding a label, a value and a unit. Today many teams model that as a separate fragment type and reference it from the parent. That works, but every consumer has to resolve those references, and authors have to create and manage lots of tiny fragments. A repeating group inside the parent could simplify both. The notes do not say what limits apply, how it interacts with variations or translation, or how it behaves in existing queries. Read the Composite Data page in the documentation before you assume anything.

Because it is a prerelease, the practical advice is narrow.

1. Pick one model where the reference pattern hurts, such as a spec table, an FAQ list or a set of store hours.
2. Rebuild it with a composite field in a development environment.
3. Query it through GraphQL and compare the response shape and the author experience with the referenced version.
4. Write down what you liked and what surprised you. Send feedback through the prerelease channel if you have access.

Do not migrate live models. Do not let a front-end team hard-code against a prerelease response shape for a launch. If the feature changes before general availability, a production dependency becomes a rework ticket.

What do multi-caption, multi-audio and AI captions change for video teams?

They change who does the work. The notes say Dynamic Media with OpenAPI capabilities now supports multiple captions and multiple audio tracks for video assets. You associate several language-specific caption and audio tracks with one primary video, and authors manage them from one interface. The stated aim is localised and accessible video for global audiences, including regional accessibility requirements.

For a brand with a single product video running in six markets, the old pattern is often six separate video assets, six sets of metadata and six places to forget an update. One primary video with attached tracks is easier to govern. When the master video changes, you replace one asset and review its tracks, instead of hunting for copies.

The AI-generated captions feature uses artificial intelligence to generate captions automatically for video content. The notes are brief, so use your own judgement on accuracy. Machine captions are a fast first draft. They are a poor final answer for legal disclosures, medical or financial statements, product names and anything with heavy accents or jargon. A sensible workflow is generate, have a native-language reviewer correct, then publish. Accessibility is also a compliance matter in many markets, so do not skip the review just because a caption exists.

The overview also mentions branded video playback and a GIF-based countdown timer for Dynamic Media email templates. The page text available here does not go further on either, so check the documentation for what they require before promising them to a campaign team.

Are the AEM agent features worth switching on?

Some of them, for specific jobs. The release names four agent-related items, and it helps to separate what each is for.

The AEM Governance Agent can help prioritise vulnerability findings. If your security team gets a long list after a scan and struggles to decide what to fix first, that is a real pain point. Use it as a sorting aid. Confirm every conclusion against Adobe's official security bulletins and your own exposure, and never treat an agent's ranking as a patch decision on its own.

CX Enterprise Coworker has new capabilities that let developers inspect workflows and investigate Dispatcher behaviour using natural-language prompts. This suits the situation where a rewrite rule or a cache behaviour is a mystery and the one person who understands it is on leave. It could shorten the first hour of an investigation. It will not remove the need to read the configuration yourself before you change it.

The Cloud Migration Agent skill adds migration patterns and beta validation, and the unified AEM MCP Server now supports Cloud Migration capabilities. If you are still moving from an older AEM deployment, this is relevant. Because validation is described as beta, run it alongside your normal readiness checks, not instead of them.

The notes direct readers to Adobe's pages for access to agents in AEM across production, governance, optimisation, discovery and development. Before enabling anything, ask three questions. What data can the agent see? Who can invoke it? Where are its outputs recorded? If you cannot answer them, you are not ready to turn it on in production.

Which platform notices need an owner this month?

Three, plus the Java 25 SDK support. The overview asks readers to review notices on CDN egress IP allowlists, the transition from built-in New Relic APM to OpenTelemetry, and deprecated Java APIs. The page text here does not give the dates or technical detail, so open each notice in the documentation and copy the specifics into your own tracker.

Here is why each one deserves a name next to it.

• CDN egress IP allowlists. If a partner, payment provider or internal system only accepts traffic from addresses you have allowlisted, a change in egress addresses can break that integration without any change on your side. The people who maintain those allowlists are often not the AEM developers. Find them.
• New Relic APM to OpenTelemetry. If your dashboards, alerts or on-call runbooks assume the built-in New Relic APM, you will need an equivalent on OpenTelemetry. Build and compare before the old path goes away, not after.
• Deprecated Java APIs. Search your code base and any custom packages for the APIs listed in the notice. Deprecation is a warning, not an outage, but a deprecated call in a hot path is a good thing to fix when you are already touching the code.
• Java 25 for the SDK. The notes say the AEM Cloud Service SDK supports Java 25 for local development. Run your build and unit tests locally on it. Do not change runtime or pipeline settings based on that single line. Confirm what Cloud Manager and the Cloud Service runtime require in the documentation.

A short ticket for each, with an owner, a source link and a date, is enough. The failure mode here is not difficulty. It is that nobody was assigned.

How do you test and roll out 2026.10.0 changes safely?

Start from the fact that Cloud Service releases arrive on Adobe's schedule, so your job is to check your own code and content against the new baseline, not to decide when it lands. Then work in this order.

1. Read the release notes with a pen. Sort every item into use now, try in a sandbox, or plan for. Share the sorted list with Sites, Assets, platform and security leads.
2. Run your regression suite on the lower environments. Cover page rendering, Dispatcher caching behaviour, key GraphQL queries and any integrations that depend on source IP addresses.
3. Check observability. If you use the built-in New Relic APM, confirm what you depend on and start a parallel OpenTelemetry setup in a non-production environment.
4. Prototype one Composite model. Keep it away from production content and from any front end that is about to launch.
5. Pilot one localised video. Attach captions and audio tracks, review the AI-generated captions, and have a regional reviewer sign off.
6. Pilot one agent, with a written scope. Choose a low-risk use, such as inspecting a workflow in a development environment.

With 2026.11.0 planned for 19 November 2026, you will have a short gap before the next set of changes. Treat this month as a rolling checklist and not a single event.

How do you measure whether any of this helped?

Pick measures you already collect, so you are not inventing a reporting project. For the Composite pilot, compare the number of fragment types and references in the model before and after, the time an author takes to create a typical entry, and the shape and size of the GraphQL response. For video, track how long a localisation round takes from master video to all markets live, and how many caption corrections reviewers make. A high correction rate on AI captions tells you where your vocabulary needs a glossary.

For the agents, measure outcomes, not usage. Did triage of a vulnerability list take less time, and did your security team agree with the ordering? Did a Dispatcher investigation reach a root cause faster than the last comparable one? If you cannot tell, you do not yet have evidence to roll the feature out wider.

For the platform notices, the measure is binary: each one has an owner, a documented plan and a test result before its deadline. Keep the notes short and dated.

Where does an implementation partner help, and where can you manage alone?

You can do a lot yourself. Reading the notes, tagging items, assigning owners, running local builds on Java 25, and piloting a single captioned video are all within reach of a capable in-house team. So is a sandbox prototype of a Composite field if you already have someone who owns your Content Fragment models.

A partner earns its fee in the areas where the work is cross-cutting or where the downside is large. Examples: redesigning a content model estate that is heavy on references, once the Composite type is generally available; moving an observability setup from built-in New Relic APM to OpenTelemetry across several programs; auditing custom code for deprecated Java APIs at scale; or running a migration where the Cloud Migration Agent skill gives you patterns but you still need someone to own the cut-over plan. If you are looking, the AEM partners directory lists firms, and the ranked AEM partner list can help you shortlist. When you are ready to brief them, the AEM RFP template gives you a structure for scope, environments and success measures.

A fair test of any partner proposal: does it distinguish between prerelease, beta and generally available features? If a proposal builds your production architecture on a prerelease capability without saying so, ask why.

What should you avoid doing after this release?

A few things tend to cost teams time.

• Do not build production dependencies on prerelease or beta features. Adobe says beta features and APIs can change without notice, and the Composite data type is listed as prerelease.
• Do not publish AI-generated captions unreviewed where accuracy matters.
• Do not accept an agent's vulnerability ranking as the final word. Check fixed versions and guidance against Adobe's official security bulletins, then verify the fix in your own environments.
• Do not let the platform notices sit in a shared inbox. An unowned notice is how an integration breaks on a Friday.
• Do not change Java versions in your pipeline because the local SDK supports Java 25. Local development support and runtime requirements are different questions.
• Do not skip the roadmap. The Experience Manager Releases Roadmap on Adobe Experience League lists upcoming feature activations, and it is the right place to check before planning a quarter.

If you want to compare firms that can help with any of this, the find partners page and the comparison tool are the quickest starting points. Otherwise, the simplest plan is the dull one: sort the notes, name the owners, pilot small, and read the documentation before you commit.

Sources

• Adobe Experience League: Current Release Notes for Adobe Experience Manager as a Cloud Service — Release notes for 2026.10.0, released 29 October 2026, with 2026.11.0 planned for 19 November 2026.