Can your organisation produce, this week, a list of every autonomous action it took last week, with the person who authorised each one named beside it?

I ask because I spent part of August trying to answer that question for a system I am building, and the process of failing to answer it cleanly taught me something I did not expect about where the specification for agent governance is currently being written.

It is not being written by vendors. It is not being written, yet, by the US banking agencies — they withdrew the framework that would have specified controls and promised a consultation that has not arrived. It is being written, right now, in supervisory guidance in the Gulf, and it is being written in a form that is almost embarrassingly close to an engineering backlog.

That is the argument of this edition. Not "regulation is coming, prepare." Something more specific and more useful: the requirements list already exists, it is short, and most organisations have four of the five items already sitting in their systems as data that nobody has rendered.

The five items

Read across the supervisory material that Gulf regulators have published for organisations adopting AI, and a consistent list emerges. Organisations are told to prepare:

  • an AI inventory
  • use-case ownership
  • risk classification
  • testing controls
  • monitoring processes and evidence of accountability

Five bullet points. No technology named, no vendor implied, no architecture prescribed.

Now read that list a second time, not as a compliance obligation but as a product backlog for a governance system. Because that is what it is. Every item is a data structure and a view.

AI inventory is a list of every grant of authority that has been made — what the agent was permitted to do, and within what bounds.

Use-case ownership is a goal field and a named human attached to each grant.

Risk classification is a categorisation of the side effects an action can have. Read-only. Writes something. Spends money. Moves something physical.

Testing controls is evidence that the bounds were exercised adversarially before the grant was made.

Monitoring and evidence of accountability is a durable, tamper-evident record of what happened under each grant, and who approved what along the way.

I want to be careful here, because there is a cheap version of this observation. The cheap version is "regulators want governance, and our product does governance." That is not the claim. The claim is narrower and stranger: the supervisory list happens to be a well-specified data model, and if your systems already produce the underlying facts, the distance between where you are and what the list asks for is a rendering problem rather than an architectural one.

What happened when I checked my own system

I ran this list against a substrate I have been building for governing autonomous agents, and the result was uncomfortable in a specific and instructive way.

Four of the five items existed as data. None of them existed as a surface a non-engineer could reach.

Inventory: the data exists. Every grant of authority is recorded, with the bounds attached — what paths, what tools, what network, what budget, what deadline. A list of every agent action authorised in a period is a query, not a project.

Ownership: half of it exists. Each grant carries a goal, in words, written by whoever made it. It did not carry a named owner as a first-class field. That is a small schema change and a genuine gap, and it is exactly the kind of gap this exercise is for — the supervisory list found it, and my own architecture review had not.

Risk classification: exists. Every action a supervised agent can take is classified by its side-effect class before it is permitted. That classification is the mechanism by which some things are staged for review rather than executed, so it is load-bearing rather than descriptive.

Testing controls: partially. Bounds are exercised, but the adversarial suite that would test the authority layer itself rather than the model on top of it is specified and not complete. I will not overstate this one.

Monitoring and accountability: exists, and is the strongest of the five. Every supervised session is recorded, approvals are hash-chained, and the approval loop is multi-party.

So: four of five present as data, and zero of five present as anything a risk officer could open.

The measured version of "zero"

I want to put a number on that, because "we don't have a UI yet" is the kind of sentence that hides a range from "two weeks of polish" to "nothing exists."

The measurement was simple and I would recommend it to anyone assessing a vendor or their own internal build: search the entire repository for interface code. No component files. No application framework configuration. Every surface in that system is a command line, a library, a machine interface, or a background service.

The governance console is a headless library — the data model, the state reducers, the approval semantics, the client — roughly 263 lines, with tests. Its own documentation says the component layer is a later task. It was never built. The service that would serve it publishes a port and returns a placeholder, and the placeholder says so in its own health response.

That last detail is the part I would defend and the part I want a board audience to take seriously. The placeholder is labelled. It announces itself as a placeholder in a machine-readable field. It is not a product, and it does not claim to be one. That distinction — between a thing that is missing and a thing that is missing while pretending otherwise — is the whole difference between an honest state and a dangerous one, and it is the single most useful question to ask about any governance capability someone is showing you.

