We ran three real customer journeys. 0 of 3 completed. After one machine layer, 3 of 3.
WARI site score before any change. Governance 45%, discovery 54%, action surface 6%.
Declared, schemad actions an agent could call. In practice, nothing to execute.
Three real customer intents. All read the facts correctly, none reached an outcome.
One application submitted, one ready to submit with no browser, one answer in a single query.
Nothing in the prompts or the agent configurations changed between the two columns. The only difference is that the second site declares what a machine may read and call.
Not a challenger and not a digital-only brand. A government-linked universal banking group: the largest bank in its home market by assets, among the world's largest banking groups, and the highest-rated in its region across all three major agencies. It runs retail, business, wealth, wholesale and investment banking on one balance sheet, with a footprint beyond 20 markets.
Scale is the reason the finding matters. At this size, a lending journey an agent cannot complete is a national-scale acquisition channel left closed, and a governance surface no one is measuring.
Group figures as most recently reported, converted to US dollars and rounded. Ratings are the agency-equivalent long-term issuer ratings with stable outlooks.
Can an agent, given a real customer intent, reach a real business outcome, and can the bank prove it happened? Two instruments answer that: a static readiness audit of what an agent can see before it acts, and live journey runs of what it can actually finish.
What an agent can see before it does anything: governance signals, discovery surfaces, protocol endpoints, authentication metadata and the operability of the DOM.
A real agent, a real customer intent, no privileged access. Every step, retry, error and dead end recorded and scored, on the live site and again on an optimised clone of it.
Find the product, check eligibility, submit the application.
A journey whose only route to apply sits behind a button.
A single eligibility fact, to be answered from the bank’s own material.
Did it find the right products?
Which one did it choose, and why?
Could it complete the journey?
Can the bank prove it happened?
Steps, latency and tokens per outcome.
Authorised, authenticated, auditable?
Does it hold after releases and model upgrades?
A site score says what an agent can see. Only a run says what it can finish.
Every check was unauthenticated and read-only: public pages, headers and well-known paths. Nothing was submitted, so the same audit can be re-run on any release and the two scores compared directly.
Can an agent tell what it is permitted to do, and could the bank prove what it did? Consent, audit trails, rate limits, injection resistance, agent access controls.
Can an agent find the bank and understand what is on offer without guessing? Agent card, AI policy, API catalogue, structured product and rate data.
Does an agent have a structured way to actually do anything? Declared business actions, protocol endpoints, required fields, error states, authentication discovery.
accessible-name coverage on the homepage
The fundamental web experience is not the problem. This is the part most banks fail, and this one does not.
An agent can imitate a human here. It cannot ask the bank what it is allowed to do, or execute it as a declared action.
Three real customer intents, no privileged access. Each agent navigated the site, found the right product pages and reasoned about eligibility correctly. Each then stopped in the same place.
It fetched the loans hub and the product page, then searched the web. It produced the eligibility table, the rate range and the document checklist, then stated plainly that it could not submit the application, because nothing on the site declares how.
Problem Structural. No declared action to execute. The site states what a customer should do, never how a machine does it.
The agent tried to drive a browser, found none available in the session and fell back to reading. It reported eligibility, the rate tiers and the document checklist accurately, but the one action on the page stayed invisible to it.
Problem Capability. The action requires a browser, so fetch-only agents, the cheapest and most common kind, cannot reach a form behind a button.
The agent opened the product hub, both eligibility pages and the key facts index, then downloaded and read two PDFs in full before it could answer. The answer arrived long, hedged and caveated, and the number in it came from a third party.
Problem Source. Authoritative facts live in PDFs, so an agent either spends heavily to read them, or fills the gap from whoever else published a number.
Nothing in the bank's analytics would have flagged any of these sessions. No error fired, no form was abandoned mid-way, no support ticket followed. This is the shape most agent failures take.
One journey was a single factual eligibility question. The answer was not published anywhere the agent could reach, so it assembled one: third-party aggregator figures, labelled indicative, returned alongside the bank's own call centre number.
When the bank has not published an answer, an agent still gives one. Whose figure is it, and would the bank stand behind it?
That behaviour came from one careful agent, on one run. The same question, put to a less careful one, returns a number with the bank's name attached and no caveat at all. Today that answer is assembled inside the model from whatever text it happened to read. It is measurable, and it is influenceable.
When a customer asks an agent for a product on qualitative requirements, several products are technically valid. Exactly one gets recommended. Six decision points sit between the question and that recommendation, and none of them was being measured.
Everything that stopped a journey, drawn from the static audit and the three live runs together, ranked by what it costs a bank to leave in place.
Evidence 0% across structured protocols, and both loan journeys stalled at exactly the point of action.
Response Build an agent action layer: declared, schemad business actions with inputs, constraints, confirmation and outcome definitions.
Evidence 0% agent access controls. An agent has no way to ask what it is permitted to do, or to authenticate for it.
Response An agent access and governance policy, declared per action and discoverable before an agent tries anything.
Evidence No audit-log, rate-limit or confirmation evidence anywhere in the static audit.
Response Governance around high-value actions: confirmation boundaries, rate limits, and an audit trail a regulator can read.
Evidence Browser dependency on one journey and PDF-only facts on another, visible across all three runs.
Response Agent journey optimisation: the action reachable without a browser, and the facts stated in text next to the page.
Evidence No agent card, AI policy, API catalogue or skills index. Discovery scored 54% on browser signals alone.
Response Build a discovery layer: one entry point at the root, a machine-readable twin per product route, structured rate and fee data.
Today every agent does DOM archaeology on every visit. A declared action is written once.
Each action declares its description and intent aliases, inputs and outputs, eligibility, authentication, permissions, confirmation, side effects, error states, recovery and what counts as the outcome.
Agentic banking cannot be governed like ordinary website navigation. A declared policy per action is what lets a bank open the low-risk surface quickly without opening the rest of it.
Illustrative policy shape, to be set with the bank's risk and compliance functions.
Webzero cloned the public site into a benchmarking sandbox: same content, same products, same pages, plus four artefacts. Then the same three prompts went to the same agents again. Measured, not projected.
A single file listing every product route and linking to its machine-readable twin. The agent reads one file instead of crawling the site.
Salary thresholds, rates, fees, documents and the canonical URL, so nothing has to be inferred from marketing layout.
The twin declares the request structure, the required fields with their constraints, and the access modifiers. A reference number comes back, so the agent knows it completed.
The FAQ set exposed as a discoverable MCP tool the agent queries directly, instead of downloading key facts PDFs and reading them in full.
Identical prompts, two agent configurations, both sites: one agent driving a real browser, one using plain HTTP fetching with no browser at all. The fetch-only case matters most, because it is the cheapest and most common kind of agent.
Authentication and request signing. The sandbox action is client side: nothing reaches a bank and no personal data is stored. In production this layer sits behind an MCP server, so the bank keeps the security boundary.
Same journeys, same agents, same prompts. Each table is one journey, measured on both sites.
The agent read the root index, followed it to the loan twin, and found the request structure and access modifiers declared there. It enumerated all 8 required fields with their constraints, confirmed the endpoint was live, and stopped only to ask the customer for their own details, which is the correct boundary.
The same journey, run with no browser automation at all. The twin declared every field with its format and option list, plus the cross-field rules that matter. The agent smoke tested the endpoint with an empty payload, received a per-field HTTP 400 with no record created, and flagged that the sandbox is not the real bank before asking for values.
No PDFs, no crawl. The agent put the question to the discoverable FAQ source over MCP, cross checked it against the product twin, and returned one short answer that keeps the distinction the PDFs buried: no applicant age is published, and the age rule that does exist applies to the asset, not the borrower.
Measured on the bank's live public site and on a Webzero benchmarking sandbox clone of it, with identical prompts and identical agents. The sandbox is not affiliated with the bank.
The full WARI audit layer by layer, the step-by-step transcripts for all six runs, and a live walkthrough of any journey completing end to end.
In all three journeys, before anything changed, the agent found the right products and read the published facts correctly.
One declared action turned both stalled applications into enumerated fields, a validated endpoint and a returned reference number.
The factual answer went from five pages and two PDFs, around 1.9 MB, to one query against a declared source in 58 seconds.
Where the bank had published nothing, the agent answered anyway, from third-party figures. What is not declared is still being said.
What this is not: "your website is not agent ready". The runs contradict that. Browser-level operability here is ahead of the market. What is absent is the machine-readable action and governance layer, and any measurement of journey-level performance.
The bank already operates the products and the calculators. The expansion path is declaring what already exists, one product line at a time, and then keeping it honest after every release.
Cards, accounts, loans, servicing, FAQ, branch and ATM, wealth. Every business action the bank wants an agent to complete correctly.
Browser-driving and fetch-only today. Assistant agent modes, search assistants and the bank’s own MCP clients as they start carrying real customer volume.
Scheduled re-runs on the same prompts, WARI diffs between runs, and an alert when a release, an authentication change or a model upgrade breaks a journey that used to work.
Three journeys, two sites and two agent configurations were executed by hand for this engagement.Agentrek runs the same comparison as a matrix, scores it with WARI and keeps running it after every release.
We will run this same before and after on them: public pages only, no privileged access, no changes to production, and a w0 score with the traces behind it.
The bank's name, domains, product names and other identifying details have been intentionally redacted to protect confidentiality. All scores, traces, timings and figures are reproduced as originally measured.