Three steps · the first one is yours
How Syncanix works
You paste one line. It reads your product on its own and writes down every screen, form and action it finds. Then you decide, one by one, what it is allowed to do, and nothing is switched on until you say so.
The sequence
From a script tag to a working agent
There is no specification to write, no catalog to upload and nobody on your team sitting down to explain your product to it.
You paste one line
about 2 minutesOne script tag, in the same place your analytics tag already sits. That is your entire part of the setup. There is no package to install, no code to change and nothing to send us.
- It goes in your page head, your tag manager, or your app’s root layout, whichever you already use.
- It reads the fonts, colors and corner radii off the page it lands on, so it looks like your product on the very first load.
- Nothing is visible to your users yet. Until you finish step three it is reading, not answering.
<script type="module" src="https://cdn.syncanix.com/widget.js" data-key="pk_live_…" ></script>The whole install. You do not need to understand it. It is here so you can see there is nothing else. It reads your product
the first hourThis is the part nobody has to do. It looks at the pages your product is made of, the buttons, the forms, the links, the things a person can fill in, and writes down what each one appears to do. You end the hour with a list, not a promise.
- Map your site: you click through your own product in your own browser, signed in as yourself, and it writes down what it sees on each screen.
- It runs in your browser, on your session. We never hold a password to your product and never crawl it from outside.
- It keeps reading afterwards, quietly, as your own users move around. Ship a new screen and it is picked up the same day. Nobody files a ticket.
- If your engineers want to be exact, they can also point a one-off scan at your source code. It is optional, and nothing else waits on it.
- What comes out is a set of guides, drafted from what it found. "How do I refund an order", walked through on your own pages. You publish the ones you want.
You approve what it can touch
an afternoon, onceEverything it found arrives switched off. You go down the list and turn on the things you want it to handle, and for anything that changes data, you decide whether it should ask the person first. Nothing here is a default we picked for you.
- Off by default, always. A capability nobody approved is a capability the agent does not have.
- Each entry is written in plain language, “refund an order” rather than an address on your API, so the person approving does not need to be the person who built it.
- Anything the agent discovered by looking at a screen always asks the person before it runs, whatever else you set.
- You can change any of it later, from the dashboard, without touching your product.
Once it is live
What your users get
Not a help center that talks. Something that can answer from your real data and then do the thing it just described.
Answers from your data, not from a manual
It looks the answer up the same way one of your staff would, in the account the person is actually signed in to.
“Why did our bill go up this month?”
Does the work, with the person watching
For anything that changes something, it shows a card with the exact change and waits. No card, no action.
“Tom left on Friday, close him out.”
Shows people where things are
When the right answer is a screen the person has never found, it walks them there and points at the control. The pointer is a highlight, not a click. If they would rather it were done for them, that goes through the same approval card as anything else.
“Where do I change who gets the invoices?”
The guardrails
What stays under your control
These six hold for every action, on every surface, whether or not anybody configured anything.
It is never more powerful than the person using it
It acts as the signed-in user, with exactly their permissions. If they cannot see a record, neither can it, and asking nicely does not change that.
It asks before it changes anything
The card shows the actual before-and-after, not a summary. Approving is one action, once, and an approval cannot be reused for a second attempt.
Everything it did is written down
Who asked, what ran, what changed, and when. The record is tamper-evident: a row that was edited or removed shows up as one.
You decide what it can reach
Per capability, per group of users, and per page. You can also give one part of your product a narrower set than the rest.
Your data stays in Europe
Stored in Frankfurt, and the AI runs there too. Nothing you send is used to train anybody’s model, ours or a provider’s.
You can stop it in one click
Switch off one capability, one surface, or the whole agent, from the dashboard. It takes effect on the next request. No release, no ticket.
Where it appears
Two places, one set of rules
The same approvals, the same limits and the same audit trail apply to both. There is no second place to configure.
Inside your own product
A chat surface that lives on your pages and looks like the rest of them: a corner bubble, a side panel, or the whole screen, whichever suits the page it is on.
This is what the script tag turns on.
In the AI tools your customers already use
Your product becomes something they can connect to Claude, Cursor or ChatGPT and operate from there, with the same approvals you set here.
Each workspace gets its own connection. Nothing is shared between customers.
See it read your product
We will put the script on a staging copy of your product and show you the list it comes back with. No slides.