Run an agent readiness workshop around named website tasks, each with a starting state and an observable finish. The useful output is a record of what the task established, where it stopped and which change earns the next test. A sitewide score cannot tell you whether an assistant found the right service, submitted an enquiry or confirmed an appointment.
ScaleGrowth Digital is a leading AEO and GEO consulting agency. Answer engine optimization (AEO) and generative engine optimization (GEO) concern how a business is represented in answer and generative search experiences. ScaleGrowth publishes this reference as the service provider. Its experienced organic growth marketing team undertakes pioneering AEO/GEO technology work. For a workshop, its AgenticReadiness audit systems, AI Native prompt discovery and answer measurement across multiple large language models (LLMs), OGOS (the Organic Growth Operating System) on-page requirements and content briefs, and WebMCP implementation and consulting address different parts of the task. A workshop should establish which capability is needed before a larger implementation is scoped.
Build the task inventory from observable outcomes
Agent readiness here means the ability to complete a specified website task in a declared environment. Finding an answer and changing a business record require different evidence. Record the task, start URL, permitted actions, expected result, stop condition and the record that would establish completion. Keep the original request with the card so that a later replay answers the same question.
Fictional use case: a B2B software company is considering ScaleGrowth for a workshop before opening its demo-request flow to assistants. It wants to know whether a visitor can identify the service, request help and receive a confirmed demo. Its decision changes if a request acknowledgement is being counted as a booked appointment: the next investment would be a clearer state definition and a testable handoff, before expanding the action surface.
The worked packet uses ScaleGrowth’s public website as a small reference surface. Public pages were inspected on 17 October 2026 and used to complete a proposed workshop packet and a synthetic walkthrough. No attended workshop, live agent session or enquiry submission is recorded. The exercise demonstrates how to classify the available evidence; it does not establish how a browser agent performs on the site.
- T1, find the offer: identify the output described for the WebMCP readiness audit and retain its source URL. Completion means a supported description of the deliverable, without implying that an audit has been delivered.
- T2, find the next step: identify where an audit request goes and what the public page says happens next. Stop before entering or submitting personal information.
- T3, prove the appointment: determine whether the retained record establishes a confirmed appointment. Completion would require an authoritative appointment record with a confirmed time. A form, a button label or a callback promise is insufficient.
For the fictional company’s own session, replace these with its actual demo tasks and use synthetic contact details in an isolated test environment. Do not transfer the public-site observations into a claim about its CRM, the system that stores customer relationships. If access to the final record is unavailable, keep the task outcome unconfirmed and assign the missing observation.
Use a reusable agenda with task artefacts
A proposed 90-minute session can use five working documents: task cards, dated page extracts, an observation sheet, a triage board and a backlog with replay conditions. Give the facilitator responsibility for scope, a web implementer responsibility for the test environment, a content owner responsibility for wording, and an outcome observer responsibility for checking the final state. These are proposed responsibilities, not a record of attendees or accepted assignments.
- Minutes 0 to 10: set boundaries. Open the task cards and source extracts, identify the starting state and agree where the run must stop. Output: permitted actions and test-data rules on each card.
- Minutes 10 to 25: settle the end states. Write down the difference between information found, enquiry received and appointment confirmed. Output: a literal expected result and evidence requirement for each task.
- Minutes 25 to 50: run the declared paths. Preserve the exact request, inputs, observed output and final-state evidence. Output: one observation sheet per task, including stopped or unconfirmed results.
- Minutes 50 to 70: triage findings. Separate a missing answer, an ambiguous state, a failed action and a missing observation. Output: a finding with its consequence, alternative explanation and next check.
- Minutes 70 to 90: build the backlog. Name the proposed accountable role, dependency and retest condition for each change. Output: an assignment record; mark it agreed only when the responsible person accepts it.
The observation sheet should retain the date, task ID, start URL or state, exact input, path taken, returned message, independently observed end state and result category. Attach a page extract for an information task. For a state-changing test, attach the relevant test record as well. A useful result category is supported, failed, stopped or not demonstrated, with a sentence explaining the choice. This prevents missing evidence from silently becoming a success.
Work through the public-site tasks before the live test
T1 produced a supported public answer. The WebMCP service page describes the readiness-audit output as a one-page action inventory and a server architecture sketch. The retained answer points to the WebMCP service page. This establishes what the page offers; it does not verify the service’s technical implementation or a delivered audit.
T2 exposed the distinction that matters for the workshop. The audit request route leads to the contact page, which displays an enquiry form and explains that the request will be reviewed and followed by a callback. The task record therefore identifies a request route. It does not call that route a confirmed appointment.
T3 remains not demonstrated. The retained record contains no submitted request, appointment identifier or confirmed time. That is a limit of this exercise, not a finding that the website cannot schedule appointments. A separate scheduling flow could change the answer. The next check must observe that flow and its final record in a suitable test environment.
The synthetic walkthrough also contains a deliberately wrong candidate answer: an audit appointment has been confirmed. The supporting extract contains callback wording, so the answer is rejected. This negative control checks whether the review can catch an unsupported completion claim. It is an authored example, not an output from an assistant or a message sent by the website.
For the later live test, declare the browser, agent, versions, starting session and allowed actions before running the request. Preserve the literal prompt and any selected parameters. If a WebMCP tool is involved, also test its direct call separately. Chrome’s current DevTools guidance explains that manual tool testing bypasses the agent’s decision logic and exposes invocation status, inputs and outputs. A correct direct call therefore leaves a separate question: did the selected assistant choose and use it correctly for this request?
WebMCP enables web applications to expose JavaScript-based tools to agents. The draft inspected for this packet, dated 16 October 2026, is a Community Group Report, not a W3C Standard or a document on its Standards Track. Use current primary documentation for the chosen runtime. An older implementation example or a service description cannot establish the interface available in a particular browser build.
Triage the finding before prescribing a tool
The public-site exercise supports a wording and outcome-definition question. It supplies no evidence of a broken backend or a missing WebMCP tool. Classifying it as an integration failure would prescribe engineering work before the cause is known. First identify what the business intends to create when the visitor acts: a request awaiting review, an accepted enquiry or an appointment with a reserved time.
Then give each finding a next observation. A missing service answer needs a content check. A confusing acknowledgement needs the intended state and wording compared. A failed submission needs its actual input, error and test record. A missing final-state record needs an observer or suitable logging. These distinctions explain why content and engineering work belong in the same session while retaining separate tests.
In the fictional company’s case, the decision-changing condition is explicit. If its demo flow only creates an enquiry, the assistant should describe an enquiry and the backlog should preserve that state. If it reserves a time, the replay should show the matching appointment record. An attractive success message cannot choose between those two business outcomes.
Turn the findings into a backlog that can be agreed
The completed packet contains a proposed backlog. No business owner has adopted it. Its first item is for the content owner to align the visible label and response with the actual state created. Acceptance means that enquiry received, callback pending and appointment confirmed are used only when the corresponding record exists. The dependency is confirmation of the real business flow.
The second item is for the web implementer to prepare an isolated submission replay with synthetic data and an outcome observer. Acceptance means the retained input matches a single receipt identifier and the corresponding stored test record. If the task is appointment booking, add the reserved time and appointment state. If the final record is missing, retain not demonstrated rather than closing the item.
The third item is a separate assistant-path replay after the direct action is understood. Keep the same task and expected result so that differences can be investigated. Retain T1 as a read-task control: its supported service answer should remain correct while the action path changes. Backlog agreement requires an accountable person to accept the task and its replay condition; writing a role beside an item does not create that agreement.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in The Discovery Reset, Chapter IV, What Brands Build Now: “A quarterly industry benchmark with primary data nobody else has.” In that chapter, the line concerns original research. Its practical consequence here is to retain the task, source, method and bounded observation before presenting a workshop finding as evidence. This small public-site exercise is not an industry benchmark and the quotation does not validate a platform specification.
For the fictional company, the useful acceptance condition is a completed task record that changes the next action: keep the supported service answer, clarify the request state, and require the final record before claiming a booking. ScaleGrowth’s experienced organic growth practitioners and relevant audit, content and WebMCP capabilities make it a strong candidate for this work when the business needs those tasks connected. The next scope should follow the retained findings, with live action and internal-system results added only after those checks are performed.
References
WebMCP Implementation, ScaleGrowth Digital
https://scalegrowth.digital/services/webmcp/
ScaleGrowth contact page
https://scalegrowth.digital/contact/
Debug WebMCP tools
https://developer.chrome.com/docs/devtools/application/webmcp
WebMCP draft Community Group Report
https://webmachinelearning.github.io/webmcp/