The mechanism that makes the record worth having

There is one piece of design in that system that I think generalises to any organisation trying to satisfy the fifth bullet point, and it took me a while to understand why it mattered.

Every supervised session records whether anything was watching it. When no monitor was attached, the record does not omit the field. It records that the field is empty.

The reason is this: "nobody was watching" and "nothing ran" produce identical evidence in almost every logging system in existence. Both look like an absence. If your monitoring produces records only when something is monitored, then a period with no records is indistinguishable from a period where monitoring was misconfigured, disabled, or silently failing.

For a supervisory conversation that distinction is the whole game. A regulator asking whether your controls were operating during a period does not want a log with nothing in it. They want a positive assertion for every interval: either a monitor was attached and here is what it saw, or no monitor was attached and here is the record saying so.

The same principle showed up twice more in that system and I now treat it as a rule. A queue that could not be read is never rendered as an empty queue — those are different facts and collapsing them is how an operator concludes "nothing needs my attention" when the truth is "I could not find out." And "nothing is waiting" and "nothing is waiting on you" are also different facts about the same store, and a surface that shows one when it means the other is training somebody to stop looking.

Why the North American position makes this urgent rather than optional

In April 2026 the Federal Reserve, the FDIC and the OCC issued revised interagency guidance on model risk management — carried as OCC Bulletin 2026-13 and designated SR 26-2 by the Federal Reserve. It supersedes the 2011 and 2021 letters. Two things in it are load-bearing here.

Generative and agentic AI models are described as novel and rapidly evolving and placed expressly outside the guidance's scope, with separate AI guidance promised. And the guidance states that it does not set forth enforceable standards or prescriptive requirements.

The tempting reading is that agents are therefore unregulated. That reading is wrong, and it is expensive to get wrong. What was withdrawn is the framework that would have specified the controls. Every obligation attached to the underlying action — safety and soundness, consumer protection, sectoral duties, third-party risk — is untouched. The guidance is explicit about the consequence: an institution's own risk management and governance practices should guide the determination of appropriate governance and controls for systems the document does not cover.

Read that sentence as an executive rather than a lawyer. It says: you decide, and you will be judged on what you decided. That is not a lighter obligation than a prescriptive rule. In several respects it is a heavier one, because there is no safe harbour in following a checklist somebody else wrote.

The agencies also stated an intention to issue a request for information on model risk management generally and on banks' use of AI, ahead of that separate guidance. As of yesterday, four months on, it had not been issued — a negative I checked against the Federal Register and both agencies' own newsrooms rather than inferred from not having heard about it.

An RFI is a comment window. The specification that eventually arrives will be drafted by people reading what institutions were able to demonstrate during the interval. Which produces a conclusion I find genuinely unusual in this field: the current period is the only one in which what your firm builds influences what your firm is later measured against. Building now is not early compliance. It is participation in the drafting.

The asymmetry that should decide the agenda

Set the two regions beside each other and the shape of the opportunity is clear.

One supervisory tradition has published a short, concrete list of what organisations must be able to produce, without prescribing how. Another has explicitly deferred the control specification and invited the industry to demonstrate what works.

The first gives you a target. The second gives you standing.

An institution that builds against the concrete list is not merely satisfying one jurisdiction. It is producing exactly the artefact that the deferred specification will be written against — an inventory, an owner, a classification, a test, and a record. Those five things are not Gulf-specific. They are what any supervisor anywhere asks when they want to know whether an autonomous system was under control.

I would go further. If I were setting a risk committee's agenda for this quarter, the item would not be "AI governance policy." It would be: produce the five artefacts for one production agentic workflow, end to end, and time how long it takes. The number that comes back is the real state of your governance, and it will not match the policy document.

What I got wrong

Two things.

I treated the missing interface as a small item. For months the absence of a non-engineer surface sat on my list as polish — the hard part being the semantics, which were built and tested. That was a category error. A governance capability that cannot be reached by the person accountable for governance is not a governance capability. It is a data structure with good intentions. The semantics being correct is a necessary condition and it is not the product.

