How an AI agent can reconcile approved designs with AEM content before a campaign goes live
This workflow gives an AI agent a defined job, a bounded set of records, and a result a person can review. The agent reads the relevant Adobe Experience Manager context and matches it with Figma, applies the rules in the prompt, and keeps the source behind every recommendation. It returns a proposed handoff rather than taking consequential actions on its own.
Can an AI agent reconcile approved designs with AEM content before a campaign goes live?
Yes. Start with the scope, date range, decision rules, and fields that identify the right records. The agent can collect the evidence, compare states or sources, mark conflicts and missing data, and organize the result around the outcome above. A reviewer then checks the matches and judgment calls before approving messages, record updates, bookings, purchases, publishing, or other write actions. The guide below shows the records, boundaries, prompt, and handoff needed for this specific workflow.
How the AI agent gives design and production one shared punch list
Campaign QA often breaks down because reviewers look at the design and the built page in separate passes. The designer comments on Figma frames, the producer checks AEM, and nobody records whether each approved decision made it across. An agent with access to both sources can prepare one discrepancy list before the release review.
Figma supplies the approved frame, copy hierarchy, asset choice, and component state. AEM supplies the page and Content Fragment values that are scheduled for publication. These products are complementary here: one documents intent, while the other contains the publishable implementation.
How the agent matches the sources before comparing them
Provide an explicit map of Figma frames to AEM page paths whenever possible. For a large campaign, include locale and breakpoint in the mapping. Names such as “final hero v2” are not reliable join keys, and the agent should not infer that two similarly named items are the same deliverable.
Ask it to compare fields a reviewer can act on: headline and supporting copy, CTA label and destination, asset or image treatment, required legal text, component order, and visible states for desktop and mobile. Layout comparisons should describe the observed difference rather than claiming pixel-level accuracy unless the available tools support that measurement.
Example starter prompt
Compare the approved Figma frames in [file or section] with the mapped AEM pages in [release or path]. Use the mapping table attached to this task.
Check headline, body copy, CTA label and URL, asset choice, legal text, component order, and the desktop and mobile states shown in the design. Cite both the Figma frame and AEM path for every discrepancy.
Return four sections: launch blockers, content differences, design questions, and unmatched items. Do not update AEM or comment in Figma until I approve the punch list.How the agent reviews disagreements without hiding them
The agent should not decide automatically that Figma is always correct. AEM may contain a newer legal correction or an approved localization change. When the sources disagree, the handoff should show both values, their locations, and any available modification or approval context. A designer or content owner can then choose the source of truth.
Questions this workflow answers
How can an AI agent reconcile approved designs with AEM content before a campaign goes live?
Give an agent the approved design frames, the release manifest, and an explicit map from each frame to its corresponding page, locale, and breakpoint. It can compare the details that usually fall through the gap between design approval and web production: headline wording, CTA destination, image choice, legal line, component order, empty states, and mobile treatment. Each discrepancy should include both source values. “Hero differs” sends a producer back through the whole page; “the approved mobile frame uses Start trial, while the mobile CTA field on /en/pricing says Learn more” gives the team a decision it can make.
The agent should first test the map itself. A missing page, an extra frame, or two frames pointing to one path may reveal a release-planning error before visual QA begins. It should keep those unmatched items out of the comparison set rather than pairing them by a similar filename. Once the mapping is sound, it can produce a punch list grouped by launch impact and owner.
There also needs to be room for legitimate differences. The built page may contain a legal correction approved after design sign-off, or a translator may have adjusted a label to fit the locale. The agent records modification dates, comments, or workflow states when available and labels the conflict for the appropriate content, design, legal, or localization owner. It does not silently declare either system authoritative.
Reviewers can sample the highest-risk items and confirm the agent opened the right frame and AEM field. After approval, producers work from one shared list instead of separate design comments and CMS notes. The final pass reruns only the accepted mappings and records which discrepancies were fixed, waived, or deferred, leaving a clear release record.
Expected handoff
The final punch list should include the Figma frame, AEM page path, locale or breakpoint, field or component, value in each source, severity, and proposed owner. Keep unmatched frames and pages visible. They often reveal a missing deliverable or an outdated release map, which is more useful than a forced comparison.