The Halt: Article 14's Hardest Requirement to Build

At 02:14 on a Saturday an agent enters a retry loop. Nobody is watching. By the time somebody is, the question is not whether you have a policy — it is whether anyone can stop it right now, and whether you will be able to describe afterwards what happened and when.

EU AI Act Article 14 names this capability directly: oversight includes the ability to intervene in or interrupt the system. Of everything Article 14 asks for, this is the one teams most often discover they do not really have, because the mechanism they were relying on turns out to be a deployment.

Why a feature flag is not a halt

A halt has to take effect through a path that does not depend on shipping anything. A feature flag that propagates through a config reload, a CDN cache and a pod restart is a fine way to change behaviour on a Tuesday. It is a poor way to stop something that is currently going wrong, because the propagation path is the thing you are trying to get ahead of.

So the mechanism is a single piece of state — a key in Valkey or its equivalent — read on the path every run already takes, before any other work happens. No build, no deploy, no restart.

The useful property of a halt is not how fast it is. It is that nothing has to be deployed for it to take effect.

That distinction matters more than a number. Publishing a specific stop time as a promise would be a performance claim, and a performance claim belongs in an SLO backed by measurement, not in a paragraph like this one. What can be stated without measuring anything is the architecture: the check sits in the request's existing path, and disabling the system does not require a release.

Three scopes, not one

The hardest design decision is how blunt the instrument should be. Too blunt and an incident in one agent takes down every healthy one beside it — which is its own incident, and one you caused. Too narrow and the operator is picking through a list while the meter runs.

• Stop model traffic — halt LLM calls for the organisation. Non-model tool calls keep running, so anything mid-transaction can still finish or roll back cleanly.
• Stop one agent — the blast radius is a single workload. Right when you know which one is misbehaving and the rest of the estate is fine.
• Stop everything — model calls and tool calls, org-wide. The one you reach for when you do not yet know what is happening.

In a real incident operators usually start narrow and widen. That order is worth designing for explicitly, because the reverse — stopping everything and then trying to bring parts back under pressure — is where the second incident comes from.

The read must fail closed

The obvious question: what if the store holding the halt state is itself unavailable? You cannot fail open. Failing open means the one moment you most need the halt is the moment it silently stops applying, and nothing in the logs will say so.

Fail closed and you accept that an outage in that dependency degrades throughput. That is the correct trade for a control whose entire purpose is to work during a bad hour. It is also the answer a reviewer is looking for, because it is the one that treats the control as a control rather than a convenience.

Who can pull the cord

The halt should be the bluntest and the most restricted control in the platform. Restricted, because its blast radius is the whole organisation. But not so restricted that at 02:14 on a Saturday the only person who can use it is asleep — an escalation path that depends on one individual is not an escalation path.

What a halt has to record

This is the part that turns an operational feature into evidence, and it is the part that gets built last or not at all. Under Article 14 a reviewer is testing whether oversight is effective, and under DORA your financial customer has an incident-reporting obligation that runs on a clock and needs substance from you to satisfy.

• Who invoked it, and under what authority.
• When — and when it actually took effect, which is a different timestamp.
• Which scope was chosen, and why that one.
• What the system did between those two timestamps. This is the field everyone skips and every reviewer asks about.
• When it was lifted, by whom, and on what basis.

A halt that has never been invoked is not a red flag by itself. A halt that has been invoked and left no record of what happened in between is, because it means the control ran and the organisation cannot say what it did.

Where Dobby fits

Dobby reads run telemetry out-of-band — CrewAI, LangChain, OpenAI, Google ADK or a custom SDK — and never sits in the request path. Halts, approvals and overrides land as records against the runs they affected, and the compliance scan evaluates them against the frameworks you have activated, Article 14 and DORA among them.

The per-control verdict has four states: compliant, violated, needs-review, and unverifiable. If the telemetry cannot demonstrate that a halt took effect and what happened while it was in force, the pack reports unverifiable rather than passing the control. Naming the gap is the point — a control that quietly passes on absent evidence is worse than one that fails.