Wix is the one platform here that hands you real backend code in the same project as the site. We build agents that run there, in Velo web modules, start from a Wix Automation, and read and write the collections, store records and bookings your site already holds.
01Use
Velo means the agent runs server-side, next to the data. Wix Automations means it starts from something that already happens on your site, a form fill or a store event, without a scheduler bolted on the side. These three use the shape of the platform rather than fighting it.
Reads a form submission, enriches it, scores it against your criteria, then tags the contact and routes it to the right person.
Drafts blog posts and product descriptions against your brand rules, and keeps catalogue copy consistent across the store.
Answers buyer questions from the live catalogue, your shipping rules and your policy pages, rather than from a stale copy of them.
02Wire
Nothing here is a bridge to a second system. The agent is part of the Wix project, using the surfaces the site already uses.
The triggers, queues and retrieval behind these agents are their own lines of work.
03Gate
Wix sites are usually run by one or two people, so the default here is stricter, not looser. Every outbound message and every publish waits. The approval queue is itself a Wix collection, which means it shows up in the dashboard you already open, without another login to remember.
Reads are broad, writes are named one at a time, and nothing leaves the site without a person behind it.
| Agent | Reads | Writes | Human gate |
|---|---|---|---|
| Lead qualification | Form submissions, contacts, your scoring criteria | wix-crm Contacts, wix-data |
Any outbound email or SMS to the lead |
| Content operations | Brand rules, existing posts, catalogue copy | Wix Blog, Wix Stores Catalog |
Publishing. Drafts only until a person approves |
| Pre-sale answers | Catalogue, shipping settings, policy pages | None | Read only. Low confidence goes to a person |
04Asked
Either. The agent lives in Velo backend code, and we build against Velo rather than against the editor you happen to use, so the same work lands on a Wix Studio site and on a standard one. The front end you already have stays where it is. If the front end lives outside Wix altogether, that is the case for Wix Headless, and we say so at scoping rather than halfway through the build.
In .jsw web modules on the Wix backend, in the same project as the site. That is the point of doing this in Velo: the agent sits next to the data it reads, so it queries wix-data collections under the same permissions rules as the rest of the site instead of pulling a copy out to somewhere else. API keys stay in the Secrets Manager and are never exposed to front-end code.
Yes. Bookings is a first-class object on Wix in a way it is not on the commerce platforms, so appointments are a genuine agent surface rather than something bolted on afterwards. We scope booking work the way we scope the rest: reads first, writes named one at a time, and every message that reaches a customer waits for a person.
Name one task your site already generates work for, a form that needs answering or a catalogue that needs writing. We will tell you what it would touch in Velo, what would wait for you, and what it would cost to run.
