Let the Agent Build It. Keep the Sign-Off.

An AI agent can build a five-page brochure site in an afternoon. It writes the pages, sorts the responsive breakpoints, wires up the contact form and deploys to staging. Then it tells you it's finished and everything works.

Sometimes that's true. Sometimes the contact form posts to an endpoint that was never configured. Sometimes "checked on mobile" meant the agent read its own CSS and decided it looked fine. Sometimes there are 140 pages and it got to 90 before it ran out of context, and its summary didn't say so.

None of that is the agent lying, exactly. It's an agent being an agent. But when the site goes live, it's your name on the invoice. When the client finds a broken form three weeks later, they won't be calling the agent.

This release gives your agent a proper place in your Launch and Migration checklists, with one firm rule: the agent does the work, and you do the sign-off.

• * *

What's new

Your agent could already read a Launch or Migration checklist and tick tasks off through the Website Toolkit API or its MCP server. Three things have changed.

1. "Done" from an agent is now a proposal. When an agent marks a task done, the task doesn't tick. It shows on your dashboard as "AI marked this done, awaiting your approval", with the agent's note explaining what it checked. You click Approve or Dismiss. The agent can still set a task to in progress directly, since that commits nothing.

2. Agents can work the Site Content tab, page by page. Site Content is the page-by-page grid of Desktop, Tablet and Mobile boxes, once before launch and once after. An agent can now list the pages still unchecked, review each one at each device width, and mark the boxes as reviewed. Those boxes go into the same amber pending state your client's review button uses. They never go straight to approved, and an agent can never untick something you've already approved.

3. Agents can add tasks. An agent that spots something that needs doing, like a 404 linked from the footer or a form with no confirmation message, can add it to your Pre-launch, Post-launch or To-do list. It's flagged AI added and comes with the agent's reason, so you know where it came from and can delete it if the agent got it wrong.

Every state change an agent makes is labelled as AI, and every note it leaves is kept. When you look at the checklist later, you can tell what you did from what the agent did.

• * *

Why "honest" needs a design, not a prompt

You can tell an agent to be careful. You can write "never say something is tested unless you tested it" in your rules file, and you should. But a rule in a prompt is a request. A rule in the system is a fact.

Here's what the toolkit enforces regardless of what the agent decides to do:

• It can't close anything. Every "done" and every reviewed box waits for you. If an agent works through all 40 pre-launch tasks in one go, you get 40 proposals, not 40 ticks.
• It has to show its working. Every proposal carries a note, and the tool instructions ask the agent to say what it checked and what it found. "Favicon served at /favicon.ico (200, 32×32)" is something you can verify in five seconds. A bare "done" isn't.
• The crawl checks it independently. Many checklist items are auto-detected from the site crawl: titles, meta descriptions, broken links, HTTPS, analytics. Re-crawl after the agent's changes and those items reconcile to what the crawler actually saw, not to what the agent said.
• Audit fixes don't stick on a promise. As before, an issue the agent marks fixed in an audit comes back on the next crawl if the fix didn't land.
• Your client never sees the agent's internals. The client-share link shows the checklist as you've approved it. AI notes, proposals and badges are only on your edit view.

Put together, the agent can do as much work as you like and still can't sign anything off.

• * *

Which builders it works with

Anything that speaks MCP connects directly, including Claude Code, Claude Desktop, Cursor, Windsurf and VS Code. Generate a token on the Domains page of your client portal, under API access. The panel gives you a setup command with your token already in it:

claude mcp add --transport http wsc-crawler https://your-server/mcp \
  --header "Authorization: Bearer your-token-here"

Other MCP clients take the same URL and Authorization header in their MCP settings.

Hosted builders without MCP, such as the browser-based "describe your site and we'll build it" tools, can't call the toolkit themselves. That's fine, because the checking doesn't have to be done by the agent that built the site. Point a separate agent, like Claude Code or a script against the REST API, at the deployed staging URL and let it work the checklist. A second agent that didn't write the code is arguably the better reviewer anyway.

Scripts and automations (n8n, Zapier, CI) use the same REST endpoints with the same token.

• * *

A launch, the honest way

Here's the loop for a new site an agent built for you.

