Permission says what an actor may do, never how much. An engineer who could change ten thousand files changes six. An agent does not.
Where the rule lives ended by asking whether anything in an ordinary organisation watches for the moment its assumptions stop matching the world. This article takes the narrowest version of that question, and the one with the widest consequences.
Almost every process a company uses to keep itself safe rests on a quiet assumption about how much work can happen. Not who is allowed to do it. How much of it there will be. Change requests arrive at a certain rate because a certain number of people are typing them. On-call rotations are sized for what tends to break in a week, and that number has been roughly stable for as long as anyone has measured it.
Nobody chose that rate. It emerged, and everything else was built around it.
Inherited. From When feedback misses its window, energy. A correction only governs if it arrives while the system is still recoverable. Applied to. Agents operating inside a company's engineering and operational systems. The question. What happens when the actor gets faster and the loop around it does not?
The rate limiter nobody designed
Consider an engineer with write access to ten thousand configuration files. On paper, capable of changing ten thousand configuration files. In practice they change six, because there is a meeting at eleven, because they want lunch, because after the fourth one they start wondering whether they have understood the pattern correctly, and because somewhere in the back of their mind is a memory of what a bad afternoon costs.
None of that is a control. None of it appears in any policy document, and no auditor has ever asked to see it. It is an accident of biology and attention, and for about a century every approval queue, review board and on-call rota has been quietly calibrated against it.
Grant the same permissions to something that does not get tired, does not have lunch and does not experience the fourth repetition differently from the first, and you have not widened the permission. The permission is identical, character for character. What you have removed is a limiter that nobody knew was load-bearing, because nobody had ever written it down.
Project OT
In January 2026, at his annual leadership retreat in Hawaii, Mark Zuckerberg and Meta's senior executives began planning what became known internally as Project OT, for Organization Transformation. Reuters investigated it on 26 August, drawing on scores of internal documents and recordings and more than twenty people with knowledge of the effort.
The ambition was to make Meta AI-native rather than AI-assisted. An internal document called the AI-Native Playbook set out the shape: product teams of ten to twenty becoming pods of three to five, job titles giving way to a flexible builder role, layers of middle management removed, some scenarios contemplating teams sixty per cent smaller. Agents would perform substantial portions of daily employee work while smaller groups of skilled people supervised them.
By March, according to Reuters, infrastructure teams were already posting internally about reliability warning signs caused by the AI coding surge.
And then, in April, an internal post recorded that unchecked AI agents were performing large-scale, disruptive actions that humans are unlikely to execute.
That is the most precise description of this problem I have found anywhere, and it was written by somebody inside a company watching it happen.
Note what it does not say. Not that the agents were wrong, or exceeded their permissions, or did anything forbidden. That they were doing things at a scale people would not have attempted. That is a claim about quantity rather than correctness or authority, and no permission model in common use has a way to express it.
What the numbers show, and what they do not
In early June, Meta's chief technology officer posted internally that code changes to the platforms and infrastructure employees use on the job were up 220% year over year. Changes resulting in features actually reaching Meta's users were up 36%. That is a striking gap for a company to measure about itself, but it describes employees using AI to generate code rather than agents acting autonomously, so it illustrates amplification rather than evidencing anything about agents.
Then the harder numbers. Major technical and security incidents rose 40% from the previous year, and the time employees spent resolving them rose by as much as 70%. Reuters presents these immediately after the April post, as the result of it. I am not going to repeat that construction. The internal posts do not say it, Meta declined to comment on them, and the same months contain a ten per cent layoff, teams restructured into pods, management layers removed, and employee sentiment falling from 74% to 55% favourable. Any one of those raises incident rates on its own.
So the incident figures belong here as correlation with the confounders named, and the argument has to stand without them. It does. The April post is the evidence, and what it describes is a property rather than an outcome.
The loop was tuned for people
This is the same failure that took down the Iberian peninsula, with one variable moved.
When feedback misses its window looked at a grid where the correction mechanism existed, was correctly sized, and was available throughout. What defeated it was time. The disturbance moved faster than the response meant to contain it, and the loop was left intact and governing nothing. Nothing about that control had changed. What changed was the speed of the thing it was supposed to control.
Every review process, approval queue and change board inside an organisation is a control loop with a response time. A pull request review takes a day. A change board meets on Tuesdays. An incident review happens after the incident. Those intervals were not derived from first principles; they were set against how fast work used to arrive, which was set by how many people were producing it.
Put an actor into that system that produces work an order of magnitude faster and none of those loops needs to fail in order to stop governing. They continue operating at the speed they were built for, correctly, while the thing they supervise moves past them.
Which means the control question is not the one most organisations are asking. It is not whether this actor may perform this action. It is how much of it, how fast, before something else has to happen.
A quantity, not a switch
Here is where this publication's own vocabulary has been incomplete, and I include the first eleven articles in that.
Autonomy is not a state a system is in or out of. It is a quantity, and the engineering question has never been whether to grant it but how much, under what conditions. Both domains in Act II that had properly worked this out arrived at the same answer, and both expressed it as a number.
Industrial robotics permits a person to work inside a live cell and caps the machine at 250 millimetres per second while they are there, slow enough to step away from. Uncrewed vessels of a certain size, under a temporary British exemption, may run at up to six knots under constant supervision by a human able to take control at any time. Neither is fully autonomous, neither is supervised action by action, and both are semi-autonomous by design, with the design living in the number.
Managed autonomy, not autonomous AI set out four elements: permission, approval, audit trail, kill switch. Three have gone largely untested across this act, because permission has absorbed the attention. But permission answers one question only, whether an action is available to an actor. It says nothing about the rate at which it may be exercised, and an unlimited number of individually permitted actions is not a bounded system.
A rate limit is precisely where the other three elements stop being optional. Something has to notice the threshold being approached, which is the audit trail. Something has to happen when it is crossed, which is approval or a stop. Without those, a rate limit is a number in a document, which is where this series came in.
The loop that closed, and what closed it
On the night of 19 May, hours before the first round of layoffs went out, Zuckerberg conferred with senior leaders and called off planning for a second company-wide restructuring intended for November. The first wave proceeded the next day, cutting about ten per cent of the workforce. Reuters, with access to internal documents and more than twenty sources, could not determine what caused him to reverse course.
I find that more useful than a tidy account would be. In an article about feedback loops, here is one whose output is visible and whose mechanism is not. A correction occurred, six weeks before any public acknowledgement, and the best-sourced investigation available could not establish what signal produced it.
The acknowledgement came on 2 July, at a town hall Reuters heard a recording of. Zuckerberg told employees that the trajectory of agentic development over at least the previous four months had not really accelerated in the way they expected. He said the executives had been super optimistic when they planned the restructuring in January and February.
That last phrase is the honest one. The plan rested on an estimate of how much work agents would produce, and the estimate was wrong in both directions at once. Less useful output than expected, and more disruptive action than expected, from the same systems.
Be exact about what closed this loop. It was a productivity judgement, not a safety one. Meta measured that it was not getting the returns it had planned for and changed direction. That is a functioning organisational feedback loop, and the first control in this act that held. But the variable it controlled was delivery, not risk.
What was actually removed
The public record does not establish that the agents exceeded their permissions. Nor does it establish that every action they took was intended. What it establishes is scale: Meta's own internal description was of actions humans were unlikely to execute.
What had been removed was something nobody had installed. The rate at which a large engineering organisation changes itself had been set, for as long as such organisations have existed, by the number of people available to change it. Every control built on top inherited that assumption without stating it, and it held so reliably for so long that it stopped looking like an assumption at all. Then it stopped being true, and the controls went on operating exactly as designed, at exactly the speed they were designed for.
A permission describes what an actor may do. It has never described how much.
Sources
Reuters, Mark Zuckerberg had a bold plan to replace Meta staff with AI. Here's how it imploded, 26 August 2026
Recording of Meta town hall, 2 July 2026, as reported by Reuters
OSHA Technical Manual, Section IV, Chapter 4, on reduced speed in manual mode
MGN 705 (M) Amendment 1, remotely operated unmanned vessels of 2.5 to under 4.5 metres, MCA