Adobe Commerce Developer Agent, what it is and how to try it

Most Magento 2 teams I know still ship custom PHP modules for work that now belongs outside the monolith: order events to an ERP, a checkout shipping method, a webhook that blocks a bad order. Adobe has been pushing that work onto App Builder for a while. The missing piece was always the boring middle. Scaffold the app. Pick the right event. Wire IMS. Deploy it.

The Commerce Developer Agent is Adobe's attempt to fill that gap. People keep asking me if it is a new Magento CLI or just Copilot with extra docs. Neither. There are two related products, and mixing them up is how you waste an afternoon.

This post is what I pulled from Adobe's developer docs in September 2026: who can use it, how the hosted agent actually works, how to install the Cursor pack, and where Adobe still says "do not trust this yet."

Two products, not one

Adobe documents both under the same "developer-agent" section, which does not help.

The hosted Commerce Developer Agent lives at experience.adobe.com/commerce-migration-assessment/developer-agent. You sign in with IMS, describe a feature or open a Migration Assessment, and it walks you through Blueprint, Develop, Integrations, and Deployments. Adobe's own overview video sells it as "plain English to a working store feature." I treat that line as marketing.

The IDE pack is the one I care about more day to day. After aio commerce extensibility tools-setup (or the bigger app-setup command), you get Commerce skills plus MCP servers inside Cursor, Claude Code, GitHub Copilot, Windsurf, Codex, and a long list of others. Same family. Different surface.

Adobe first listed the IDE pack in the March 2026 Cloud Service release notes as "App Builder AI coding tools." The hosted agent and the video series showed up in the docs around late August 2026.

What you need before you start

The hosted agent is not public-internet free. Adobe lists:

• An Adobe Commerce entitlement (customers only)
• Adobe Developer App Builder access
• An active IMS identity tied to the org

Capacity is currently included at no extra charge. There is a Usage tab that shows how much of the org's allocation you have burned. If you hit the ceiling, your Adobe rep or an Admin Console admin has to raise it. Adobe says expanded usage details and pricing come later.

You can start two ways:

• Net-new: open the agent home screen, sign in, click New Project, pick App Builder or Edge Delivery.
• From a Migration Assessment: open a finished assessment, go to Module Reports, click Open in Developer Agent. Context is pre-loaded, which is the whole point.

I would not start with a payment gateway. Adobe's own net-new table says custom payment work needs extra security review, and API Mesh generation is not available at all.

How the hosted agent actually works

The mental model is the part I keep repeating to people. Planning and execution are separate.

You describe the job in English. The agent writes a Blueprint: architecture, assumptions, tasks, a diagram. You can argue with it. Each change creates a new blueprint version. No code is generated until you click Approve plan. That gate is required, not optional.

After approval, the Develop tab builds an App Builder workspace. Adobe says a typical blueprint comes back in under 60 seconds. Full code generation can take up to 5 minutes depending on scope. You can pause a run and come back. Project memory persists across sessions, which is nice until you realize a new chat thread in the same project is not a fresh start. The project is the source of truth.

What the generated extension can include, per Adobe's capabilities page:

• App Builder Commerce extension scaffolding that App Management can install
• Event-based listeners
• Webhook-based interceptors for validation
• Merchant-configurable settings
• Persistence for extension-owned data
• A ZIP export of the workspace

Adobe runs validation checks on the output. They still tell you to review every line before production. I agree with that sentence more than with the rest of the pitch. Complex business logic, especially anything that touches money or security, needs a human who already knows Magento.

The UI also has Integrations (GitHub, App Builder) and Deployments. Blueprint and Develop work with little setup. The later tabs often need extra wiring.

A prompt that works better than "build an action"

Adobe's prompting advice is the same thing I tell people using any coding agent: describe the business event, not the Magento class you already decided on.

Weak: "I need an action."

Better: "I need to send order data to an external OMS when an order is placed."

That prompt is asking for this shape:

The skills and prompts page has two samples I would actually paste.

ERP notification, integration starter kit:

Implement an Adobe Commerce SaaS application that will send an ERP notification when a customer places an order. The ERP notification must be sent as a POST HTTP call to <ERP URL> with the following details in the request JSON body:
 
