Skip to main content
Vertical AnalysisLowest Scores

Government Agent Readiness: Why Public Services Are the Most Invisible to AI Agents

Government websites are designed for compliance, not for agents. PDF forms instead of APIs. CAPTCHA walls instead of authentication tokens. Phone trees instead of endpoints. The IRS, DMV, and city portals all score under 15 on the Agent Readiness Score. The irony: government mandates WCAG accessibility for humans but blocks AI accessibility entirely.

AH
AgentHermes Research
April 16, 202614 min read

The Accessibility Paradox

The US federal government has spent billions on digital accessibility. Section 508 compliance. WCAG 2.1 AA standards. Screen reader compatibility. Keyboard navigation. Every federal website must be accessible to people with disabilities — and most are, at least nominally.

But there is a category of user that no government regulation addresses: AI agents acting on behalf of citizens. When someone asks an AI assistant to “check my tax refund status,” “renew my driver's license,” or “find out if I qualify for food stamps,” the agent hits a wall. Not a content wall — an infrastructure wall.

Government websites are built to be read by humans with assistive technology. They are not built to be used by AI agents with API calls. The result is a paradox: the most accessibility-conscious sector in the economy is the least accessible to the fastest-growing category of digital interaction.

<15
Avg govt score
0
Govt MCP servers
95%
Services in PDF
48
Best: data.gov

Government Agent Readiness Scores

The gap between service-delivery government and data-distribution government is stark. Data agencies score 3-5x higher than service agencies because their mission naturally produces structured, machine-readable outputs.

Entity
Score
Tier
Key Issue
IRS (irs.gov)
11
Not Scored
PDF forms, CAPTCHA, no API, phone-only resolution
DMV (varies by state)
8
Not Scored
Appointment via phone, no structured data, legacy CMS
City Portals (avg)
12
Not Scored
Permit PDFs, no digital submission, fragmented systems
data.gov
48
Bronze
Structured APIs, CKAN catalog, machine-readable datasets
USASpending.gov
52
Bronze
REST API, OpenAPI spec, bulk download, structured fiscal data
Census Bureau API
45
Bronze
REST endpoints, API key auth, structured demographic data

The exception proves the rule: data.gov, USASpending.gov, and the Census Bureau API all score Bronze because they were built to distribute data, not deliver services. Their mission required structured APIs from day one. Every government service that involves citizen interaction — taxes, permits, licenses, benefits — scores under 15.

Five Failure Patterns That Make Government Invisible

The same five patterns repeat across federal, state, and local government websites. Unlike professional services firms that score low due to neglect, government scores low due to design. These are intentional architectural decisions that were correct for a pre-agent world but are now blocking the next generation of citizen services.

PDF form walls

95% of government services

Tax forms, permit applications, license renewals — all locked in PDF. An agent cannot fill a PDF, cannot extract structured fields from one, and cannot submit one electronically. This kills D2 API Quality (15%) and D9 Agent Experience (10%).

CAPTCHA as default security

80% of government portals

Government sites use CAPTCHA on nearly every interaction point. Designed to block bots, it equally blocks AI agents acting on behalf of authenticated users. There is no machine-to-machine bypass or OAuth alternative.

Phone-only resolution

90% of government services

"Call 1-800-xxx-xxxx for assistance" is the universal government endpoint. No API, no webhook, no structured callback. When an agent hits a dead end, there is no programmatic path forward.

Legacy CMS with no API layer

70% of federal and state sites

Most government websites run on legacy content management systems — Drupal 7, custom .gov frameworks, or static HTML generators. None expose structured APIs. Content exists as rendered HTML pages, not queryable data.

No structured service catalog

99% of government agencies

Businesses publish product catalogs. Government should publish service catalogs — but none do in a structured format. What services does this agency provide? What are the requirements? What are the timelines? All buried in prose.

What Agent-Ready Government Would Look Like

Imagine asking an AI assistant: “Am I eligible for the Earned Income Tax Credit this year?” Instead of linking you to a 47-page PDF, the agent calls an eligibility API with your filing status and income. It returns a structured yes/no with the estimated credit amount, required forms, and a link to file electronically. That is agent-ready government.

1

Structured service catalog API

D1 Discoverability, D2 API Quality

A machine-readable endpoint listing every service the agency provides, with requirements, timelines, fees, and eligibility criteria as structured fields. Like a product catalog for public services.

