Two fixed-scope diagnoses, and the work that follows

What an AI shopper actually receives from one live Shopify store, tested across the three agent surfaces this check covers and reported with the evidence attached.

What you get

• A three-surface map of browser WebMCP, remote Storefront and UCP MCP, and Agentic channels
• A product truth matrix comparing what each surface says about the tested products
• Buyer-journey evidence with the tool, the input, the observed result and the exact stop before payment
• A prioritised correction plan of up to five changes, each with an owner and an acceptance check
• One retest of up to two corrected items within 14 days

What you do not get

• Calls or meetings
• Implementation of the corrections, which is a separate engagement
• A penetration test, or any Shopify, MCP, WebMCP or UCP certification
• A test order, because the cart lifecycle stops before payment

The audit is not a prerequisite. The full scope, the exclusions and the preflight are on the product page.

Suited for D2C Shopify stores that want documented evidence of what an agent receives from them today.

A measurement of how agent-ready your site and APIs are today, with a prioritized list of what to fix first.

What you get

• An independent scanner runs against the site or API
• Manual review of /.well-known/ manifests, JSON-LD, head metadata and HTTP headers
• Review of robots.txt, sitemap.xml, ai.txt and llms.txt against current agent norms
• A live check of how AI assistants and agents retrieve and answer questions about the site or API today, across several AI platforms (answer engine optimization, AEO)
• Written report with findings ranked by score impact and implementation cost
• One round of written follow-up questions

How it is measured

• Every agent-readiness check an independent scanner runs, recorded per check rather than as one headline number
• A fixed question set put to several answer engines, recording whether they name your site when asked about your category rather than by name
• Your published web security scans, so the report rests on measurements you can re-run yourself

What you do not get

• Calls or meetings
• Implementation of the fixes (separate engagement)
• Ongoing monitoring (separate engagement)

Levels move with the check set. The same site can read Level 1 on a full run and Level 2 on a narrower one, so the report names the checks that failed and what each one costs to fix, and leaves the headline number out of it.

Large sites are covered in full. If a site is big enough that the live checks reach a tool quota, the quota is raised rather than the coverage reduced. Once the audit is complete, the fixes it lists are typically about a day of implementation work, whether your team does them or I do. That figure is an estimate scoped to the findings this audit lists, not a fixed quote, and the audit is what identifies that work and orders it by impact.

Suited for teams that want a clear picture of where they stand before deciding what to do about it.

Ongoing input on agent-readiness as part of your product roadmap, with tracking of how the scores change over time.

What you get

• Monthly re-scan and score delta report
• Monthly AI-visibility delta from the same question set re-run across several AI platforms (answer engine optimization, AEO)
• Written review of any agent-readiness related work your team ships, within one business day
• Roadmap input on what to ship next and why
• Async channel for questions (email or shared doc)
• Quarterly summary of measurable progress

What you do not get

• Calls or meetings
• A promised score, because the check set changes when the standards do

The monthly re-run uses the same measurement as the audit, so a delta means something. A number that moved for a reason nobody can name is not progress, and the review says which change moved it.

Suited for teams treating agent-readiness as an ongoing product responsibility rather than a one-off cleanup.

Hands-on work on the fixes the audit identified, or new agent-ready infrastructure built from scratch. The audit comes first, because the day is spent building rather than diagnosing.

Your traffic runs through an edge worker I deploy in front of your origin, and the access to do that exists before the day starts. Cloudflare Workers is the default, because that is what this site runs on. Any edge runtime that executes your code in front of the origin does the same job, Fastly Compute, Akamai EdgeWorkers, AWS Lambda@Edge and the edge functions on Netlify and Vercel included, so tell me which one you run when we scope the day. The worker adds agent surfaces beside your site, and it does not touch your application.

Typical work

• Head metadata and /.well-known/ files served at the edge
• robots.txt with AI crawler rules and Content Signals, and a Web Bot Auth directory
• Markdown content negotiation, so a request asking for text/markdown gets markdown while a browser still gets HTML
• An agent skills index, auth.md and an API catalog
• JSON-LD generators for product, organization and article schemas
• ai.txt and llms.txt authoring
• Signed content and agent authentication patterns
• An MCP server card and an agent-to-agent card for a server that already runs, and the discovery paths that point at it

What a day does not cover

• DNS records for agent discovery, which need your DNS rather than an edge worker
• Tool declarations inside your pages, which are application work
• Agent commerce protocols, which need working payment flows behind them
• Building the MCP server itself, which is its own engagement, so a card written on a day points at a server that already runs

You check the work yourself. Run the scanner before the day and after it, so the result is a number you produced. I do not promise a readiness level, because the level moves depending on which checks are run.

Scoped repository write access per task. No retainer.

The work beyond readiness, for teams moving from "an agent can read us" to "an agent can act on a system that matters." Two things decide whether an agent acts correctly. The data it works from has to arrive intact, even over links that drop or lag. And the decisions it is allowed to make have to sit inside an envelope of permissions and thresholds you set deliberately.

Typical work

• Review of the data path an agent depends on, and where it breaks under real network conditions
• The permission and threshold envelope that bounds what an agent may decide and act on
• Where a human stays in the loop, and how control passes between person and agent
• Guardrails and verification so an agent's decisions can be checked after the fact

What decides the price

• How many systems the agent touches, and whether any of them can move money or delete data
• Whether a decision boundary exists already or has to be written from scratch
• Whether the work ends at a written envelope or continues into building the guardrails

What you do not get

• Calls or meetings
• An agent built for you, because this is the envelope around one rather than the thing itself
• Sign-off that your agent is safe, because a review cannot promise that

Suited for teams letting agents act on data and decisions that matter, rather than only reading a marketing site.

An MCP server built for your product, exposing read-only data to agents over streamable HTTP transport. For public, non-sensitive data, no auth surface and no logging by default. Auth and an audit trail follow the data and the misuse model.

Typical work

• Read-only discovery tools over your product data
• An MCP server card at /.well-known/mcp/server-card.json so agents can discover the server
• Registry publication so the server is findable in MCP directories

What decides the price

• How many tools the server exposes, and whether they read one system or several
• Whether your data is already reachable through an API, or the read path has to be built first
• Whether read-only is enough, which is the default here, or the server has to accept writes

Write tools are not included by default. A read-only server cannot modify the source through that interface. That is the property worth keeping. It does not settle exposure, bulk extraction or availability. Those are decided per tool.

Suited for teams that want agents to read product data through a supported interface rather than scraping HTML.