Order ID -> orderID
Order Total -> total
Customer Email ID -> emailID
Payment Type -> pType

Custom shipping, checkout starter kit:

Implement an Adobe Commerce SaaS application that provides custom shipping methods.
The extension should:
1. Return shipping options based on the destination postal code
2. If postal code is in California, add an "Express California" option for $15
3. If postal code is outside US, add an "International Standard" option for $25
4. The carrier code should be "MYSHIP"

After the first generate, keep talking on the Develop tab. Adobe's own follow-ups are boring in a good way: make the log level configurable, add validation before the HTTP call, add tests for the event handler, generate a README. If the first pass is wrong in a fundamental way, they say start a new run with a tighter blueprint instead of endlessly patching a bad plan.

Cursor and the MCP pack

If you already live in Cursor, this is the path I would take first. You still need Node 22+, npm or yarn, Git, and a bash shell. Then either:

aio commerce extensibility app-setup

That one is the long wizard: Adobe Developer Console project, APIs, starter kit clone, .env, skills, MCP. It asks which starter kit (Integration, Checkout, or AEM Boilerplate Commerce) and which coding agent (Cursor is on the list).

Or, if the repo already exists:

aio commerce extensibility tools-setup

After install, restart Cursor. Skills land under .cursor/skills/. Open MCP Settings, find commerce-extensibility, turn it on. Log in so the RAG docs search actually works:

aio auth login
aio where

Without login, some tools still run. The documentation lookup does not. That is the piece that makes this different from a generic agent guessing Magento XML from 2021 blog posts.

Adobe's smoke-test prompt is decent:

What are the differences between Adobe Commerce PaaS and Adobe Commerce as a Cloud Service when configuring a webhook that activates an App Builder runtime action?

If the agent ignores the MCP server, tell it to use the commerce-extensibility tools. I have had to do that with other MCP servers too. It is not unique to Adobe.

Skills you can invoke by name:

Pick AEM Boilerplate Commerce during setup and you also get the dropins MCP server plus storefront skills (/researcher, /dropin-developer, /block-developer). Those query real slot, event, and container data instead of inventing drop-in APIs.

You can search docs from chat:

/search-commerce-docs "How do I subscribe to Commerce events?"

What it will not do

Adobe is unusually honest here. I am copying the list because this is where people get burned.

The hosted agent does not generate API Mesh. It does not do AEM Experience Modernization / Edge Delivery content migrations. It does not set up local Docker or Composer for you. No CI/CD pipeline. One generated project per session. No org-level RBAC beyond IMS. No customer-facing usage dashboard with real detail yet.

Net-new quality drops on custom PWA scaffolding outside Edge Delivery, on multi-extension dependency graphs, and on payment gateways. Adobe says those need extra scrutiny. I would add anything that replaces a large in-process PHP module with years of edge cases. The agent can get you a workspace that compiles. Knowing whether that workspace matches how your catalog, quotes, and payments actually behave is still on you.

Generated code is scaffolding. Adobe says that in the FAQ. If a run is garbage, refine it in Develop. If it is structurally wrong, start over. There is a feedback channel for quality issues.

When I would actually use it

I would use the hosted agent when a client already has App Builder, a written requirement, and a module that is mostly "on this Commerce event, call that HTTP API." I would also use it to get a first-pass architecture out of a Migration Assessment instead of staring at a PHP plugin list for a day.

I would use the Cursor MCP pack on any ACCS / App Builder repo I am already in, even if I never open the hosted UI. The docs search alone is worth the setup.

I would not use either of them to "migrate the whole customizations folder." That is not what this is.

The video playlist walks the full loop if you want the screen-by-screen version: overview, blueprint and develop, connect integrations, deploy and install, configure and test, migrate existing code.

Official resources

• Commerce Developer Agent overview
• Getting started
• Net-new development
• Commerce development MCPs and skills
• Skills, prompts, and commands
• dropins MCP server
• Launch the hosted agent
• Video tutorials

If you try this on a real module, I want to hear what the first generated blueprint got wrong.