Shopify's Admin GraphQL API is cost based and rate limited with a leaky bucket, so an agent that fans out across a large catalogue has to budget its calls rather than loop freely. We treat that as the design constraint, not an afterthought, and set a cost and latency budget per task before anything is built.
01Use
Each one is scoped to a single task and reaches the store through tools we build per operation, not a generic passthrough. Because every call is costed, we decide what a run is allowed to read before we decide what it is allowed to write.
Reads the order, the product record and your refund policy, drafts a reply in your voice, and issues the refund when it sits inside policy.
Fills missing product metafields, writes SEO titles and descriptions, and normalises variant options against a supplier feed.
Handles fulfillment holds, corrects addresses before dispatch, and works carrier exceptions instead of leaving them in a queue.
02Wire
Five surfaces, and nothing beyond them. A run can be started by a webhook or by a Shopify Flow action, so merchandising staff can kick off work from the tool they already use.
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 | orders, customers, refund policy |
refundCreate |
Refunds above your threshold |
| Catalogue enrichment | products, productVariants, supplier feed |
productUpdate, metafieldsSet |
Price changes, title changes |
| Order operations | fulfillmentOrders, inventoryLevels |
fulfillmentCreateV2, orderEditBegin |
Cancellations, address edits after fulfillment starts |
03Gate
A held action shows what the agent intended to write, the record it would touch, and the trace that led there. Nothing is written until someone clears it.
The queue is an embedded admin app built with App Bridge, so it opens beside orders and products. The person who already works in Shopify approves the action in Shopify, without a second login or a second tool.
The proposed write in full, named as the Admin GraphQL API operation it would call, the record it targets, and the run trace behind it: the trigger, the reads, and the reasoning that reached the draft.
Refunds above your threshold, every price change and product title change, cancellations, and address edits once fulfillment has started. We widen the agent's authority only on your instruction, one action at a time.
A rejected action stops the run and is recorded with its trace. Those rejections are the best eval cases you will get, so they go into the suite and the agent is tested against them on every change.
04Asked
For a single merchant, a custom app on your own store is the right shape. It is created in your admin, it holds only the Admin GraphQL API scopes the agent's tasks need, and it stays yours. A public app is worth the extra work only when the same agent has to install across stores you do not own. Either way the approval queue is an embedded admin app, so reviewers stay in Shopify.
The Admin GraphQL API is cost based, so every read and write draws from a leaky bucket that refills at a fixed rate. The agent budgets its calls against that bucket instead of looping freely: work that fans out across a large catalogue is split into batches sized to the budget, and when the bucket runs low the run backs off and resumes rather than dropping the remaining records. Every wait and retry lands in the trace, and the cost and latency ceiling for the task is agreed before we build.
Yes. Each store gets its own install, its own credentials and its own call budget, so a long catalogue run on one store cannot starve the support queue on another. Gates and thresholds are set per store too, because the person who signs off a refund is rarely the same person in every market.
Tell us the task you would hand to a capable new starter with admin access. We will tell you what the agent would read, what it would write, where the gate sits, and what a run costs to make.
