Agent-Native Shipping Proof: Run a Peek Before You Ship

October 26, 2026

When an agent ships a page, you still need proof a visitor can do the job — not only that the build succeeded. Boidwatch’s capped peek runs 3 Census-derived personas for up to 15 steps with a 5-minute hard stop, returns the single strongest finding, and gates the full report behind that peek. Agents can call it via the authenticated HTTPS API (POST /v1/peek on api.boidwatch.com). Use peek as the default gate before client review; escalate to a full flock when the engagement needs the complete deliverable.

The missing step in agent-native shipping

The default agency loop with Cursor, Claude Code, Bolt, or Lovable looks like this:

Build → deploy preview → ??? → client.

CI going green answers “did the deploy succeed?” It does not answer “can a visitor complete the job?” An agent can leave a checkout CTA below the fold, a form that never focuses the first field, or a pricing table that reads clean in the IDE and collapses on a phone — and still report done.

That gap is the shipping-proof step: one agent-callable check that runs real browser sessions against the preview URL before the client link goes out.

What “shipping proof” means here

Shipping proof here is not a 200-test suite and not a human teardown booked for next week. It is:

1. One design intent (what the page is supposed to accomplish).

2. Real Chromium sessions driven by Census-derived personas.

3. One ranked finding you can act on before handoff.

Other products in this space frame the problem as “can agents use your product?” (AgentEye), “one command, many testers” (breakit.dev), or agent-callable browser checks (Assrt MCP, Monito MCP). Those are useful frames. The agency job is narrower: prove the preview is safe to show a client, cheaply, from the same agent that opened the PR — then escalate only when you need the full client packet.

The capped peek (exact limits)

Peek is intentionally small. Server-side caps:

| Cap | Limit |

|-----|--------|

| Personas | 3 (Census-derived; default preset us_representative) |

| Steps per persona | 15 |

| Wall clock | 5-minute hard stop |

| Output | One strongest finding (+ confidence) |

| Full report | Gated (report_gated_url / billing path) |

When peek is enough: PR opened, preview URL live, you need a yes/no gate before the client sees it. Paste the finding into the PR or handoff note; fix blockers; ship the link.

When to escalate: use --quick on the CLI for a 5-persona credit run, or run a full flock (20 personas per llms.txt) when the engagement needs the complete report and a public share link for the client packet. Those counts and ungated complete reports require wallet top-up / a paid run outside the free cap. Peek is not a substitute for that full pass.

New accounts get 30 free credits (1 credit = 1 persona), but signup credits alone do not lift the free cap: without wallet top-up, ordinary runs remain capped at 3 personas with gated results. Peek uses the same authenticated account surface; it does not invent a separate anonymous path.

How agents call it

No dashboard babysitting is required for the gate. Authenticate once (BOIDWATCH_API_KEY from API keys settings), then call POST /v1/peek with curl from the agent terminal.

curl from the agent terminal

Call peek with curl (or any HTTP client the agent already uses):

export BOIDWATCH_API_KEY=fg_live_...

curl -sS -X POST https://api.boidwatch.com/v1/peek \
  -H "Authorization: Bearer $BOIDWATCH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://preview.example.com",
    "design_intent": "Understand pricing and start a trial"
  }'

Response includes a run_id. Poll GET /v1/runs/{id} until complete, then:

curl -sS "https://api.boidwatch.com/v1/runs/$RUN_ID/results?format=peek" \
  -H "Authorization: Bearer $BOIDWATCH_API_KEY"

You get { run_id, finding, confidence, report_gated_url, pay_url }.

Adjacent CLI paths create ordinary /v1/runs, not peeks: boidwatch --json run create --url --design-intent "" --quick --wait (5-persona credit run) or the same without --quick (20 personas). These counts and ungated complete reports require wallet top-up / a paid run outside the free cap. Install from llms.txt / install. GitHub Action is also a supported surface for CI-adjacent gates.

Authenticated HTTPS `POST /v1/peek`

Same contract as above. Required: Bearer API key (or session). Body accepts create fields plus top-level url; exploration mode is forced; free caps apply even on paid accounts. Results shape for agents is ?format=peek — one finding, not the ungated HTML dump.

Base URL: https://api.boidwatch.com.

MCP tools (`boidwatch mcp`)

claude mcp add boidwatch -- boidwatch mcp

MCP is an adjacent ordinary-run surface using /v1/runs, not peek. Documented tools: boidwatch_quick_check (a 5-persona credit run, subject to the same free cap without wallet top-up; returns within about 45s; if still running, returns a run_id — resume with boidwatch_get_results, do not call quick_check again) and boidwatch_get_results. For a capped peek, use POST /v1/peek + ?format=peek from the same agent session. MCP and CLI share the same API key env.

What you do with the one finding

Three outcomes:

1. Fix — finding is a blocker (broken primary path, missing CTA, unreachable form). Patch, redeploy preview, peek again.

2. Accept — finding is real but out of scope for this ship (copy preference, secondary nav). Note it in the PR; do not block the client link.

3. Escalate — client packet needs the full flock, ranked gaps, and a public share link. Use wallet top-up / a paid run outside the free cap for full (20 personas) or --quick (5 personas) and an ungated complete report, then share from the report.

Concrete SOP line: paste the peek finding into the PR description or handoff note before the client URL goes out.

Guardrails

Peek is not:

A full UX audit (use a full flock for that).
Accessibility certification.
Security testing.

It is a shipping gate: real Chromium, Census personas, capped budget, one finding, gated full report.

FAQ

How do I prove an agent-built website works before I ship it?

Deploy a preview URL, set a one-line design intent, and run an authenticated Boidwatch peek (curl POST /v1/peek). Read the single strongest finding. Fix blockers before the client link goes out; escalate to a full flock when you need the complete deliverable.

What is a “shipping proof” step for agent-native web work?

The step between “agent says done” and “client sees URL.” It proves a visitor can do the intended job in a real browser — not that CI passed. In Boidwatch that step is the capped peek.

What’s a capped peek in Boidwatch, and when should I use it vs a full run?

Peek: 3 personas, 15 steps, 5-minute hard stop → one strongest finding → full report gated. Use it as the default pre-client gate. Use --quick (5-persona credit run) or a full flock (20 personas) when the engagement needs the complete report and shareable client packet; those counts and ungated complete reports require wallet top-up / a paid run outside the free cap. Without wallet top-up, even accounts with signup credits remain capped at 3 personas with gated results. Peek does not equal a full flock.

Can coding agents (Cursor, Claude Code, Bolt, Lovable) trigger that proof themselves?

Yes. Those agents are named on the product homepage as the intended callers. Authenticate with an API key, then call peek via HTTPS with curl from the agent terminal — no human dashboard step required for the gate.

Run peek on your preview URL

From the agent that just opened the PR: authenticate, curl POST /v1/peek at the preview URL with a one-line design intent. If the strongest finding is a blocker, fix before the client link goes out.

curl -sS -X POST https://api.boidwatch.com/v1/peek \
  -H "Authorization: Bearer $BOIDWATCH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://YOUR-PREVIEW-URL","design_intent":"YOUR ONE-LINE INTENT"}'

Get a key at app.boidwatch.com/settings/api-keys. Install and agent docs: boidwatch.com · llms.txt.