Evaluate and Approve the Experience Modernization Agent evaluate
This page is for the person who approves the Experience Modernization Agent for a team that builds or migrates Adobe Experience Manager sites on Edge Delivery Services: an architect, technical lead, or platform owner who may never use the agent personally. It explains what changes for your team, the three ways to run a migration, how Adobe’s team works with yours, which systems and data the agent touches, how changes are controlled and traced, and what remains project work.
For what Edge Delivery Services is and how a project fits together, see How Your Site Is Built and Updated. A result on your own pages tells you more than any description, so ask a team member to start with Auto mode or to import a page step by step while you read.
What Changes for Your Team team-impact
Without the agent, a migration to Edge Delivery Services starts with weeks of developer work before anyone can judge the result: listing the source pages, grouping them by layout, mapping their content to blocks, writing block code and styles, and writing import scripts. The agent does that repetitive work with your team, in a hosted environment with nothing to install.
- Your team decides and reviews; the agent produces. People set the scope, the content model, the target design, and the integrations, and they accept the result. The agent writes the code, imports the content, and compares the result with the source.
- More people contribute directly. Designers, content specialists, and marketers who know some HTML and the basics of Git make changes by describing them in plain language. Developers keep control of what reaches production by reviewing those changes as pull requests. See Broader Contribution, Same Production Control.
- Effort grows with layouts, not pages. A correction changes a reusable block or import script rather than one page, so it applies to every page of the same layout. A site of 5,000 pages that share 12 layouts is mostly the work of 12 templates. See How the Agent Migrates at Scale, and to size the work from the first templates, Estimate Before You Commit.
- The result is a standard project. The code is plain HTML, CSS, and JavaScript in your Git repository, following the conventions of the AEM boilerplate. The site doesn’t depend on the agent at run time, and developers can continue in their own editor or with other AI tools.
- Project knowledge stays in the repository. The conventions that your team agrees on live in
AGENTS.mdand related files, which the agent and new team members both follow. See Project Instructions and Memory.
What the Agent Does and What Your Team Does responsibilities
For how the migration lead coordinates contributors, see Lead the Migration. Several people can work on one project, each in their own console workspace; see Work as a Team.
What Remains Project Work project-work
The agent is a development agent: what can be built on Edge Delivery Services can be built with it. A migration copies what the source pages show, though, not the systems behind them. The agent rebuilds the site: its pages, blocks, styles, and the code that calls your services. Approval and publishing workflows, the back-end systems behind integrations, and how your teams work on the new site remain your organization’s work. These needs require a decision from your team before the agent can build them:
For source access, interactive content, and other boundaries of the import, see Limitations.
Figma and Design Systems figma
Figma can be the source of a new design. With the Figma import add-on, the agent reads the selected component or frame through Figma’s API, using a Model Context Protocol (MCP) server, the way a developer reads a design handoff. It writes the design’s variables and styles, such as colors, typography, and spacing, as CSS custom properties in the project’s global styles. These properties are the site’s design tokens. They live in the code, not in a separate token export, so designers and developers review them like any other change. For how designers work from Figma with the agent, see Work from a Figma Design.
What to approve:
- Access: Each person who uses Figma with the agent creates a Figma personal access token with read-only scopes and stores it in the console’s settings. Figma issues and governs this access token, which has nothing to do with design tokens. There is no organization-wide Figma connection, and a personal access token can’t be limited to specific files: it reads every file that its owner can open.
- Seats and rate limits: Figma limits how often a token can read files, based on the token owner’s seat and the plan that owns the file. With a View or Collab seat, a token can read files through Figma’s API only a few times a month, so people who use Figma with the agent need a Dev or Full seat. See Figma’s rate limits.
- Data: For the selected frame or component, the agent sends its structure, a screenshot, its variables, and its text to the AI model. See What the AI Model Processes.
Choose How the Migration Runs approaches
The same agent can run a migration in three ways. They differ in who drives the agent and who answers for the result. All three produce a standard Edge Delivery Services project, with code in a Git repository and content that authors edit, so you can move from one to the next: transfer an Auto mode result to your own site and continue in the console, or continue with the agent yourself after an engagement with Agentic Outcome Engineers.
The Team Behind the Agent adobe-team
When you choose the agent, you also choose the team that builds it and the direction that it takes. How people find information on the web is changing: more of them ask an AI assistant, which answers from what it reads on the brand’s own site. And an agent can change a site’s content, design, and code together, so a change that once needed a project can take hours. The team’s mission is to help you move to Edge Delivery Services, get the most out of Experience Manager, and use agentic development tools to build sites that stay relevant as these shifts continue. Its work with you doesn’t end at the migration, and the agent keeps changing; the release notes list each change.
When changes are cheap, the hard part is deciding what to change, keeping it governed, and giving the agent the right brand, design, and business context. That knowledge sits with your teams and systems. Adobe’s team helps you connect it to the platform:
- Engineers who can run the migration with you. For a complex migration, Adobe’s Agentic Outcome Engineers can operate the agent with your team and hand the site over to it. See Choose How the Migration Runs.
- Current as the product changes. The console’s What’s new notice lists the highlights of each release. To apply a change to your own site, review your architecture, or discuss a need that the agent doesn’t meet yet, ask your Adobe customer success manager or account team for a meeting with subject-matter experts and the product team.
- Your experience shapes the product. The product team exchanges expertise with customers and partners, and works with some of them on new capabilities. What you report feeds into what the team fixes and builds next.
To reach the team from the console, use Request support, or Get help on the Auto mode pages. Your message goes straight to the team that builds the agent, which looks into it and follows up by email. See Request Support and, for what a request shares, Support Requests.
Adobe’s team works the same way with implementation partners, so that with your partner the site keeps improving after the migration.
Systems and Data Flow systems
The agent works in a hosted environment and reaches your systems only through connections that people set up and permissions that they grant.
aemcoder.adobe.io where people work with the agent.aem.page and the live site on aem.live.Security and Data Handling security
The console lets the agent work on your site without giving it the credentials that you configure, and you decide when changes reach your Git repository and your content destination.
Access and Isolation security-access
- You sign in to the console with your Adobe ID. Every request is authenticated with Adobe Identity Management Services (IMS).
- Each user works in a separate backend environment with its own workspace storage, one in each Adobe organization that they sign in with. The console creates the environment when the user first signs in and pauses it when it’s idle.
- The console has no project roles. Anyone with access can ask the agent for any change in their own workspace. Experience Manager and your Git provider continue to enforce their own permissions for any code or content that leaves the workspace.
Credentials security-credentials
- The AI agent does not receive the credentials that you configure in the console. Tokens for GitHub, Cloud Manager Git repositories, Experience Workspace, Figma, and protected source sites are held outside the agent’s environment. A separate component adds each credential only to requests for the service it belongs to. The same applies to the credential used to call the AI model.
- Credentials belong to the user who configures them, not to the project. Each team member connects their own Git account and stores their own Figma token.
- Agent permissions are off until you turn them on. Turning one on lets the agent act with that access, for example to push to your repository, without seeing the credential. By default, a permission uses the user’s own sign-in. To narrow what the agent can reach, enter a token for it instead: a fine-grained personal access token scoped to the repositories it needs, or the token of an Adobe service account.
- Other services that the agent calls while it works, such as a test API, get their credential the same way, from an entry in Protected site authentication for the service’s hostname. See Credentials for Other Services.
- Store credentials only in the console’s settings, never in prompts, chat, source content, or project files: the agent reads these and can send them to the AI model. Make this part of onboarding, because people who are new to coding agents may paste a password or key into the chat to get a task done. Ask everyone who uses the console to read Keep Secrets Out of the Chat first, and tell them what your organization’s policy allows them to share with AI tools.
What the AI Model Processes security-model-data
To perform your request, the agent can send the following to the large language model (LLM) that it uses, currently a Claude model:
- Your prompts and instructions.
- Source page URLs, markup, and content, or exported CMS content.
- Repository code and configuration, such as blocks, styles, and site configuration.
- Design and brand references, such as Figma designs and screenshots.
- Generated content and code under review.
Adobe does not use your conversations or other customer data to train or fine-tune AI models.
Control over Changes security-control
The agent works in your console workspace, where you review its changes and the preview. Work reaches your site in separate steps, and each step has its own control:
- The console’s own checks are safeguards, not approval gates. Optional plan mode lets you approve a plan before the agent starts. The console also stops the agent from uploading, previewing, or publishing unless your current message asks for it or you agree when the agent asks, but it can’t detect every way of making such a request. Neither check stops a person with access from pushing or publishing.
- With a Git permission, the agent can push to any branch that your credentials can write to, including
main. A push tomainchanges the live site’s code. - To require review, enforce it where the change lands. Protect
mainwith branch protection that requires a reviewed pull request, push with Create new PR, and limit who can publish with the site’s publish role. The pull request lists the changed files and the preview URLs of affected pages, so that a developer checks the result before merging. Set these controls up before more people contribute, and turn on agent permissions only when a task needs them. See Broader Contribution, Same Production Control. - Treat source pages and design files as untrusted input. They can contain text that attempts to steer the agent. Review the changes before you push, preview, or publish them.
Content Push Permissions content-push-permissions
When you upload content using your Adobe sign-in, the destination enforces your account’s permissions. For document-based content edited in Experience Workspace, you need write access to the destination content. For Experience Manager authoring, you need permission to write pages and assets at the selected paths on the author instance. Signing in to the console doesn’t grant those rights.
When you turn on the agent’s Adobe credentials permission, its content pushes to the document-based content repository use your account’s access. Asking the agent to upload doesn’t bypass the destination’s permissions. For Experience Manager authoring, upload the content yourself through the console; direct agent uploads aren’t supported.
If a document-based upload uses a configured fallback account because your sign-in is unavailable or authentication fails, the destination enforces that account’s permissions instead. The same applies when you explicitly configure a service account for the agent. Confirm which account is used before relying on your personal permissions to limit changes.
Trace What the Agent Did audit-trail
The console keeps no separate audit log, but the agent’s work doesn’t go unrecorded. What the agent produces reaches your site only through your Git repository or through Experience Manager, and both keep a history:
- Code is the primary record. Your Git history records each change to blocks, styles, and import scripts, and the import scripts define the structure of every imported page.
- Content changes are recorded with the content. Experience Workspace keeps a version history of each document, and the author instance keeps its own page versions.
- The conversation shows what was asked. Download chat saves the conversation as a Markdown file. Download it before you select Clear chat, which removes the messages and can’t be undone. See Chat Panel.
The record is easiest to follow when each request to the agent ends in its own commit, pushed to a working branch rather than to main, and, where pages changed, its own content upload, which the agent offers and a person approves. Ask for this in the project’s AGENTS.md; see Leave a Record of Each Request. Reviewers then read what the agent changed, request by request, in tools that they already use.
Where Your Work Is Stored security-storage
- Code that you push is stored in your Git repository, and content that you upload is stored in Experience Workspace or on your author instance. Their own retention and version history policies apply.
- Work that you haven’t pushed or uploaded exists only in your console workspace, along with the chat history and the transcripts of the agent’s sessions. Clear chat removes the messages from the chat panel but keeps the transcripts. To delete the open project’s work in the console workspace, including the transcripts, use Reset workspace.
For processing locations, data retention, and compliance information, contact your Adobe account team or see the Adobe Trust Center.
Health Data and HIPAA security-hipaa
The Experience Modernization Agent is a developer tool for migrating and building sites. Your site’s visitors never reach it: Edge Delivery Services serves the published site, and visitors’ requests don’t pass through the console or the agent. You can migrate a healthcare site’s pages, designs, and assets without patient data. Never give the agent real end-user data, such as patient records or your users’ credentials, and don’t migrate pages or assets that contain it. Use fictitious data to develop and test patient-specific layouts. Whatever you give the agent can reach the AI model; see What the AI Model Processes.
A staging site, an allowlist, or a source login doesn’t change this restriction. Before importing a protected source, check the pages and assets in scope and restrict the source account to content with no protected health information (PHI). Configure that account through source authentication, not in chat.
For a site that will process PHI under the Health Insurance Portability and Accountability Act (HIPAA), confirm the authoring and delivery setup with your Adobe account team, including the required license, Business Associate Agreement (BAA), and configuration. HIPAA readiness for Adobe Experience Manager as a Cloud Service lists Edge Delivery Services as HIPAA-ready, but the Universal Editor as not HIPAA-ready; it can be added to an Extended Security Program only when no PHI is introduced. A HIPAA-ready delivery service doesn’t extend its PHI coverage to the agent or to an editor that isn’t HIPAA-ready.
Support Requests security-support
A support request goes to the Adobe team that builds the agent. With the topic and description that the sender writes, it shares:
- The sender’s name, email address, and Adobe user and organization IDs.
- The session ID, project name, and preview URL, and the Git host for GitHub Enterprise.
- Any recent prompts that the sender chooses to attach. None is attached by default.
These details let the team find the session’s conversation and logs. Before the sender’s console workspace is set up, a request shares only the name, email address, and organization. On the Auto mode pages, Get help shares only the sender’s name and email address with their message. Ask users not to include passwords, tokens, or personal data in the description. See Request Support.
Next Steps next-steps
Once your team has agreed the scope, approach, and controls, follow Migrate a Production Site. Use Auto mode for a first check on your own pages before committing to that work.