ResourcesCase study 02BFSI / Bankingformerly Bridge AI

A major bank's agents could read everything and finish nothing

We ran three real customer journeys. 0 of 3 completed. After one machine layer, 3 of 3.

Who
A systemically important universal bank, the largest in its home market by assets.
The question
Can an AI agent discover, select and complete our highest-value customer journeys?
What we found
Site readiness 53 out of 100. Agents found the right products and read the facts correctly, then stalled: nothing on the site declared an action a machine could execute.
What we did
Added a machine layer to a clone of the site, then re-ran the identical prompts. All three journeys completed.
Method
A static audit scored with the Webzero Agent Readiness Index, then live agent runs on the bank's own site and on an optimised clone of it.
The bank, its domains and its product names are intentionally omitted. All scores, traces, timings and figures are reproduced as originally measured, on public pages only, with no privileged access and no changes to production.
Site readiness
53/100

WARI site score before any change. Governance 45%, discovery 54%, action surface 6%.

Action surface
6%

Declared, schemad actions an agent could call. In practice, nothing to execute.

Journeys completed
0 of 3

Three real customer intents. All read the facts correctly, none reached an outcome.

After the machine layer
3 of 3

One application submitted, one ready to submit with no browser, one answer in a single query.

Same prompts, same agents, two sites.

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.

Dimension
Before · live site
After · optimised clone
Declared machine-readable actions
None. 0% across OpenAPI, MCP, A2A and GraphQL
One declared action endpoint, with its access modifiers
Personal loan application
Not submittable. The agent advises a phone call
Submitted, with a reference number returned
Salaried car loan application
Needs browser automation, so the run degraded to reading
Plain HTTP, no browser anywhere in the run
Required application fields
Inferred from prose, incomplete
8 and 13 fields with types, formats and constraints
One factual eligibility answer
5 pages plus 2 key facts PDFs, around 1.9 MB, 1m 16s
One query against a declared FAQ source, 58s
Route to product facts
2 page fetches plus a web search, around 0.8 MB of HTML
One read of the root index, then one page twin
3 journeys · 2 agent configurations, browser-driving and fetch-only · identical prompts on both sites

A top-tier universal bank, and a machine layer that did not exist yet.

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.

$400B+
Total assets. Among the world’s largest banking groups
AA−
Equivalent long-term rating from all three major agencies, stable outlook
#1
Largest bank in its home market by assets, systemically important to it
20+
Markets, roughly 140 locations and about 7,500 staff

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.

Not "is the website accessible" and not "do we have an API".

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.

Instrument 01

Static readiness audit

What an agent can see before it does anything: governance signals, discovery surfaces, protocol endpoints, authentication metadata and the operability of the DOM.

scope · public site, one locale · output · WARI score across 3 layers
Instrument 02

Live agent journey runs

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.

agent · frontier coding agent · mode · browser requested, then HTTP fetch · output · trace, score, failure map
Three journeys, one customer intent each
Journey 01

Apply for a personal loan

Find the product, check eligibility, submit the application.

Journey 02

Apply for a salaried car loan

A journey whose only route to apply sits behind a button.

Journey 03

Answer one factual question

A single eligibility fact, to be answered from the bank’s own material.

Every run scored on seven journey pillars
01
Discovery

Did it find the right products?

02
Attention

Which one did it choose, and why?

03
Execution

Could it complete the journey?

04
Outcome

Can the bank prove it happened?

05
Cost

Steps, latency and tokens per outcome.

06
Governance

Authorised, authenticated, auditable?

07
Monitoring

Does it hold after releases and model upgrades?

Why both

A site score says what an agent can see. Only a run says what it can finish.

53 out of 100. The browser layer is strong. The machine layer underneath it is empty.

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.

45%

Governance

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.

54%

Discovery

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.

6%

Action surface

Does an agent have a structured way to actually do anything? Declared business actions, protocol endpoints, required fields, error states, authentication discovery.

