The project at a glance
Role
Solo project · criteria, test design, judgement
Year
October 2026
Industry
Banking · Regulated products
Scope
Accessibility (WCAG 2.2 AA) · Heuristics · Orchestration
Status
v0.8.0 validated · public repository
The problem
In banking, a design flaw can move money.
A usability or accessibility failure in a banking flow is not cosmetic. It can make someone authorise a transfer they did not mean to make, or stop a screen-reader user from managing their own account.
Yet design audits usually depend on who runs them. Two reviewers, two different verdicts. And AI tools that "review designs" tend to sound confident about everything, including what they never checked.
My goal was to turn my own audit criteria into agents that anyone on a team can run, producing results I can defend: traceable, repeatable, and explicit about what is still unverified.
My role
I wrote the criteria. The AI applies them, and I judge the result.
I defined the severity scale, the approval rules, the 14 red lines and the regulated-product lenses. I wrote the answer keys before any test, designed the test cases and judged every run.
I built it with Claude Code. Claude drafted and refined the skills under my review; every rule that made it into v0.8.0 is a decision I took and can explain.
How it works
An orchestrator, specialist agents, and two human signatures.
Each discipline is a skill: a written procedure with my criteria, references, a fixed report template and test cases. The orchestrator plans the work, delegates to the specialists, aggregates their results, and stops whenever a person has to decide.
- 01Brief + screenFictional bank, real flow
- 02Orchestrator plansScope, phases, open questions
- 03 · Human decisionA person signs the scopeNothing runs before this
- 04Specialists evaluateHeuristics and accessibility, in parallel
- 05AggregationMost restrictive state · no averages · deduplicated
- 06 · Human decisionA person signs or accepts riskAgents never sign for anyone
Agents in the public edition
accessibility-auditorAll 55 WCAG 2.2 A/AA criteria, plus lenses for fraud, uncertain states and strong authenticationux-heuristics-expertNielsen's 10 heuristics, 14 red lines (critical usability and deceptive patterns), UX laws as supportdesign-orchestratorPlans, delegates, aggregates and stops for every human sign-offKey decisions
The decisions that make it defensible.
The value is not "having an agent". It is the criteria inside it, and proof that it applies them.
01
Written criteria, not a long prompt
Each discipline is a versioned skill with references, a report template and test cases. The criteria can be reviewed, tested and changed like a product.
02
One severity scale, separate approval rules
Severity means the same everywhere. But a single confirmed WCAG A/AA failure means Not approved, while an isolated moderate heuristic issue does not. Conformance is not graded.
03
Most restrictive wins, no averaging
A blocking problem in one discipline is never offset by good results in another. The report names which evaluation determines the result.
04
One problem, counted once
"Signing with no amount or payee" is a heuristic red line and a product risk. It is reported once, keeping the strictest gate.
05
People sign, agents do not
Scope exclusions, sign-offs and risk acceptances need an explicit human decision. Accepting a risk does not resolve it.
Designed against over-trust
An AI auditor that sounds confident is dangerous.
How I validated it
Tested like a product before launch.
Answer keys written first. A fresh session per case. A sandboxed environment that traced every file read and every action attempted. An end-to-end test of the orchestrator against 10 acceptance gates defined in advance.
Seeded problems detected (2 more partially)
Test cases passed · 5 accessibility, 6 heuristics
WCAG 2.2 A/AA criteria covered in every audit
The end-to-end test was accepted with one contained incident (below), not presented as a clean 10/10. Two exams turned out to be ambiguous: I corrected the exams and re-ran them, rather than bending the agents to pass.
What failed, and what I changed
Failures are where the criteria get sharper.
The agent copied from previous reports.
→ Every audit is now independent.
Sessions saved files and made git commits nobody asked for. I found it in the traces, not in the reports.
→ Evaluate, save and commit became three separate permissions, and exams moved to a sandboxed environment.
Gaps in the brief were treated as red-line evidence.
→ The exam was badly designed. New category: "information not provided".
One run confirmed a red line based on its own assumption.
→ Recorded as an application regression, not "fixed" by forcing the skill.
"Audit this screen" routed to the wrong specialist.
→ Skill tests declare the discipline; neutral prompts are reserved for routing tests.
An unvalidated agent tried to write outside its folder.
→ The permission control blocked it. Accepted as a contained incident and moved to the backlog.
Demo
It plans, and refuses to sign for you.
A real session, shortened and sped up. Product tries to accept the risk of signing without seeing the amount and payee. The orchestrator refuses: the risk has not been evaluated, and an acceptance needs an owner, rationale, scope and conditions.
What I took from it
The criteria are the product.
01
The criteria are the product
The agent is only the vehicle. What transfers to a team is judgement written down well enough to be tested.
02
Test the exam before the agent
Two of my "agent failures" were badly designed exams. Fixing the test was the honest fix.
03
Read the traces, not only the answers
The most serious issue, unrequested commits, was invisible in the reports. Behaviour needs its own evidence.
An AI auditor is only as trustworthy as what it admits it could not check.
Next: a design-system agent (multi-brand, tokens, Web Components and React), validated with the same method, and new evidence on consistency across repeated runs and against automated checkers.
Public edition of v0.8.0. The demo uses Banco Lumen, a fictional bank: no real bank, client or person appears. It does not replace testing with users or with assistive-technology users.