Adobe Commerce and Magento Open Source give an agent a full REST API, a GraphQL API and a module system. We build the agent's tools against the REST API, host its approval queue in a small admin module, and keep every write behind a person until you say otherwise.
01Use
Each one does a single job, reaches the store through tools we build per endpoint, and holds any write for a person in the admin you already use.
Reads the order, its items and the customer record, drafts a reply for the ticket, and prepares a refund when the case sits inside your policy.
Fills missing attributes, writes product copy and meta fields, and checks products against a supplier feed before anything is saved.
Watches orders that stall, prepares shipments, and adds a comment to the order with what it found and why.
02Wire
Five surfaces, and nothing beyond them. The agent works through the APIs Magento already exposes, and the only code we add inside Magento is a small admin module for the approval queue.
Read access is broad enough to answer the question, write access is narrow, and every write has a gate until you decide otherwise.
| Agent | Reads | Writes | Human gate |
|---|---|---|---|
| Support triage | /V1/orders, /V1/customers |
/V1/order/{orderId}/refund |
Every refund until you set a threshold |
| Catalogue enrichment | /V1/products, supplier feed |
/V1/products (attributes, copy) |
Price and name changes |
| Order operations | /V1/orders, /V1/inventory/source-items |
/V1/order/{orderId}/ship, order comments |
Address changes, cancellations |
03Gate
A held action shows the write the agent intends, the record it would touch, and the trace behind it. Nothing reaches the store until someone clears it.
The approval grid is part of a small admin module, so it opens inside the Magento admin with the same roles and permissions your staff already have.
The proposed call in full, named as the REST endpoint it would hit, the order or product it targets, and the run trace that led to it.
Every refund, every price and product name change, shipments where the address changed, and any cancellation. Authority widens only on your instruction.
A rejected action stops the run and is kept with its trace. Rejections become eval cases, so the agent is tested against them on every change.
04Asked
Yes. The REST and GraphQL APIs the agent uses are part of both. Where Adobe Commerce adds features, such as its B2B modules, we only use them if your store runs them.
Only a small admin module for the approval grid, installed through your normal deployment. The agent itself runs outside Magento and talks to it through the APIs with its own integration token.
It should not. Bulk work is batched, runs through your message queue or off-peak cron where you have one, and is paced so the storefront keeps its capacity.
Tell us the task you would hand to a capable new starter with admin access. We will tell you which endpoints the agent would call, where the gate sits, and what a run costs to make.