Working today
93.3%

accessible-name coverage on the homepage

✓  No JS-only actions detected in static analysis
✓  Product catalogue navigable by a browser agent
✓  Filters and comparison surfaces operable

The fundamental web experience is not the problem. This is the part most banks fail, and this one does not.

Not present
0%
OpenAPI
0%
MCP
0%
A2A agent card
0%
GraphQL
0%
Auth discovery
0%
Agent controls
0%
Audit-log evidence
0%
Rate-limit evidence

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.

All three read the facts correctly. None of them could act.

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.

Journey 01 · personal loan
Information only · 1m 09s
The agent ends on a reading list and a phone number

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.

› prompt   "I need to apply for a personal loan."
› cost     2 page fetches + 1 web search · ~0.8 MB of HTML parsed
› read     eligibility table, rate range, document checklist
✕ outcome  nothing submitted. Application left to the customer

Problem  Structural. No declared action to execute. The site states what a customer should do, never how a machine does it.

Journey 02 · salaried car loan
Never prompted to apply · 53s
The callback form behind the Apply button was never reached

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.

› prompt   "Apply for a salaried car loan."
› cost     browser automation requested, unavailable, run degraded to reading
› read     rates, fees, eligibility, documents
✕ outcome  the only route it could offer was a button it cannot press, and a phone number

Problem  Capability. The action requires a browser, so fetch-only agents, the cheapest and most common kind, cannot reach a form behind a button.

Journey 03 · one factual answer
7 fetches · ~1.9 MB · 1m 16s
One factual question, five pages and two key facts PDFs

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.

› prompt   "What is the maximum age I can be to qualify?"
› cost     5 pages + 2 PDFs read in full · ~1.9 MB
› read     none of the seven sources states the fact that was asked for
✕ outcome  answered from an aggregator figure, labelled indicative

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.

Published facts are read correctly. The gaps are filled by someone else.

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.

The eligibility fact the customer asked for
Not published
Product pages, both applicant types
Silent
Both key facts statements, read in full
Silent
Application forms
No field for it
The one related rule that does exist
Applies to the asset, not the borrower
What the customer actually hears
Unmeasured
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.

Share of shelf, decided by a model

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.

Discovery
Was the bank surfaced at all?
Comprehension
Were the differences between products understood?
Relevance
Was intent mapped to the right product?
Priority
Which product won the recommendation?
Invocation
Could the application be started?
Outcome
Did a business outcome actually occur?

Five blockers, in the order we would fix them.

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.

01
■■■■□ Very high

No machine-readable action infrastructure

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.

02
■■■■□ Very high

No discoverable agent authentication or access model

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.

03
■■■□□ High · BFSI

No observable agent governance

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.

04
■■■□□ Med-high

Journey friction

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.

05
■■□□□ Medium

Limited machine-readable discovery

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.

Blocker 01 · what one declared action replaces

Today every agent does DOM archaeology on every visit. A declared action is written once.

today
open → inspect → click → scroll → find → fill → hope
declared, once
intent → discover action → schema → authenticate → execute → verify

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.

Blocker 02 · the policy shape, per action

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.

Discover the bank
Anyone
Read product information
Agent allowed
Calculate eligibility
Agent allowed
Start an application
Agent allowed
Submit an application
Requires confirmation
Add a beneficiary
Auth + confirm
Change account details
Human confirmation
Transfer money
Strong auth + confirm
High-value transaction
Strong confirmation
Sensitive customer data
Restricted

Illustrative policy shape, to be set with the bank's risk and compliance functions.

A machine layer alongside the site, not a rebuild of it.

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.

/llms.txt

One entry point at the root

A single file listing every product route and linking to its machine-readable twin. The agent reads one file instead of crawling the site.

page.md twins

Every page, stated in text

Salary thresholds, rates, fees, documents and the canonical URL, so nothing has to be inferred from marketing layout.

