The Second Visitor: Designing UK Services for Software That Acts

Most UK product teams still design as though the person at the screen is the person doing the task. That assumption is becoming unstable. Increasingly, the visitor is software: an assistant comparing rail fares, a household agent renewing a parking permit, a finance tool checking whether a direct debit can be moved. The human remains accountable, but they are no longer the one clicking through every step. The interface has acquired a second visitor, and it does not see the page the way we do.

The visitor that never sees the page

For two decades, digital service design has concentrated on the rendered surface: layout, copy, form validation, progress feedback. These remain important. But an agent does not experience a service as a sequence of screens. It experiences it as a set of machine-readable claims: what is on offer, at what price, under which conditions, with what permissions, and what happens when something goes wrong. If those claims exist only as prose or visual hierarchy, the agent must guess, scrape or abandon the task.

This is not a niche concern. UK rail retail already involves multiple systems comparing itineraries, split tickets and retailer terms. Council services increasingly expose eligibility rules for permits, waste collections and housing repairs. Open banking has made permissioned data sharing a routine part of household finance. In each case, the service is already partly machine-facing. The design question is whether that machine-facing layer is deliberate or accidental.

Offers need structure, not scraped prose

A machine-readable service layer begins with structured offers. That means publishing the essential attributes of a service in a form that can be compared and acted upon: price, availability, eligibility, duration, cancellation terms and the identity of the provider. For rail retail, this is more than an itinerary feed. It is a clear statement of what the fare permits, what restrictions apply and how changes are handled. For council services, it is an explicit eligibility model rather than a PDF whose meaning has to be inferred.

Structured offers are not merely a technical convenience. They are a design decision about legibility. When a service publishes its terms in a consistent schema, it reduces the space for an agent to misrepresent them to the human on whose behalf it acts. It also makes comparison fairer, because the agent is not rewarded for interpreting ambiguity in the most favourable way. The UK has useful precedents here: Open Banking succeeded in part because it standardised consent and data fields, not because every bank redesigned its app in the same way.

Consent that travels with the task

The hardest part of designing for agents is not data exchange. It is authority. A human may be willing for an assistant to find a cheaper energy tariff, but not to switch supplier without confirmation. They may permit an agent to check council tax balance, but not to make a payment. These distinctions must be expressible in the service layer, not left to the agent's discretion.

This suggests consent boundaries that travel with the task: scoped permissions, explicit confirmation points and a clear record of what was authorised. Open banking's consent dashboards are a useful model because they separate access from action and make revocation visible. Council services could adopt similar patterns for delegated applications, allowing a carer or household agent to prepare a request without submitting it. Rail retailers could distinguish between holding a fare, completing a booking and modifying a journey after purchase. Each boundary should be a designed state, not an afterthought.

Actions that leave a trace

If software acts on a person's behalf, the resulting action must be auditable. That means a record of what was requested, what was returned, which terms were accepted and which party confirmed the final step. Auditability is not only a compliance requirement. It is a trust mechanism for the human who delegated the task. When a booking is made or a permit is renewed, the person should be able to see the path taken without reading a raw log file.

UK product teams already understand this in payments, where authorisation and settlement leave distinct traces. The same discipline should apply to service actions that carry less financial weight but more administrative consequence: a school application, a waste collection request, a parking suspension. An auditable action is one that can be explained after the fact in plain language, not merely reconstructed by engineers.

Failure states for software intermediaries

Agents fail differently from people. They may hit a rate limit, encounter an ambiguous eligibility rule, receive a partial response or attempt an action outside their permission. If the service returns a generic error page, the agent has little choice but to retry, escalate or give up. None of these is a designed outcome.

Legible failure states are therefore part of the machine-readable layer. They should state what failed, whether the failure is temporary, what the agent is permitted to do next and when a human decision is required. This is the machine equivalent of good error copy: specific, actionable and honest about uncertainty. For council services, a failure state might explain that eligibility could not be confirmed because a document was missing. For rail retail, it might distinguish between a fare no longer available and a payment that was declined. The distinction matters because the agent's next step depends on it.

A layer, not a surrender

Designing for agents does not mean designing for machines instead of people. It means recognising that the service surface now extends beyond the screen. The human still needs clear confirmation, understandable terms and a route back. The agent needs structure, boundaries and honest failure signals. A well-designed machine-readable layer serves both by making the service's claims explicit rather than implicit.

For UK product teams, the practical starting point is an audit: which parts of the service are already being accessed by software, and which of those accesses rely on scraping or assumption? From there, teams can define a small set of structured offers, consent scopes and action records. The aim is not to build a separate agent product. It is to make the existing service legible to a second kind of visitor without handing over the oversight that keeps the first one in control.