2

Digital form submission API

D2 API Quality, D9 Agent Experience

Every PDF form should have an API equivalent that accepts structured JSON input, validates fields, and returns a confirmation. The form data already exists in structured databases — the API is the missing surface.

3

Appointment scheduling endpoint

D2 API Quality, D3 Onboarding

DMV, passport offices, benefits offices — all require appointments. A REST endpoint for check_availability() and book_appointment() would replace millions of phone calls per year.

4

Application status-check API

D6 Data Quality, D8 Reliability

Tax refunds, permit applications, license renewals — citizens constantly check status. A get_status(application_id) endpoint with structured responses eliminates the need for phone trees and "check back in 6-8 weeks."

5

Machine-readable eligibility rules

D6 Data Quality, D9 Agent Experience

Benefits eligibility, tax brackets, permit requirements — all currently buried in legal prose. Structured rules engines that agents can query would let AI assistants answer "am I eligible for X?" with real data.

This is not speculative. The UK Government Digital Service (GDS) already publishes structured APIs for tax, benefits, and vehicle registration. Estonia runs 99% of public services through digital infrastructure with structured APIs. The US has the policy framework — the IDEA Act, the Federal Data Strategy, the API-first mandate from OMB M-23-22. What is missing is execution at the service-delivery layer.

The irony is that government is invisible to AI agents at exactly the moment when citizens are starting to use AI assistants for the most frustrating interactions in their lives: taxes, permits, benefits, and bureaucratic processes that currently require hours on hold.

The WCAG Irony: Accessible to Humans, Hostile to Agents

WCAG compliance mandates semantic HTML, ARIA labels, alt text, keyboard navigation, and color contrast ratios. Government has spent decades and billions achieving compliance. These efforts produce marginal benefits for AI agents — semantic HTML is slightly easier to parse than tag soup — but they fundamentally miss the point.

WCAG accessibility is about consuming content. Agent readiness is about performing actions. A screen reader can read the text on irs.gov. An AI agent cannot file a tax return on irs.gov. The gap between reading and doing is the entire agent readiness score.

A new mandate is needed — not WCAG 3.0, but something like “AARG” (Agent Accessibility and Readiness Guidelines). Structured service catalogs. Machine-readable eligibility rules. API endpoints for every citizen interaction. The same rigor applied to screen readers should be applied to AI agents — because increasingly, citizens will interact with government through agents, not through browsers.

What WCAG gives agents

  • Semantic HTML structure
  • Alt text on images
  • Labeled form fields
  • Consistent navigation

What agents actually need

  • REST API endpoints
  • OAuth or token auth
  • Structured JSON responses
  • Machine-readable service catalog

Frequently Asked Questions

Why do government websites score so low on agent readiness?

Government websites are designed for compliance (Section 508, WCAG), not for machine consumption. They optimize for human-readable content — PDFs, prose, phone numbers — rather than structured APIs. The absence of any API layer means agents have no programmatic entry point. Additionally, CAPTCHA, session-based auth, and legacy CMS platforms actively block automated access.

Are there any government services that score well?

Yes. Data-focused agencies score significantly higher than service-delivery agencies. data.gov (48 Bronze), USASpending.gov (52 Bronze), and the Census Bureau API (45 Bronze) all provide structured REST endpoints with machine-readable data. The pattern is clear: when the mission is data distribution, the infrastructure is agent-adjacent. When the mission is service delivery, it is agent-hostile.

Could government services realistically become agent-ready?

Technically, yes. The UK Government Digital Service (GDS) has already shown that government can build API-first services. Estonia runs nearly all public services through structured digital infrastructure. The US has the 21st Century Integrated Digital Experience Act (IDEA Act) and the Federal Data Strategy — both mandate machine-readable data. Execution is the gap, not policy.

Does WCAG accessibility help with agent readiness?

Partially. WCAG mandates semantic HTML, alt text, and keyboard navigation — all of which improve D1 Discoverability slightly. But WCAG is designed for screen readers, not AI agents. Screen readers parse rendered pages. Agents need APIs. Accessibility and agent readiness overlap on maybe 10% of signals. The remaining 90% requires dedicated agent infrastructure.


Score any government website

Run a free Agent Readiness scan on any .gov domain. See exactly which dimensions fail and what it would take to make public services agent-accessible.


Share this article: