What it checks
The walk takes three steps, in order:
To find the signup page, the walk follows the plan’s link, or your home page’s own signup link, or the Sign-up link in your Brand Book, in that order.
If your Brand Book has a confirmed sign-up link, which is the link the brand MCP server’s
get_signup_link gives assistants, the walk opens it too and checks that it works and leads to your signup form.
What it never does
The walk only reads. Every step opens a page, the way typing an address in a browser does. It never:- types into a field, ticks a box or presses a button;
- submits a form, so your signup endpoint never receives anything from it;
- signs in, creates an account or buys anything;
- answers a CAPTCHA or bot check;
- opens a page outside your workspace’s domain and its subdomains, or a page that is not
https.
Before it runs
The walk needs a person’s consent to visit your domain. Without a live consent it does not run, and the check readsnot_consented with the step to take: give consent in the app under Settings. When a consent expires after 90 days, the walk stops until it is renewed. Nobody at Attensira does this for you.
Browser runs that are paused in your workspace (or stopped for everyone) hold the walk too, and it runs at most twice a day per workspace, whatever retries ask for.
What it files
Each kind of blocker files one Change:
Each Change is in the
own_site lane, says what to change, and carries its evidence: the page, a screenshot of it as the agent saw it (from the browser run), and the part of the page the finding is about. You make the change on your site and mark it shipped. Because it changes how people sign up, it always waits for a person: no autonomy level ships it on its own.
A blocker that is still there next week keeps the same Change; it is never filed twice. When a later walk reaches the step the blocker stopped, the blocker is closed and the Change’s receipt shows it live verified: live_status is live, with the date, the page the walk reached and a sentence saying so. The walk also moves the Change to delivered, so it leaves the Inbox whether or not you approved it first; its timeline says the signup walk found it fixed. A Change you declined stays declined. These Changes have no shipped text to look for, so the weekly live check does not read them; the walk is what keeps their receipt. A blocker that comes back after its Change was delivered or declined is filed as a new Change. If its Change is still open (the walk could not close it), the blocker reopens that same Change, its live_status turns no_longer_live, and nothing new is filed, so there is never more than one open Change per blocker.
Reading it
The check is part of your workspace’s agent readiness, assignup_check:
A
screenshot_url is a signed link that works for 15 minutes; read the check again for a fresh one. Screenshots are kept for 30 days, like every browser run’s (see Data retention). Where the check is not available on a deployment, signup_check is null.
What it costs
The walk is a browser run, so it uses credits for the time the browser runs: half a credit for each started minute, never more than 7.5 credits for one walk (see Browser work). Only a walk that finishes is charged; a walk that breaks on our side, or that you stop, is not. If your balance does not cover a walk, it does not start, andnext_step asks you to add credits; the walk runs again on its next weekly turn.