The agent loop is becoming the enforcement layer
For most of software's history, correctness has been checked after the fact. You write the code, then a linter reads it, a scanner audits it, a reviewer reads the diff, and CI decides whether it ships. Every one of those steps happens after the code already exists, done by separate tools, often on separate days.
That arrangement is quietly coming apart. The interesting movement in developer tooling right now is not a new scanner or a faster linter. It is where the checking happens. Across security, code quality, and now accessibility, the check is moving out of the after-the-fact review step and into the loop where code is written, enforced by the same agent that is generating it.
Once you see the pattern you start seeing it everywhere.
The check moved into the loop
The old model was always the same: point a tool at a repository, it produces a report, someone reads the report, findings become tickets. The tool sat downstream, describing code that already existed. By the time a finding surfaced, the developer who wrote the line had moved on and the context that would make the fix quick was gone. Accessibility worked the same way — a scanner ran against a deployed page, and the gap between "the problem was created" and "someone is looking at it" was measured in weeks.
That distance is what is now collapsing. Instead of scanning finished code, the same tools hand the agent their rules as it writes. SonarQube ships an MCP server and one-command hooks for Claude Code, Copilot, and Codex, with the stated goal of enforcing quality "in the agent coding loop" — gates the agent has to satisfy, not a report a human reads later. Semgrep is building toward the same place, static analysis positioned as a guardrail in the workflow rather than an audit bolted on the end.
One honest caveat about that second row before we go further: the "checks" step carries a lot of weight, and automated verification only reaches so far. A static check confirms a label exists, a heading level is not skipped, an ARIA attribute is valid. It cannot tell you whether the label means anything, whether focus order matches the way a person reads the page, or whether a keyboard user can actually escape a menu. That mechanical layer is a real slice of the work and worth automating, but it is not the whole of accessibility, and a loop that treats "passed the check" as "accessible" is quietly overstating what it did. Hold that thought; it is the whole reason the next section exists.
The governance vocabulary is following. A recent tl;dr sec write-up describes agent frameworks giving each agent its own identity that logs actions as "this agent did this on behalf of [user]," plus static guardrails, a per-agent privilege ceiling, and per-task policies. That is the language of enforcement, not reporting.
Accessibility arrived in the same loop
The reason this is a Jeikin story is that accessibility landed in exactly the same place this month, and from an unexpected direction: the AI tools themselves started shipping it as a default, not an add-on. GitHub's app now has screen readers announce agent activity as it happens; Wispr Flow ships keyboard, screen reader, and reduced-motion support on by default; the platform 12twenty ran a broad pass across its navigation, forms, and dialogs.
None of these are accessibility products. They are AI and developer tools that decided accessibility was table stakes for the loop they operate in. When the tools people use to write code treat keyboard and screen reader access as default behavior, the floor for "shippable" rises for everyone downstream. We argued in finding issues was never the problem that closing the distance between finding and fixing was always the hard part. Moving the check into the writing loop is how that distance closes.
What it takes to actually count
Here is what separates a real enforcement layer from a nicer-looking scanner. Being "in the loop" is necessary but not sufficient. A check that runs in the loop and produces a suggestion the agent can ignore is still just advice, delivered earlier. For the loop to enforce anything, three things have to be true.
The rules reach the agent before it writes. A guardrail the model receives as part of its instructions shapes the output. A finding delivered after generation is back to being a report.
The result is verified, not asserted. An agent saying it added a label is not the same as a label existing and being announced. An agent will tell you it built an accessible dialog because it added aria-modal="true", and if focus never gets trapped inside that dialog, the claim was confident and wrong. Enforcement means the fix is checked against reality, ideally by exercising the behavior rather than reading the markup, and the check has a recorded outcome, so "done" points to something real instead of something the model believed.
The outcome leaves evidence. This is what turns a workflow into a compliance story. If a fix happens inside a chat window and vanishes when the session ends, there is nothing to show a client or an auditor. The value is not just cleaner code today; it is a durable trail proving the code was checked.
It is worth being clear about who each half of that serves, because they are not the same person. The evidence serves the business: a record the team can hand to a client, a procurement reviewer, or a compliance lead. The verification serves the user: whether the person relying on a screen reader can actually complete the task. Those interests usually point the same way, but they can come apart, and when they do the verification is the one that matters. A trail proving a check ran is worth very little if the check only ever confirmed the mechanical layer and the experience underneath still breaks. Evidence without real verification behind it is the thing accessibility overlays have always sold. The point of doing this in the loop is to make the evidence mean something, because the behavior behind it was actually checked.
Those three properties are what we built Jeikin around, applied to accessibility. When an agent works through Jeikin, the rules for an issue are fetched before the fix, the fix is verified with an automated check, and the outcome is recorded as evidence rather than living and dying inside a conversation. It is the accessibility instance of the same pattern SonarQube and Semgrep are building for quality and security.
The shift underneath all of it
Step back and it is one movement in every domain: correctness is migrating from a thing you inspect afterward to a property the agent maintains while it works. Security got there first because the stakes made it obvious, quality followed, and accessibility is arriving now — partly because the AI tools decided it was non-negotiable, partly because the machinery that enforces a SQL injection rule carries over cleanly to the mechanical layer of accessibility, even if the judgment-heavy parts still need a human or a behavioral test.
If you are building with an agent today, the takeaway is short: stop auditing your standards later, start handing them to the agent as constraints it works inside. Give it the rule before it writes. Verify the result. Keep the evidence. The web's median has never been accessible, and twenty years of post-hoc scanning never changed that. Moving the check into the loop is the first thing that plausibly does — and it is finally being built in, by the tools doing the building.
If your agent is already writing your code, it can already enforce your accessibility standards while it works. See how Jeikin fits into the loop.