Every team that fixes its agent-readiness issues faces the same second problem: keeping them fixed. A redesign ships, a component library upgrades, someone refactors the checkout — and the labeled fields, the JSON-LD, the semantic buttons quietly disappear. No error, no alert. You find out when the numbers sag.
Why this belongs in CI
CI is where engineering already encodes "things that must stay true": tests, types, lint, bundle budgets. Agent-readiness is the same shape of invariant — this page must remain machine-operable — and it's checkable at exactly the right moment: on the pull request, before the regression exists in production.
The non-negotiable: determinism
A gate that flakes gets deleted within a month, and deservedly. That means the merge check can't be an LLM vibing about your markup — it has to be a deterministic suite: same input, same score, versioned scoring so a number is always explainable. Autonomous agent runs are valuable as a periodic, deeper signal; the thing that blocks merges must be reproducible.
What a good gate checks
Two layers. Score: the static readiness score for key pages must not drop below your threshold. Flows: the deterministic task suite — find product, add to cart, reach checkout, sign up — must still complete. The second layer is the one that catches real money: a page can keep a decent score while a renamed field breaks the actual task.
Adopting it without team revolt
Start advisory, prove the signal, then make it required.
Run the check in report-only mode for a couple of weeks so the team sees what it catches and that it doesn't flake. Then flip it to a required status check on the branches that ship customer-facing markup. One more habit closes the loop: when the gate does block something, the fix should arrive as a reviewable PR — not a ticket that ages in a backlog. At that point agent-readiness stops being a project and becomes a property of your pipeline, which is the only place it survives.