1. Crawl staging and start a launch checklist. Either from the portal, or ask your agent: "Start a launch checklist for clientsite.com from the latest crawl."
2. Let the crawl go first. The auto-detected tasks are already ticked or left open based on what the crawler found. That's your independent baseline before the agent says anything.
3. Hand the agent the manual tasks. "Work through the open pre-launch tasks. For each one, check it on staging and propose it done only if you've verified it. Put what you checked in the note. If something's wrong, fix it if you can, otherwise add a to-do saying what's needed."
4. Hand it the pages. "List the Site Content pages still unchecked for pre-launch. Review each one at 1440, 820 and 390 pixels wide and mark the devices you actually looked at. Note anything that looks off, and add a task for anything that needs fixing."
5. Re-crawl, then recheck. The auto tasks reconcile to the new crawl. Anything the agent "fixed" that didn't land stays open.
6. Review the proposals. Open the checklist. A violet bar tells you how many tasks are waiting, and Show only these narrows the list to them. Read each note and approve or dismiss. On Site Content, use Show: Not checked with the Phase and Device filters to see exactly what's left. For example, Not checked · Pre-launch · Mobile is every page nobody has signed off on a phone yet.
7. Send the client their review link. They see a clean checklist, review the pages themselves with the feedback widget, and their review marks land in the same queue for you to approve.

For a migration it's the same loop, plus the redirect map. The agent imports the old URLs, checks every one of them, and fixes the ones that don't land. The "all old URLs redirect correctly" task ticks itself only when the check genuinely passes.

• * *

What only you can cover

This is the part that matters most for a freelancer. An agent can check whether a page renders. It can't take responsibility for the job. These are the things worth keeping on your checklist as yours, and which no agent proposal should close.

Things the agent can't see:

• Does the contact form actually reach the client? An agent can submit the form and get a 200 back. Only a person can confirm the email arrived in the right inbox and not in spam. Send a test, then ask the client to confirm they got it.
• Real devices. Resizing a browser window isn't an iPhone with a notch, Safari's address bar and a slow 4G connection. Check the key pages on an actual phone yourself.
• Is the content true? Prices, phone numbers, opening hours, team names, the year in the footer. An agent will happily check that text exists. It can't know whether it's right.
• Payments in live mode. If the site takes money, run a real transaction and refund it.

Things the agent can't be accountable for:

• Legal pages and consent. An agent can draft a privacy policy and add a cookie banner. Whether they're accurate for this client's data, and whether non-essential tracking waits for consent, is a professional judgment. Your liability doesn't move to the tool that wrote the first draft.
• Licences. Stock images, fonts, premium plugins and themes. Agents pull in assets without thinking about who paid for them. Check that every one is licensed, and licensed to the client where it needs to be.
• Accessibility claims. Automated checks catch maybe a third of real accessibility problems. If you're promising a standard, a person has to test with a keyboard and a screen reader.

Things only you can hand over:

• Ownership and access. The domain, DNS, hosting, analytics and search console should be in the client's name with your access added, not the other way round. Write down where every login lives.
• Backups you've actually restored. "Backups are configured" and "I restored one and it worked" are different claims. Only the second protects you.
• Email authentication. Set up SPF, DKIM and DMARC for the domain, so the client's mail doesn't start bouncing the week after launch.
• What happens after launch. Who fixes things, how fast, and for how much. That's your contract, not the agent's.

A practical tip: add these as custom tasks to your launch template once, in a group called something like Freelancer sign-off. Every new project then starts with them, and they sit on the checklist right next to the agent's work, where you can't forget them. If an agent ever proposes one of them as done, that's your cue to look closer.

• * *

A rules snippet for your agent

Whatever builder you use, give the agent standing instructions. Put something like this in CLAUDE.md, your Cursor rules or the equivalent:

## Launch checklist (Website Toolkit)

- Before launch work, read the checklist with list_project_tasks and
  list_site_content (onlyUnchecked: true).
- Only propose a task as done after you have verified it on the deployed
  staging site. Always include a note: what you checked, how, and the result.
- When you review a page, mark only the devices you actually viewed, at
  1440 / 820 / 390px. Note any visual problems.
- If you find a problem you can't fix, use add_project_task to add it to
  the To-do list with the URL and what you saw. Don't silently skip it.
- Never propose tasks in the "Freelancer sign-off" group. Those are mine.
- Saying you're unsure is fine. Leave the task in progress with a note.

The toolkit enforces the important parts anyway. Proposals still wait for you whatever the agent's instructions say. This snippet just makes the agent's notes more useful.

• * *

The new tools

Over REST, the same operations live under /api/client-api/v1/{domain}/projects/{type}/: POST tasks adds a task, POST tasks/{key}/state sets a state, GET site-content lists pages and POST site-content/mark marks a page. The MCP guide has the full reference.

If you've scripted against set_task_state before, note the change: done no longer ticks the task directly. Your script gets back "applied": false, "proposed": "done", and the tick happens when you approve it on the dashboard.

• * *

The point

Agents have made building a site fast and cheap. That's great for freelancers, until speed turns into a launch nobody checked properly. The value you add was never typing the HTML. It's knowing what has to be true before a site goes live, and being the person who can say it is.