AI agents for the platform you sell on

01Same

What does not change from platform to platform

The expensive part of an agent build is not platform specific. We build it once and carry it across, which is why the second platform costs less than the first.

Agent core: Planning, tool selection and stopping conditions, built once and reused on every platform we point it at.
Eval suite: Written from your real examples before the agent exists, and run again on every change we make.
Tracing: The plan, the tool calls, the inputs, the outputs and the cost are recorded for every run, so you can see why the agent did what it did.
Human gate: Write actions wait for a person by default on every platform. We open that up only where you tell us to.
Budgets: Cost and latency ceilings are set per task and enforced inside the run, not reviewed after the invoice arrives.

02Differ

What changes is the tool layer

Each platform exposes a different API, names its records differently, and has a different place to host an approval queue. That is the honest reason we can cover all of these without being shallow on any one of them.

Platform	Agent surface	Reads and writes	Where approval lives
Shopify	Embedded admin app, Flow trigger	`orders`, `products`, `metafieldsSet`, `refundCreate`	Shopify admin
Wix	Velo backend, Wix Automations	`wix-data`, Catalog, CRM Contacts	Wix dashboard collection
WordPress	Plugin on WP-Cron	`/wp/v2/posts`, `/wc/v3/orders`	WordPress admin, pending queue
Ecwid	REST app, `/batch`	`/products`, `/orders`	Email with trace attached
BigCommerce	Catalog and Orders APIs	`/catalog/products`, `price-lists`, `channels`	Staged batch review
Magento	REST API, custom admin module	`/V1/products`, `/V1/order/{orderId}/refund`	Admin grid in the module
Squarespace	Commerce APIs, webhook subscriptions	Orders fulfillment, Inventory adjustments	Hosted queue, linked by email
Webflow	Data API, webhooks	CMS items as drafts, `orders`	A person publishes
HighLevel	Marketplace app, location scoped	`contacts`, `opportunities`, `conversations`	HighLevel conversation view
HubSpot	Private app, workflow trigger	`contacts`, `deals`, `tickets`	Task on the HubSpot record
Salesforce	Connected app, Platform Events	`Case`, `Lead`, `Opportunity`	Approval process on the record
Zendesk	Ticketing API, sidebar app	`tickets`, internal notes	An agent sends the reply
Custom stack	MCP server over your API	Your endpoints only	Your internal tool

The same three jobs keep coming up across all of them: triage, catalogue and content work, and order or pipeline operations. See how we build them in agent engineering.

03Gate

The gate sits where the risk sits

Every platform holds write actions for a person by default. What differs is which action counts as the dangerous one, so we set the gate against the real risk rather than applying one rule everywhere.

HighLevel

The gate is every outbound message, without exception, because SMS and email marketing are regulated. The agent drafts the reply and a person sends it. We do not make that gate optional.

BigCommerce

The gate is a record count. Bulk writes are the expensive mistake on a catalogue this size, so the agent stages the whole change set, reports how many records it would touch, and waits for someone to approve the batch.

WordPress

The gate is post status, because the platform already has a review queue. Posts stay at draft or pending, comments are held rather than deleted, and every write runs as a user checked with current_user_can.

Shopify, Wix and Ecwid follow the same logic. On Shopify the held action surfaces in the admin next to the record it would write. On Wix the queue is a collection in the dashboard. On Ecwid, where a store is often run by one person, approvals arrive by email with the trace attached, because there may be no dashboard anyone checks.

04Pick

Go to your platform

Each page names the use cases we build there, the API surface the agent touches, and where the approval queue lives.

05Asked

Questions we get about platform coverage

We use two of these. Can one agent span both?

Yes, and it is a common shape. The agent core stays single. We build a tool set per platform and hand the agent both, so one run can read a HighLevel contact and write a note on the matching Shopify order. Where the two meet, the stricter gate wins: if outbound messaging waits on one platform, it waits in the joined run too.

What if our platform is not on this list?

These are the platforms we work on most, not the limit of what an agent can reach. If your system has a documented API and a way to authenticate an app, the agent core, the eval suite and the tracing are unchanged, and the work is the tool layer. Tell us what you run and we will describe that layer before you commit to a build.

Do we need to give you production access to start?

No. We start on a development store, a staging site or a sandbox sub-account, with the eval cases written from real examples you send us. Production access comes later, scoped to the operations the task actually needs, and write actions still wait for a person by default once it does.

Tell us the platform and the task

Name the one job you would hand over first. We will tell you what the agent would touch on your platform, where the approval sits, and what it would cost to run.

Start a project

Agents inside the platforms you already run