Part of the 20–26 October editorial series. Prepared and source-checked on 26 October 2026.
Start with the customer task, not the interface
A service website needs an additional agent interface when a real task benefits enough to justify building and maintaining it. First test whether the existing pages and forms let a customer, or an assistant acting for that customer, find the right information and reach a useful next step.
SEJ reported on 22 October that Sundar Pichai expects browsing and protocols to develop together, with protocols taking longer. That is a direction of travel, not an instruction to add an API to every consultancy site. The decision framework below is my proposed way to evaluate one capability before commissioning infrastructure.
Separate reading from making commitments
List the tasks people actually bring to the website. Reading an offer, checking a service area and collecting required enquiry fields are different from reserving a slot, accepting a price or submitting personal information. An interface decision should preserve those differences.
Choose one task with a clear success condition. For a fictional research consultancy, it might be finding the briefing options and returning the questions needed for a fit call. That is a better starting point than asking for an agent-ready website without deciding what an agent should be able to finish or who can authorise it.
Try the current browser route first
Have a reviewer follow the path from a realistic question to the offer and next step. Record missing facts, unclear labels, unavailable controls and contradictory instructions. A browser agent can be another test participant when its access and behaviour are appropriate, but preserve the human review of its result.
Some failures call for a clearer page or a more accessible form. Others reveal repeated structured work that an endpoint could simplify. Do not attribute every failed task to the absence of an API. A new interface serving the same ambiguous offer can reproduce the ambiguity at a different technical layer.
Define one capability before choosing a protocol
Write a short contract for the proposed capability: inputs, returned information, unavailable states, permitted actions and confirmation requirements. Keep it understandable without naming a framework. For the consultancy example, the output could be a service identifier, required context and an enquiry destination, without accepting a project on the owner's behalf.
Then ask what changes when the same information is requested through the page and through the proposed interface. They should agree about the offer and limitations. Design how changes will reach both surfaces and who resolves a mismatch. The additional maintenance work belongs in the decision, not in a later surprise.
Keep identification and permission separate
Google's user-triggered fetcher documentation describes Google-Agent as software that navigates and performs actions at a user's request. Recognising that software does not tell your business what this particular person has authorised it to do.
For an action that creates a commitment, define the confirmation step and the record you need to retain. Plan how the system handles repeated requests, incomplete information and withdrawal before completion. These are engineering recommendations for the proposed capability, not promises that any particular protocol supplies them automatically. Keep a human route available when the automated one cannot finish responsibly.
Use a pilot threshold and a fallback
Estimate the recurring task volume, avoidable manual work, implementation effort and support responsibility. Agree what would justify a pilot and what would stop it. During the pilot, compare completed tasks and corrections as well as response speed. A fast response containing the wrong commitment is not a successful service interaction.
If a browser improvement solves the problem, make that improvement. If repeated structured exchanges remain the obstacle, scope a small workflow integration and test it against the same acceptance conditions. The result should be a useful customer capability with an owner, rather than a protocol badge without a business purpose.
Link Map
Sources and editorial review
Sources checked on 26 October 2026. The publication date is assigned to the 20–26 October editorial series; this edition was prepared and reviewed on 26 October 2026. Proposed workflows and illustrative examples are JQ AI SYSTEMS editorial analysis, not reports of completed client tests.
- Search Engine Journal: Google CEO says agents will hit sites two ways (22 October 2026; Interview reporting by Matt G. Southern).
- Google: User-triggered fetchers (publication date not shown; checked 26 October 2026; Official crawling documentation; checked 26 October).