How this site actually works

Walk-through 1: the contact form

What happens when you press send on the contact form

Your enquiry has to survive things going wrong: a network drop, a service being down, a duplicate submission. Here is what happens after you press send, and what happens when a step fails.

1. 1. Your browser validates and throttles

   The form checks the address looks like an address before anything is sent, and a short throttle stops a double-click becoming two enquiries.

   When the throttle stops a second press it writes a message into a polite live region, so a screen-reader user is told rather than left with an apparently dead button. The throttle exists to stop double-clicks, not to stop people.

2. 2. The API rate-limits and runs the spam checks

   The request reaches the API, which applies its own rate limit and spam checks rather than trusting the browser to have done it.

   Client-side checks are a convenience for you, never a control. Anything that actually matters is enforced again here, because the browser is not a trusted participant.

3. 3. The enquiry is stored durably, all or nothing

   The enquiry, any attachments and the instruction to deliver it are all written down before you are told anything succeeded.

   Storing the enquiry and notifying about it are separate steps on purpose. Reaching the success response means the enquiry, every attachment and the queue message all durably exist. If the email cannot be sent afterwards, the enquiry is already safe and delivery is retried. The alternative, sending first and storing after, loses enquiries precisely when the system is already unhealthy.

4. 4. A separate worker sends the notification

   Delivery happens outside your request, so a slow mail provider does not become a slow form.

   A delivery failure is classified as transient or permanent. Transient failures are retried by the queue. A message that exhausts its retries is dead-lettered and recorded rather than silently dropped, because an enquiry nobody knows was lost is worse than one that failed loudly.

5. 5. Attribution is recorded outside the request

   Where the enquiry came from is recorded separately from the enquiry itself.

   Attribution genuinely runs outside the request and cannot fail an enquiry. A lost analytics event is an inconvenience; a lost enquiry is a lost client. Those two are not allowed to share a failure path.

6. 6. You see a confirmation

   The confirmation appears once the enquiry is stored.

   The confirmation reflects what actually happened. It does not say "we will be in touch" before anything has been stored, because a reassuring message about work that did not happen is the one outcome worse than an error.

Walk-through 2: what an AI agent sees

What an AI agent sees when it arrives

Software is starting to visit websites on people's behalf. Most sites make it guess. This one hands it a set of tools and tells it what they do.

The tools

pagetech_get_availability

Returns dates that can actually be booked. Past dates are never returned, because they cannot be booked, and returning them would be technically honest and practically useless.

pagetech_get_pricing

Returns the published rates, from the same source file the pricing pages read, so an agent and a person are told the same number.

pagetech_list_services

Projected from the service data the page already publishes, rather than a second list that would drift the moment either changed.

pagetech_search_faq

Searches the questions and answers on the current page, read from that page's own structured data.

pagetech_prepare_contact_enquiry

Fills the contact form and stops. It cannot submit. An agent should be able to prepare an action for a person, not take it on their behalf, and that boundary is worth building in rather than hoping for.

Whether your browser can call these needs JavaScript to check. The five tools listed above are what an agent-capable browser would find.

The tool list on the full write-up is checked at build time, not read from the browser: the API is write-only, so a page cannot read back what it registered. Publishing a "live" list would be a claim the page cannot support, so a mismatch between that list and the registered tools fails the build instead. The full write-up.