Agents inside the platform you already sell on
One agent core, six sets of tools. The reasoning, the eval suite, the tracing and the approval model are the same work on every platform. What changes is the tool layer underneath.
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 these six 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 |
| HighLevel | Marketplace app, location scoped | contacts, opportunities, conversations |
HighLevel conversation view |
| BigCommerce | Catalog and Orders APIs | /catalog/products, price-lists, channels |
Staged batch review |
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.
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.
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.
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.