Building a workflow with the AI Assistant
The assistant sits beside the canvas, not on a server somewhere. You describe what the workflow should do; it reads the workflow you already have, proposes blocks, checks its selectors against the page that is actually open — and waits for you to apply them.
First: give it a key
The assistant uses your model, not ours. Open Settings → AI Assistant, choose a model from the dropdown and paste the API key for it. Claude, GPT, Grok and any OpenAI-compatible endpoint work; you can save several and switch between them.
Two things follow from that arrangement. Your key never leaves your machine except to the provider you chose, and the bill for the model is the provider’s — there is no seat and no credit pack. The assistant itself comes with the paid plans; the Free plan does not include it.
Describe the job, not the blocks
Open a workflow, open the assistant panel, and write what you want in plain language:
Log in with the account in the table, open every order marked New, and copy the order number and total into the sheet.
It answers with a proposal: which blocks, in what order, with which selectors and which fields filled in. Nothing is added to the canvas yet — the proposal sits in the panel until you apply it.
Asking for one step at a time works better than asking for a whole program. “Add a loop over the rows of this table and open each link in a new tab” gives a proposal you can read in a few seconds; “build me a scraper” gives one you have to audit like someone else’s code.
What it can see — and what you decide it sees
Three sources, each one under your control:
- The workflow. The blocks on the canvas and how they connect, so a proposal fits what is already there instead of starting again.
- The last run. A number field decides how many of the most recent blocks’ logs travel with the question. Set it to five and the assistant sees what the last five blocks did — which is usually enough to explain a failure.
- The open page. A checkbox lets it read the DOM of the profile you have open. Passwords, hidden inputs and anything that looks like a token are masked before the page is sent.
Leave both off and it answers from the workflow alone; it says so when it is working blind rather than guessing quietly.
Selectors it has actually checked
The failure mode of “AI writes automation” is a confident selector for an element that is not on the page. When a profile is open, the assistant tests the selectors it intends to use against that page before offering them, and rewrites the ones that match nothing.
You can do the same by hand at any time with the element picker: point at what you want and take its selector, including inside iframes and shadow DOM. The two work together — pick the tricky element yourself, let the assistant wire the rest.
Fixing a run that failed
Every run keeps a log that names the block it stopped on. The useful loop is:
- Open the log and click through to the block that failed.
- Set the logs field to about five, tick the page checkbox if the profile is still open, and ask: why did this block fail, and what should it be instead?
- Apply the proposal if it reads right, then start the run again from that block — not from the top.
Most of what breaks is a selector that changed or a step that ran before the page was ready. Both are visible in the log, which is why giving the assistant those few entries changes the quality of its answer so much.
What it will not do
It does not run your workflow, click Save, or change a block behind your back: every proposal is applied by you. It does not know anything about your other profiles, and it does not send your cookies anywhere — the page context it reads is the DOM, masked, and only when you ask for it.
And it is not a substitute for knowing what the blocks do. The block reference is worth twenty minutes; after that, reading a proposal takes a glance instead of a leap of faith.
Try it on your own machine
The free plan runs ten profiles with the same fingerprints and the same workflow editor as the paid ones.