Your Next Customer Might Send an AI Agent

The visitor arrives with a job to finish

Consider a customer planning a stay. They want somewhere available on specific dates, a clear total price, and an explanation of what happens after they submit a request. A person can navigate several pages, open a calendar, and ask a question. An assistant acting for that person needs to obtain the same facts and recognize which next step the service supports.

A beautiful landing page helps establish trust with the customer. An agent also needs usable links, current information, and a way to distinguish a quotation from a confirmed reservation. If it cannot tell those states apart, a convincing answer can misrepresent what the business has actually done.

This travel scenario is illustrative. The concrete walkthrough below uses the Semitexa documentation site and read-only requests. It demonstrates discovery and representation, without pretending that we have measured bookings made by third-party agents.

The web is serving people and their software

In The Internet has a second audience, published September 30, 2026, Cloudflare describes agents as visitors acting on behalf of people, alongside search and training crawlers. Its account separates making services discoverable from letting agents use them and deciding how that use creates value. Those observations concern Cloudflare’s network and products; they do not establish how many customers arrive through agents on an individual Semitexa site.

For a site owner, the useful question is which customer task could cross that boundary today. Looking up opening hours requires reliable public content. Comparing plans requires unambiguous conditions. Changing a subscription requires a supported operation and the customer’s authority. Each task puts different demands on the application.

The agent may use a browser, fetch documents, or call an API. You do not need to predict a single winning client. Start by making the information and actions your service already offers coherent across the interfaces it exposes.

Google has made agent browsing an audit category

There is a concrete signal in the tools developers already use. The mobile PageSpeed Insights report for semitexa.com, captured October 2, 2026, includes a separate Agentic Browsing category. That Lighthouse 13.5.0 report displays 3/3 for the category: three passed audits and four marked not applicable. This is a recorded result for the homepage in that run.

Google’s June 22, 2026 developer announcement explains the broader purpose. Lighthouse’s agentic checks examine selected accessibility signals, layout stability, and WebMCP integration. Programmatic names help an agent identify controls; a stable layout reduces unexpected movement during interaction; WebMCP checks inspect declared tools and their schemas. Google described the category as informational and unbenchmarked at publication, and the report itself says it is still evolving.

Lighthouse also has a dedicated llms.txt audit. Google’s documentation treats the file as an emerging, optional convention: a missing file returning 404 is not applicable. An audit supporting the convention does not mean every agent consults it. The useful step remains to provide a clear index and verify the destinations it advertises.

For product teams, the addition is an important signal: suitability for agent interaction is becoming an explicit part of website quality tooling. The report gives us concrete properties to inspect, alongside our discovery documents and supported operations. Its result does not establish that an assistant can finish a booking, obtain permission, or report the final business state correctly. That still requires the complete journey check described below.

A useful map starts with actual destinations

On our local Semitexa site, GET /llms.txt returns Markdown guidance. It links to /sitemap.json, /robots.txt, and page entries. The generated fallback draws page entries from the tenant’s sitemap; a project can supply its own file to override it. Its bounded page list points to the full sitemap when the index is larger.

curl http://semitexa.test/llms.txt
curl http://semitexa.test/sitemap.json

These requests were checked locally for this article. Both returned HTTP 200; the sitemap response was JSON containing site, hints, pages, endpoints, and templates, as well as version and generation metadata. The pages included the documentation entry point and a JSON alternative for it.

An index reduces the work of finding a relevant destination. It remains advisory. An agent may never request llms.txt, and a sitemap entry does not prove that every advertised representation is complete. Follow the links and check the responses. A machine-friendly file cannot repair missing information on the page it describes.

Readable data still needs an understandable meaning

The next request in the local walkthrough is GET /docs?_format=json. It returns an application/json page document with five top-level keys: page, meta, content, slots, and links. The page identifies the documentation index, while its content includes document navigation with titles and hrefs.

curl 'http://semitexa.test/docs?_format=json'

That is an observed response from the installed application, not a promise about every possible Semitexa page. Check the representation for the routes you intend to serve. A JSON wrapper can describe a page while leaving the fact the customer needs buried in prose or absent altogether.

For the illustrative stay-planning task, a useful representation would distinguish dates, currency, occupancy assumptions, and whether availability is current. These are application responsibilities. A transport that emits JSON cannot invent the business meaning of a price or resolve disagreement between two published versions of a policy.

The human page and its machine representation should make the same claim. Keep the links between them inspectable, identify the authoritative source, and specify when a value must be checked again. Our multilingual publishing walkthrough explores a related problem: connected representations need an explicit update process.

Discovering a route is different from choosing an action

We also sent OPTIONS /blog. Its JSON document described a public endpoint, a GET method, and an optional topic input. The route contract makes those declared inputs inspectable without requiring a reader to infer them from a form.

curl -X OPTIONS http://semitexa.test/blog

This endpoint reads a catalog. Its contract supplies no booking operation, no payment permission, and no general instruction to try other verbs. A visitor should use the supported interface for the requested action, then handle its response according to that operation’s meaning.

An API description can help an integration client, but serving it does not automatically create a connected tool in every assistant. Client integration, credentials, and operation semantics still matter. Our companion article, Your API Changed. Did Your Docs Notice?, examines how to keep that description connected to the running service.

The application owns permission and the final state

A customer’s assistant is another client of your application. For a state-changing operation, the server needs to establish who is acting, which resource they may affect, and which conditions permit the action. Finding an endpoint does not establish any of those facts.

The response should let a client distinguish a submitted request from an accepted request and a confirmed outcome. If a booking needs the owner’s decision, a submission receipt cannot truthfully mean that the stay is confirmed. Our Solomiia case follows an embedded assistant through that distinction; an external integration needs the same business rule.

Retries introduce another question: did the first request act before its response was lost? The duplicate-delivery article explains why a repeated message needs an explicit identity and recovery policy. Those responsibilities become more visible when software is navigating the customer journey, but they already belong to a dependable application.

Measure whether a task can actually finish

Start with a narrow journey and record where it succeeds or stops. A file-exists check answers whether an index is present. A task check answers whether a client can use it to find a fact or complete an authorized operation.

For this article, the retained evidence covers local HTTP discovery, the documentation page representation, and one route description. We did not run an autonomous visiting agent or a state-changing customer task. The next useful test for a product would exercise its chosen task and include missing, stale, unauthorized, and retry cases.

Improve one customer journey before adding another interface

Choose a task your customers already ask for. Follow its public information, identify its source of truth, and check which operation genuinely advances it. Fix broken links, unclear conditions, or ambiguous receipts before expanding the integration surface.

Semitexa’s discovery documents and page representations provide concrete pieces to inspect. Application code supplies the business facts and decisions. A customer arriving through software should be able to obtain the same reliable answer and reach the same supported outcome as a customer navigating directly.