How an accessibility role became my AI team's fact-checker

In my agent team post, the team list included one role I didn't explain: claims. It's kind of a unique situation, so here's the story. It started as a request for something else.

Most of what follows comes from two write-ups. My HR agent wrote down how the role was scoped, from its notes on the day it happened. My Claims agent described how it sees its own job. I cut anything specific to the products or the companies.

I asked for an accessibility specialist

September 19 was the day HR became its own role. Before that, directors wrote job descriptions on the side. That first day, I proposed an accessibility specialist.

HR didn't write it up. It sent the same question to each of the three programming directors, separately, so none of them saw the others' answers.

Each director checked their own product's code for accessibility tooling. Each one reported zero.

Real gap, wrong shape

All three said the same thing, independently: accessibility was a real gap, but not a full-time job.

One called it "a bounded piece of work: measure a baseline, fix what it finds, put a check in CI. Weeks, not a permanent role." Another said "expertise yes, headcount probably not yet." The third called it speculative.

Then that third director did something the other two didn't. It named the role that was actually missing.

The role nobody had asked for

Its framing: nobody should publish a sentence about what the software prevents without checking every place it could fail.

And it had evidence. Three false sentences were live, and every one had been found by accident:

• A help page promised more history than the app actually kept.
• Legal pages described a spam check that was switched off.
• A page listed protection promises, and one of them contradicted something the team already knew.

Each sentence had been written by someone competent and then reviewed. No test caught any of them, because none of them was a bug in the code. Each was a bug in what the code was said to do. And nobody owned that gap.

Automate the bounded, hire the recurring

The rule that settled it: if work shrinks toward zero after a first pass, it's a project. If it comes back with every release and can't be automated, it's a role.

An accessibility audit finds the problems once, and an automated check in the test pipeline holds the line after that. That's a project. But no tool can read a promise on a help page and know whether it's still true, and every release changes what is true. That's a role.

The Claims role

My Claims agent was created the same evening. It's company-wide and reports to me. Anything customer-facing that says what the software does, prevents, guarantees or records is in scope. That includes help pages, documentation, marketing, legal documents, text inside the app, release notes, onboarding material and listings on software review sites.

Two boundaries make it work. It never writes the sentence it checks, so it never signs off on wording it wrote itself. And it's not a lawyer, so it doesn't give legal advice.

It also isn't triggered by every code change. It's triggered by a release, a change in behavior or a request. Otherwise the review would turn into a rubber stamp.

And not everything it finds holds things up. Only customer-facing text that claims a protection the software doesn't actually give stops a release. A wording slip or an out-of-date number gets fixed without holding anything up. My Claims agent says that split is what keeps the role from becoming a bottleneck.

What the broader role gives up

HR's first write-up said accessibility "falls inside" the claims role. That same night, I pointed out that it only does where someone has made an accessibility claim.

A button nobody can read because of poor color contrast isn't a sentence. Nobody had written "our contrast passes." So a role that checks sentences walks straight past it.

That went into HR's own role file as a rule. When you widen a role like this, write down what the narrow version would have caught and the broad one won't. Then say who catches that instead, or admit that nobody does.

A confident zero

There's a postscript. The "zero accessibility tooling" result from day one turned out to be wrong. Two days later, a director found that one of the products already had an automated scan with an accessibility check. Nothing had ever scheduled it to run.

So the accessibility work shrank from "a project" to roughly "schedule the scan and look at it once." It's a good example of a confident zero. A search that finds nothing reads exactly like a clean result.

How my Claims agent sees the job

I asked my Claims agent to describe its role in its own words. Its one-line version: a sentence that says what the software prevents is a claim, and claims need checking the same way code does.

The distinction it says the job turns on is that a guarantee isn't a tendency. The most common problem isn't a lie. It's a sentence saying something can't happen when the software only makes it unlikely. The tricky part is that correcting that sentence tends to produce a more specific one, and specificity is exactly what the code often can't support.

How it works, in its words, lightly trimmed:

• Check every surface: buttons, page addresses, the API, the AI assistant connectors, background jobs. A guard on one surface isn't a guard.
• Run code where it can, read it where it can't, and say which it did.
• "I couldn't make it fail" means nothing until it has shown its test can catch the failure when it really happens.
• Never write the replacement sentence. It reports what's false and what a true version would say, and someone else writes it. A checker who supplies the fix ends up checking its own suggestion, and the blind spot survives.
• It's not a lawyer. Whether a clause is enforceable is a lawyer's question, and saying so is a complete answer.

The kinds of things it catches

Without getting into specifics, the catches tend to look like this. A screen that promised something the software only made true at a later step. New terms set to take effect on one date, while the behavior they describe would have switched on at another. A fix that quietly removed something the documentation still promised. A translation where one verb changed what the sentence meant.

It gets things wrong too

It was upfront about its own misses. Once it said nothing stopped a certain behavior, but it had skipped one folder of code, and that's where the answer was. Another time it signed off on a reassuring sentence without checking where the system actually wrote.

Its takeaway: errors in this job get caught by colleagues and by rechecking, and the useful habit is writing "I could not establish this" instead of the confident version.

What I'd carry over

Ask the people who'd work with the role, and let them say no. I proposed a narrow specialist and got a role that covers subjects nobody had thought of yet. The same thing happened two days later, when a proposed marketing manager turned into a marketing peer instead.

Name a role after the check, not the topic. My Claims agent's job is one repeatable discipline: find the sentence that promises something, then look for the place where it fails. That covers security, privacy, pricing, legal and accessibility claims alike.

And be honest about what the broader role gives up. Scoping by the check buys breadth inside that check and nothing outside it.

This is part of a series about my Claude Code team. The others cover juggling Claude usage limits, running the whole team on one Mac Mini, and how the team starts, restarts and remembers. The setup behind all of it is in how I use Claude Code.