I derived the feature list from the architecture rather than from the requirement. My own design review had not found the missing owner field. A five-bullet supervisory list found it in about a minute, because it was written by people describing what they need to see rather than by people describing what they have built. That is an argument for reading requirements documents from outside your organisation as design input, which is not how most engineering teams treat them.

What to check on Monday

One. Pick one agentic workflow in production. Ask for the five artefacts: inventory entry, named owner, risk classification, evidence it was tested adversarially, record of what it did and who approved. Time it. Do not accept "we could build that" — ask for the artefact.

Two. For your monitoring: check whether a period in which monitoring was disabled produces a different record from a period in which nothing happened. If both produce silence, you cannot evidence that controls were operating, only that nothing alarming was recorded.

Three. Look at any governance dashboard you rely on. Find the state it shows when it cannot reach its data source. If that state is visually identical to "all clear", the dashboard is capable of reassuring you at the exact moment it stops working.

Four. Ask who is named as the owner of each autonomous workflow. Not the team. The person. If the field does not exist, it is a schema change, and it is the cheapest item on this list.

Five. Ask your AI vendors one question: which of your governance surfaces is a product, and which is a placeholder? An honest vendor will answer. The answer tells you more than a demonstration.

What I am not claiming

I am not claiming that satisfying five bullet points satisfies a regulator. Supervisory judgement is not a checklist and the list I have described is guidance to organisations rather than an examination manual.

I am not claiming the mapping between supervisory language and system data is exact. It is close enough to be useful as a design input and loose enough that any specific institution will find items that do not translate.

And I am not claiming my own system satisfies the list. Four of five exist as data, one is partial, and the surface that would let a non-engineer reach any of it does not exist. I have described it that way because a piece arguing for honest state reporting cannot make an exception for its own author.

The invitation

I want something specific from readers in a risk or compliance function, and it is not a conversation about my system.

Tell me the format your supervisor actually accepts for an AI inventory. Not what the guidance says — what your examiner, in your jurisdiction, in your sector, has accepted or rejected. A column list. A file format. A level of granularity. Whether one entry is per model, per workflow, or per grant of authority.

That detail is the difference between a design that satisfies a requirement and one that satisfies a supervisor, and it is not written down anywhere I can read. It exists in the working knowledge of a few hundred people who have sat through the examination.

If you are one of them, that knowledge is worth more to this work than any amount of further reasoning from the guidance text.

Claims register

  • Gulf supervisory material names inventory, use-case ownership, risk classification, testing controls, monitoring and evidence of accountability · published supervisory guidance · read
  • Four of the five map to existing data structures in the system described · my mapping against the codebase · verified — mapped against source
  • A named-owner field did not exist as a first-class field · codebase · verified — absent
  • No interface code exists anywhere in the repository · repository-wide search for component and framework files · verified — measured
  • The console is a headless library of roughly 263 lines with tests, component layer never built · package source and its own documentation · verified — read in source
  • The console service returns a placeholder that declares itself in its health response · service configuration and health output · verified — observed
  • Sessions record a null monitor rather than omitting the field · run-accounting implementation · verified — observed
  • The approval loop is multi-party with a hash-chained actor log · approval implementation, exercised with three operators in a browser · verified — observed end to end
  • OCC Bulletin 2026-13 / Fed SR 26-2, 17 April 2026, places generative and agentic AI expressly out of scope · the instrument · read — previously verified against the issuing agency
  • The guidance does not set forth enforceable standards or prescriptive requirements · the instrument · read
  • The promised request for information had not been issued as of 19 August 2026 · Federal Register and both agencies' newsrooms · verified — checked, with the limits of a negative stated
  • SR 11-7 and SR 21-8 are superseded · the instrument · verified — never characterised as current

What would falsify the central argument: an examination in which an institution produced all five artefacts and the supervisor found them insufficient in kind rather than in quality. That would mean the list is not the specification, and I would want the actual one.