The OCC's AI framework and the problem of agents that spawn agents

When one AI agent can start 10,000 subagents, human review of each action stops being possible.

Joseph Lo raised that number on a panel at the SIFMA and PwC Risk and Regulatory Forum in September. His point was that agents cannot be supervised one at a time once a single agent can start thousands more. He also said, "If humans must review every output, the savings may not materialize."

A short animation of one agent spawning thousands is in the original version of this article on the author's site.

On November 4, 2026, the Office of the Comptroller of the Currency (OCC) published a 22-page framework that looks at the same problem from the examiner's side. It ranks AI risk well. It leaves the agent-swarm problem open.

A guide for examiners, not a rule

OCC Bulletin 2026-54 points to a PDF titled "OCC Supervisory Framework on Bank Use of Super Intelligence."

The framework is guidance for examiners. It is not a rule, and it rescinds nothing. It does show what an examiner is likely to ask when reviewing a bank's AI.

The name needs a note. "Super Intelligence" here means ordinary AI. A footnote says the term "refers to the technologies and systems previously encompassed by the term 'Artificial Intelligence' as defined in 15 USC 9401(3)," and points to Executive Order 14434 from October 2, 2026. Wherever the document says SI, read AI.

The framework also fills a gap. The interagency model risk guidance issued in April 2026 (OCC Bulletin 2026-13, Fed SR 26-2) replaced the 2011 guidance and said generative and agentic AI "are not within the scope of this guidance." The new framework says it is "more applicable to generative and agentic SI."

Footnote 3 adds a detail worth noting: the framework "was prepared with the assistance of SI. The content has been reviewed, edited, and approved by a human." The regulator disclosed its own use of AI.

How the tiers work

The framework gives an example that belongs in every AI program's governance materials: "a simple rules-based agent authorized to initiate transactions could present greater risk than a sophisticated model limited to internal drafting assistance."

Many teams still triage AI by model: which vendor, which version, how capable. The OCC asks a different question: what the system can do if it is wrong, and who notices.

The document scores each use case on seven factors (page 14):

Factor	What the examiner asks
Decision consequence	Does it inform a human, make a decision, or take an action directly, like moving funds or interacting with a market?
Reversibility	Can a bad action be caught and undone before harm, or is it effectively final once executed?
Customer and financial impact	How large is the harm to a customer, the markets or the bank if it is wrong?
Autonomy level	Human in the loop, human on the loop, or fully autonomous?
Data sensitivity	Does it touch regulated, confidential or personal data?
Explainability	Can the output be traced to a reason good enough for legal or disclosure duties?
Provenance	Built in house, fine tuned from a vendor model, or bought as a service?

Those factors "combine into a 'composite tier.'" The tier table on page 15 sets out four levels.

"Market access" sits in Tier 1, next to autonomous payment agents. Given the Knight Capital history covered below, that placement is well founded.

Test results do not lower the tier. The framework says a fully autonomous, customer-facing payment agent sits at Tier 1 "regardless of how well it performs in testing." A strong evaluation score will not move a system down a tier. Less autonomy, more reversibility or less impact will.

Human review at agent scale

This section matters most for any program that relies on a human approval step to control agent risk.

The key phrase is "more than a nominal click." The framework also separates two ideas that are often blurred. Human in the loop means "review and approval before an output or action is used or executed." Human on the loop means "active monitoring with authority and practical ability to intervene."

The span of control line is where the 10,000 figure returns. Whatever number one person can credibly monitor, a swarm of agents exceeds it quickly. A reviewer can check what a group of agents returns. The reviewer cannot check every step each agent took to get there.

When the system stays up and is wrong

The operational resilience section contains the line that should guide any agent running in production.

Most resilience plans start from an outage. This one starts from a system that stays up and keeps taking the wrong action while the uptime dashboard shows green.

The same section names "velocity limits" for outside agents, and the cybersecurity section warns that "Broad credentials or permissions could allow a compromised or manipulated agent to cause fraud, data exposure, or operational disruption at machine speed." It suggests governing agent identities and credentials "in a manner comparable to privileged users."

Knight Capital, 2012