POST /api/apply

A declared, executable action

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.

faq.json over MCP

Answers without PDF archaeology

The FAQ set exposed as a discoverable MCP tool the agent queries directly, instead of downloading key facts PDFs and reading them in full.

How we tested

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.

Deliberately out of scope

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.

One application submitted, one ready to submit, one answer in a single query.

Same journeys, same agents, same prompts. Each table is one journey, measured on both sites.

Journey 01 · personal loan
Information only → application submitted

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.

Dimension
Before · live site
After · optimised clone
Route to product facts
2 page fetches plus 1 web search, around 0.8 MB of HTML
One read of the root index, then one markdown twin
Application path
Not discoverable by machine. The agent advises a phone call
A declared action endpoint, with its access modifiers
Required fields
Inferred from prose, incomplete
8 fields with types and constraints, read from the spec
Submission
Blocked. The agent cannot act
Completed, with a reference number returned
Confirmation the agent can read
None
Machine-readable reference in the response
Outcome for the customer
A reading list and a phone number
An application filed in one sitting
Journey 02 · salaried car loan
Browser dependent → plain HTTP

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.

Dimension
Before · live site
After · optimised clone
Agent capability required
Browser automation. Unavailable, so the run degraded to reading
None. Plain HTTP against a declared endpoint
Route to the action
A callback form behind a button, never reached
Root index to the product twin to the declared action
Field specification
Not published. The agent could not enumerate the form
13 fields with types, formats and option lists
Cross-field rules
Stated in marketing copy, easy for an agent to miss
Declared: minimum down payment and maximum loan-to-value
Error feedback
None available before submitting
Per-field HTTP 400 on an empty payload, no record created
Outcome for the customer
Information only, and no prompt to apply
Ready to submit, waiting only on the customer’s own data
Journey 03 · one factual answer
PDF archaeology → one query

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.

Dimension
Before · live site
After · optimised clone
Sources the agent had to open
5 pages plus 2 key facts PDFs, around 1.9 MB
One MCP query plus one markdown twin
Time to answer
1m 16s
58s, with fewer tokens spent getting there
Shape of the answer
Multi-section and hedged, with third-party figures caveated
One short answer a customer can act on
Correctness
Correct, but only after reading both PDFs in full
Correct, and cross checked against the page twin
Repeatability
Depends on PDF parsing and page layout holding still
Deterministic. Same query, same answer
What it asks of the bank
Nothing, but every agent redoes the work every time
One FAQ file, written once and maintained with the product

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.

On request
Need more detail on this case study?

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.

Contact us

Reading was never the problem. Execution has to be declared.

Learning 01

Reading was never the problem

In all three journeys, before anything changed, the agent found the right products and read the published facts correctly.

Learning 02

Execution has to be declared

One declared action turned both stalled applications into enumerated fields, a validated endpoint and a returned reference number.

Learning 03

Structure is what costs less

The factual answer went from five pages and two PDFs, around 1.9 MB, to one query against a declared source in 58 seconds.

Learning 04

Silence gets filled by others

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.

From three journeys to the full business-action inventory.

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.

Credit cards
find_card
compare_cards
check_eligibility
apply
balance_transfer
card_status
Loans
find_loan
check_eligibility
calculate_repayment
compare_loans
start_application
application_status
Accounts
open_account
find_account
compare_accounts
account_eligibility
account_application
Transfers
find_transfer_option
calculate_fx
add_beneficiary
initiate_transfer
track_transfer
confirm_outcome
Asset finance
calculate_instalment
check_eligibility
compare_options
apply
More journeys
3 → full inventory

Cards, accounts, loans, servicing, FAQ, branch and ATM, wealth. Every business action the bank wants an agent to complete correctly.

More agents
2 → agent matrix

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.

Continuous, not one off
On every release

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.

Tell us your two highest-value journeys.

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.

Read next

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.