Ashby’s Law

W. Ross Ashby described regulation in three terms. Here they are, filled in for an invented product team in the spring after its engineers got coding agents:

Disturbances

Every change that could break a product decision. Last spring, about 30 pull requests a week, mostly from five engineers working in parts of the product they knew. This spring, about 150 a week, from the same five engineers and their agents, touching billing, permissions and data retention code that some of them had never opened.

Regulator

Two senior reviewers, a pull request template with a "product impact" checkbox, and a weekly product sync. The same as last spring.

Outcome

What ships. The team wants every change to respect what it has decided: annual plans can't be discounted, deleted workspaces are purged after 30 days, guests never see billing.

Read the three entries together and the result is easy to predict. The first one grew five times over, in kinds of change as well as count. The second one didn't change. Ashby's law, published in 1956, says that when the kinds of disturbance outgrow the regulator, the third one can't stay where it was.

Only variety can destroy variety

Ashby was a British physician and cybernetician, director of research at Barnwood House in Gloucester. His 1956 book, An Introduction to Cybernetics, sets out the idea that now carries his name in a chapter called "Requisite Variety."

He frames regulation as a game. A disturbance, D, makes a move. A regulator, R, answers with a move of its own. The pair decides the outcome. The regulator's job is to keep the outcome within a small set of acceptable values, whatever D does. Ashby works through what that takes and arrives at the law: the variety in the outcomes can be pushed down only by a matching increase in the variety of the regulator.

"This is the law of Requisite Variety," he writes. "To put it more picturesquely: only variety in R can force down the variety due to D; variety can destroy variety."

He admits that in simple cases it sounds obvious. "If, for instance, a press photographer would deal with twenty subjects that are (for exposure and distance) distinct, then his camera must obviously be capable of at least twenty distinct settings if all the negatives are to be brought to a uniform density and sharpness." Where it earns its keep is in systems too large to judge by feel. The law, he says, "though trite in the simple cases, can give real guidance in those cases that are much too complex to be handled by unaided intuition."

Two more consequences matter here. If the regulator always makes the same move, whatever happens, "the variety in the outcomes will be as large as the variety in D's moves. D now is, as it were, exerting full control over the outcomes." And a regulator can only respond to what reaches it: "R's capacity as a regulator cannot exceed R's capacity as a channel of communication."

Review gates have a fixed number of settings

Back to the invented team. Its reviewers are the camera, and their settings are the decisions they know about and can recognize in a diff. That number grows slowly. It depends on what two people were in the room for, what they remember, and how much attention a reviewer has left by the fortieth pull request of the day.

When pull requests came from five engineers working in familiar code, two reviewers were roughly enough. When agents started opening five times as many, in code nobody on the team had memorized, the disturbances outgrew the regulator. Ashby's law says the extra variety has to go somewhere, and it goes into the outcome. A discount appears on an annual plan. A deleted workspace is kept for 90 days because an agent copied a retention constant from the wrong service. Each one passed review, because the reviewer approving it had no setting for it.

The tempting response is to approve faster, and that is Ashby's unvarying regulator. A review gate that says yes to everything isn't regulating anything. At that point, in his words, the disturbance is "exerting full control over the outcomes."

Our essay on the modern product development lifecycle describes this stage of agent adoption in nearly the same terms: "the work now piles up at the same review gates, waiting on people." We've written about where that queue comes from and why the volume keeps growing. Ashby's law explains why adding effort at the same gate can't fix it. The gate's variety is bounded by what its people know and can attend to.

Amplifying regulation

Ashby didn't think the limit was hopeless. His thirteenth chapter, "Regulating the Very Large System," ends on a question about people trying to regulate very large systems with a regulator "limited to that available to the members of the species Homo." His answer is to build the regulator in stages. When "a regulator R1 acts so as to bring into existence a regulator R2," he writes, "the capacity of R2 is not bounded by that of R1." His next chapter, "Amplifying Regulation," works out what that allows.

He is careful about what that does and doesn't allow. "The law of Requisite Variety, like the law of Conservation of Energy, absolutely prohibits any direct and simple magnification but it does not prohibit supplementation." Two reviewers can't become twenty by trying harder. But they can build something else that does the regulating, and supply it with variety from somewhere other than their own heads. A designer who manages it, Ashby says, ends up "like a workman equipped with power-operated tools, able to achieve tasks impossible to the unaided workman."

Back in his chapter on requisite variety, he separates control from regulation: "Suppose the decision of what outcome is to be the target is made by some controller, C, whom R must obey." The controller decides what the target is, and the regulator holds the outcome to it.

The PDLC essay's next stage puts those two ideas together: "Review gates become rules that agents check on every change. Material decisions go to a named owner, routine ones stay with the team." The pairing is ours, not Ashby's, but it fits. The people play the controller, C, and decide. The rules become the second regulator, R2, and its variety isn't limited to what two reviewers can hold in mind.

Where Brief fits: building the second regulator

Brief is the product strategy agent. The homepage says it "captures decisions where they happen, connects them into one graph, and acts on them." In Ashby's terms, it is a way to build R2: a regulator whose settings are the team's recorded decisions, that sits where changes start, and that grows each time someone decides something.

Each recorded decision is one more setting. In the Brief app, recording a decision requires both What was decided? and Why? before Record Decision will save it, and a decision can also carry Tags and a Re-evaluate when condition. "Annual plans can't be discounted, because annual pricing is already our discount" is a setting the regulator didn't have before. Unlike a reviewer's memory, the number of settings isn't capped by how many decisions two people can keep in their heads.

The variety comes from where decisions are made. Ashby's supplementation comes from outside the first regulator, and in his biological example, "from the environment itself." The homepage says Brief "reads decisions from Slack, Jira, Confluence, and GitLab, self-hosted included." The retention rule decided in a Jira ticket and the guest permissions settled in a Slack thread can become settings without either reviewer having been there.

The regulator acts where the disturbance starts. Ashby's law also says a regulator can only respond to what reaches it. Coding agents set up with Brief search the recorded decisions before they start work, and ask Brief to check significant changes with brief_ask in check mode, which compares a planned change against existing decisions and flags conflicts. An agent about to add a discount to annual plans can meet the pricing decision before it writes the pull request, not after a reviewer misses it. People can run the same check with brief ask --mode check.

Missing settings show up as gaps. When a decision is still pending, an agent can hold. The homepage shows an agent asked to add per-seat pricing to the checkout API learning that D-241, the seat-based pricing decision, is pending, and replying: "Holding the pricing change until D-241 is decided." An open question can be proposed as a pending decision that names Who should decide?, agents can call brief_list_pending_decisions to see what is waiting, and the homepage's Friday brief "names the decision holding each late launch and who owns it." That is Ashby's controller, C: the person who sets the target the regulator then holds.

The reviewers' job changes. With the routine settings recorded and checked earlier, review can spend its limited variety on what the recorded decisions don't cover. The reviewers stop being the only regulator and become one stage of a larger one.

None of this lifts Ashby's law. The second regulator has exactly the variety the team has recorded. A decision nobody recorded is a setting it doesn't have, a check nobody runs regulates nothing, and a vague Why? is a setting that fits too many cases to be useful. Brief can't decide what the team should want. What it changes is where the team's decisions live once they are made: in a regulator that people and agents can consult on every change, instead of in the memory of two people at the end of the pipeline.

Ashby's law is unforgiving arithmetic. If the changes reaching your product grew fivefold this year, how many new settings did your regulator gain?

Objections