On August 1, 2012, Knight Capital deployed new code to an order router that still held an old, unused function. According to the SEC, "During the first 45 minutes after the market opened on August 1, Knight Capital's router rapidly sent more than 4 million orders into the market when attempting to fill just 212 customer orders." The firm "eventually suffered a loss of more than $460 million" and later paid a $12 million penalty.

The SEC had already adopted the market access rule, Rule 15c3-5, in 2010. It requires broker-dealers to block orders that breach preset credit or capital thresholds, and to reject erroneous orders, "on an automated, pre-trade basis, before orders are routed to the exchange or ATS." Knight's case was the SEC's first enforcement action under that rule.

The SEC's findings read like a list of what an agent program could get wrong today:

No adequate control "immediately prior to its submission of orders to the market, such as a control to compare orders leaving the router with those entered."
Financial controls "not capable of preventing the entry of orders that exceeded pre-set capital thresholds for the firm in the aggregate."
No adequate controls for code deployment and testing.
A control review that "largely focused on compiling an inventory of existing controls and ensuring they functioned as intended, instead of focusing on such risks as possible malfunctions."

An internal Knight system also generated 97 automated emails that went to a group of staff. The SEC says Knight "did not act upon them on August 1." An inbox cannot keep pace with a router sending tens of thousands of orders a minute.

Daniel Hawke of the SEC said firms "must look at each component in each of their systems and ask themselves what would happen if the component malfunctions and what safety nets are in place to limit the harm it could cause." Thirteen years later, that sentence still sums up most of the OCC framework.

Five gaps in the framework

The document is careful and mostly permissive. It uses "may" and "could" almost everywhere, and the word "must" never appears in the PDF. That fits an examiner guide the OCC says it will update. Five gaps remain.

Agents that spawn agents are not addressed. The terms "spawn," "sub-agent," "multi-agent" and "orchestration" do not appear in the full text. The closest references are the span of control line and a note on "correlated or cascading activity across customers, agents, and providers."
"Transfer of agency" is not defined. It is one of the three headline dimensions in the bulletin, and the PDF never says what it means. Section 2.2 lists two dimensions, page 3 lists nine factors and page 14 lists seven. The lists overlap but do not match.
The tiers do not map to controls. The framework promises "light-touch for low-risk, low-autonomy use, materially heavier for anything approaching customer-impacting, irreversible, or highly autonomous action." It does not say which controls a Tier 1 system needs that a Tier 3 system does not. Everything in the scoring section is labeled "illustrative," and there are no weights.
There are no hard limits. Kill switches, circuit breakers and rate limits "could help." Nothing says what a sensible limit looks like, who sets it, or that it should sit outside the agent's own control. For market access, Rule 15c3-5 is explicit: the controls must be under the firm's "direct and exclusive control."
One tier listing is inconsistent. Tier 2 lists "code assistance for internal code or data access changes." Tier 4 lists plain "code assistance." The likely reading is that the tier depends on what the code touches, but the document does not say so.

Taken together, the framework is a sound first version. Each bank will need to make its own decisions in these gaps.

Recommendations for banks

These are Infinity AI's recommendations. The OCC does not require them.

Inventory every agent with its permissions. The framework asks for the use case, owner, provider, permissions, deployment status, monitoring and fail-over. Permissions are the column that decides the tier.
Treat spawned agents as the parent's agents. A subagent should inherit the parent's limits and count against them. Ten thousand subagents should not receive ten thousand separate budgets.
Place limits outside the agent. Rate limits, spending caps and kill switches belong in the platform the agent runs on, where the agent cannot change them. Rule 15c3-5 asks the same of broker-dealers with its "direct and exclusive control."
Set span of control as a number. Decide how many actions per hour one reviewer can actually check. If the agent exceeds that, the review is a nominal click, and the framework says so.
Test the failure where the system stays up and acts wrongly. Run a drill where the agent is healthy, fast and wrong, and measure how long it takes someone to stop it.

Before any AI agent goes into production, two questions need clear answers. What is the worst it can do on its own? What stops it before it gets there?

When agents move faster than people can review, the limit belongs on the agent.

Sources

Screenshots are from the OCC bulletin page and the framework PDF. Page numbers refer to the numbers printed on the PDF pages.