Nobody at the Keyboard: Designing UK Services for Delegated Authority

For two decades, UK product teams have organised their work around one quiet assumption: that a person sits in front of the screen, reading it. Discovery research, usability testing, error states, consent banners — each of these presumes a human present at the moment of action, able to see what is happening and to intervene. That assumption is now expiring, and it is expiring faster than most roadmaps allow for.

Agentic tools are already booking appointments, comparing and switching tariffs, filing forms and completing purchases on behalf of UK users. Some are general-purpose assistants; others are narrow, purpose-built services acting under open banking connections or delegated credentials. In either case the practical consequence is the same. The party performing the transaction is no longer the party looking at the interface. Design work that assumes otherwise will produce services that are legible to a human who is not there, and auditable by nobody at all.

The screen is no longer where the service happens

Much of what we call interface design is really the negotiation of intent: a button that makes consequences clear, a summary that confirms what is about to occur, a warning that interrupts a mistake. When an agent acts, that negotiation moves elsewhere — into a mandate agreed in advance, and into a record examined afterwards. The screen does not disappear. It changes job. It becomes an audit surface rather than a control surface.

Teams that grasp this early tend to reorganise around three artefacts: the mandate, the event log and the receipt. The first sets out what the agent may do. The second records what it did. The third explains the outcome to a person who was not present. None of these is usually owned by a single discipline today, which is precisely why they tend to be built badly.

A mandate needs edges, not adjectives

Consent language inherited from web flows is poorly suited to delegation. A checkbox granting access to an account tells an agent almost nothing about scope, and a person almost nothing about risk. Open banking has already taught the UK market how much friction sits inside that gap: reauthentication cycles, strong customer authentication, and a supervisory expectation that consent is specific, informed and withdrawable.

An agent mandate should be concrete on at least five points. What may be done — pay, book, cancel, submit. Up to what value, or under what threshold. For how long, and whether it renews. With which counterparties, named rather than categorised. And on what evidence: which facts the agent may rely on when deciding. A mandate without those edges is not a delegation. It is a blank cheque with a friendly label.

Revocation has to be tested, not announced

Almost every team can demonstrate a revoke button. Fewer can demonstrate what happens afterwards. Delegation creates chains — a principal, an agent, occasionally a sub-agent or a scheduled job already queued — and revocation must propagate along the whole of it. Standing instructions, cached credentials, pending transactions and future bookings each represent a way for authority to outlive the decision to withdraw it.

The practical test is straightforward and rarely performed: revoke, then observe. What arrives in the inbox over the following seventy-two hours? Which scheduled actions still execute? Which third parties still hold a derived token? Until a team can answer those questions with evidence, revocation is a claim rather than a control.

Receipts a person can actually read

The record produced after an agent acts is often written for engineers: timestamps, correlation identifiers, status codes. Useful, but insufficient. The person on whose behalf the action occurred needs a different document — one that states what happened, under whose authority, at what cost, what changed as a result, and how to undo it if the outcome was wrong.

This is not a call for verbosity. A good receipt is short, structured and consistent, and it is paired with a machine-readable event for the systems that need one. The design question is who the receipt is for. If the honest answer is the support team, the receipt is not finished.

Liability arrives before the policy does

UK law already gestures at these questions without fully settling them. Article 22 of the UK GDPR constrains significant decisions taken solely by automated means. The Consumer Duty asks firms to evidence good outcomes. The Digital Markets, Competition and Consumers Act sharpens expectations around unfair commercial practices, including some uses of interface design. Consumer contract law determines who is bound when a transaction is made by something other than the account holder's own hand.

Against that backdrop, the most useful thing a product team can do is make the chain of authority provable. Who authorised what, when, with which limits, and what evidence did the agent rely on? A service that can produce that chain can argue its case. One that cannot will find the argument made for it.

Patterns worth adopting now

A handful of practices are emerging as durable. Delegated identity should be distinct from the account holder's own credentials, with its own lifecycle and its own audit trail. Actions above a value should require fresh confirmation through a channel the person controls. High-consequence operations benefit from a reversible window before they settle. Accounts should offer a delegation centre — a single place to see what is acting, under what limits, and to stop it. And agent-facing documentation, machine-readable terms above all, is becoming as much a part of the service as the help pages.

Each of these is modest in isolation. Together they shift the design brief from a person at a screen to a chain of authority that can be inspected later. For UK teams building on open banking, One Login and the expectations set by the DMCC Act, that shift is not speculative. It is the next interface, and nobody will be sitting in front of it.