The world feels profoundly out of balance.
We’re building ever more complex digital ecosystems (resource-hungry agentic AI, autonomous agents, systems of systems) whilst simultaneously ignoring systematic failures in the natural ecosystems that underpin everything. We struggle to find common ground on our major challenges, with polarisation and hyper-personalised filter bubbles making it harder for people to collectively see problems, let alone organise to address them.
Technology used to feel exciting, visionary, inspirational. Now too often it feels extractive, exploitative, creating fears of a dystopian future. Many in the tech industry are disillusioned by their direct and indirect impacts. They crave something more hopeful.
Earlier this year, thanks to Selena Evans of Ara Governance Advisory pointing me at them I’ve been reading Stafford Beer’s 1973 Massey Lectures, published as Designing Freedom. It’s almost eerily prescient. Beer was writing about institutional collapse, about systems that can’t adapt fast enough, about computers being used to “make lousy plans more efficiently lousy.” He was warning about what happens when we use powerful tools to reinforce existing dysfunction rather than redesign for viability.
Fifty years on, his diagnosis feels pretty bang on as do many of his proposed approaches…
The Core Laws (In Plain English)
Beer’s cybernetics can sound intimidating, but the core principles are straightforward.
1. Complexity Must Be Matched
Beer refers to “Ashby’s Law of Requisite Variety.” In plainer terms: a controller must have at least as much complexity as the system it’s trying to control.
If your governance framework can handle ten scenarios but reality throws a hundred at you, you’re going to lose. The mismatch doesn’t just cause inefficiency; it causes instability. The system produces states the controller can’t recognise, can’t learn from, can’t respond to.
This is why heavyweight governance frameworks fail. They attenuate variety (reduce complexity) by forcing everything into predefined categories. But reality doesn’t fit the categories. The variety leaks out around the edges, and the framework becomes a fiction everyone pretends to follow while actual decisions happen elsewhere.
2. Recovery Speed Matters More Than Robustness
Beer’s “relaxation time” principle: systems need time to stabilise after disruption. If disruptions arrive faster than the system can recover, you get permanent instability.
This isn’t about building thicker walls. It’s about recovery velocity. A system that can bounce back quickly from minor perturbations can handle a lot of chaos. A system with slow recovery time will eventually collapse, no matter how robust its individual components, because the disruptions pile up faster than it can process them.
Sound familiar? This is the lived experience of most enterprise architecture teams right now. The backlog grows. The technical debt accumulates. Each “strategic initiative” arrives before the last one has bedded in. The system never reaches equilibrium.
3. You Cannot Regulate What You Cannot Model
Every regulatory function (governance, oversight, management) contains an implicit model of what it regulates. If that model is wrong, the regulation is worse than useless; it’s actively harmful, because it gives false confidence.
The model is supposed to be simpler than reality. That’s its job. It attenuates variety by design, preserving what matters and discarding what doesn’t.
The question isn’t whether to simplify. The question is how to simplify, and who decides. Are you simplifying in ways that preserve the signals that matter? Or are you optimising for what’s easy to measure while ignoring what’s important?
4. You Have Exactly Two Options
When complexity is mismatched (and it almost always is), you can either:
- Reduce complexity in the system being controlled (filter, constrain, simplify), or
- Amplify the controller’s capacity to handle complexity (delegate, distribute, automate)
Most organisations do both badly. They install amplifiers where they need filters and filters where they need amplifiers. They centralise decisions that should be distributed and distribute decisions that need central coordination. They collect all the data (amplifying variety on the wrong side) while applying rigid rules that can’t handle the variety they’ve collected.
Beer’s insight: get the amplifiers and attenuators on the right side of the equation.
The Minimum Data Principle
Here’s where Beer gets radical, and deeply relevant to the current AI moment, and our recent trend for collecting everything - aka big data.
His vision was explicitly about minimal data, not maximum data.
The argument runs like this: if your model is good, most incoming data simply confirms what you already know. It’s noise. The only signals worth processing are exceptions, the things that deviate from expected patterns. Everything else can be discarded at source.
This is the opposite of the “collect everything, analyse later” approach that has been dominating enterprise data strategy (requiring us to pay for more storage and compute…). Beer would call that a category error: using variety amplifiers (AI, storage, compute) on the wrong side of the equation, generating more complexity rather than absorbing it.
“But we need all that data for ML training!” I hear you say. Beer’s response would be sharp: you need good models, and most training data is noise (often biased and toxic to boot). We’re already seeing this play out. Model collapse is documented: systems trained on AI-generated content progressively deteriorate. The internet is increasingly being contaminated with synthetic content. Clean, human-generated, domain-specific data becomes more valuable precisely because it’s scarce, not because we collected everything.
The practical implication: you don’t need a data lake containing every transaction. You need a model that knows what normal looks like, and alerts that fire when reality deviates from expectation. The data minimisation isn’t just a privacy benefit; it’s a fundamental requirement for viable systems. And yes, it’s also a sustainability benefit: less storage, less compute, less energy. The cybernetic argument and the environmental argument converge.
Nested Autonomy
Beer’s “levels of recursion” concept helped refine our ecosystem architecture thinking.
Each viable system contains viable subsystems, each operating autonomously within constraints from the larger system that contains it. The same organisational pattern repeats at each level, just with different scope.
To me this validates what feels fundamentally broken in modern Western society: the economy isn’t the top level. It’s embedded within systems that constrain it.
- Individual
-- Team
--- Department
---- Organisation
----- Sector
------ Economy (markets, production, consumption)
------- Human Society (civilisation, culture, institutions)
-------- Natural Ecosystems (forests, oceans, watersheds, atmosphere)
--------- Biosphere ← the foundation everything rests on
Beer would call the lower layers in this stack higher levels of recursion. I find it clearer to draw them as foundations, because that is what they are: every level rests on the ones beneath it. (Explore the interactive version.)
Mainstream economics treats the environment as an “externality” to be accounted for (if at all). Beer’s recursion principle inverts this: constraints flow from the larger system to the smaller one it contains. The ultimate constraints aren’t policy decisions; they’re physics, chemistry, and ecology.
In Beer’s terms, we’re violating Ashby’s Law in both directions at the civilisational scale:
- Attenuating variety we shouldn’t: through destroying the biodiversity and complexity that makes natural systems resilient (monocultures, extinction, simplification)
- Generating variety natural systems can’t absorb: exceeding planetary boundaries for carbon, nitrogen, waste, heat
The relaxation time of climate systems is measured in decades to centuries. We’re perturbing them on timescales of years. The system cannot stabilise. This is Beer’s wave metaphor playing out at planetary scale: looking stable until it isn’t, then catastrophic collapse.
The critical insight for architecture: central coordination should specify the pattern of how complexity is managed, not the content of decisions. But “central” here doesn’t mean your enterprise architecture team. At the foundation, it means planetary boundaries. The constraints carry up through every layer built on top.
This is API-first design scaled up. This is defining contracts and letting subsystems choose their own implementations. But the ultimate contract is with the biosphere. The moment any level tries to ignore the constraints of the layers it rests on, it’s not being autonomous; it’s being unviable.
For ecosystem architecture, this means: don’t try to control everything from the centre. Define the constraints at each level, then let the subsystems self-organise within those bounds. If you can’t describe what makes a viable node at one level, you can’t compose them into a viable system at the next. And if your economic system can’t operate within ecological constraints, it’s not a viable system, however profitable it appears in the short term.
The Bureaucracy Warning
Beer’s analysis of bureaucracy identifies a specific issue: systems that exist to produce themselves. A healthy organisational “nucleus” coordinates operations for the benefit of the whole organism. A bureaucracy coordinates operations for the benefit of its own continuation.
A simple test for this: How much of your architecture governance function exists to serve delivery teams, and how much exists to perpetuate the governance function?
Beer borrows a term from the biologists Humberto Maturana and Francisco Varela for this: “autopoiesis”, self-production. A bureaucracy accepts change, acknowledges novel conditions, makes modifications. But the changes are superficial. The underlying organisation that makes the system the system it is remains untouched. There is, as Beer puts it, “change without alteration.”
Freedom Through Constraint
The title “Designing Freedom” is deliberately paradoxical.
Beer’s argument is that freedom without structure is just noise. A system with unconstrained variety cannot stabilise, cannot learn, cannot adapt. Real freedom comes from well-designed constraints that filter variety appropriately at each level.
You’re free to make decisions within your bounded context precisely because the context is bounded. The constraints enable autonomy by making it viable.
This isn’t governance minimalism which is probably a common misreading. Beer isn’t saying “less governance is better.” He’s saying governance at the wrong level, or governance that specifies content rather than patterns, actively destroys the system’s capacity to function. The answer isn’t to remove governance but to place it correctly: at the right level of recursion, expressed as constraints that enable rather than prescriptions that constrain.
This reframes the whole governance debate. The goal isn’t to remove all governance. It’s to place governance at the right level, expressed as patterns, filtering complexity rather than amplifying it.
“But isn’t this just distributed systems theory?” Yes, in part. The patterns Beer identified map onto what we now call bounded contexts, event-driven architecture, API-first design. But Beer adds something crucial: explicit attention to the human and organisational layer. He’s not just talking about how services communicate; he’s talking about how institutions maintain viability, how bureaucracies become self-perpetuating, how freedom and control can be reconciled. The technical patterns are necessary but not sufficient.
The AI Moment
Which brings us to the current AI moment, and why I think Beer feels so relevant.
Consider the challenges I have been mapping in my sleepwalking piece and AI Autumn principles:
- Confirmation fatigue: Human review becomes meaningless theatre because AI-generated content looks plausible even when it’s wrong
- Capability degradation: Staff never develop expertise because AI does the work
- Automation overload: Systems designed for human use get overwhelmed by agentic AI
- The impending arms race: Each side deploying more AI to counter the other’s AI
In Beer’s terms, we’re installing variety amplifiers on the wrong side of the equation. We’re using AI to generate more complexity (more content, more agents, more interactions) rather than to absorb complexity (better models, smarter filtering, exception-based alerting).
“But we’ll use AI to handle the AI-generated complexity!” I hear this a lot (sometimes it’s an argument I have with myself :-). It’s the arms race I described: each side deploying more AI to counter the other’s AI. Beer would recognise this immediately as a positive feedback loop heading towards instability. You’re not solving the problem; you’re accelerating it. Each round of AI-vs-AI increases total system complexity while the human capacity to understand and intervene diminishes.
The result is systems that can’t stabilise, because disturbances (or as Beer calls them, perturbations) arrive faster than the system can recover.
What AI Should Be Doing
AI architecture (and governance) could look very different if this was applied:
-
Filter at source. If data doesn’t deviate from the model’s expectations, don’t store it. Use AI to identify exceptions, not to process everything.
-
Make models explicit. Every AI system contains an implicit model of what it’s trying to do. Make those models visible, testable, and updateable. Stop hiding them behind “it’s a black box” excuses.
-
Match autonomy to capability. A system (or team, or agent) can only be autonomous if it has the capacity to handle its own complexity. If it doesn’t, you need to either simplify what it’s responsible for or increase its capacity.
-
Design for recovery speed. If your system can’t recover faster than disruptions arrive, it will eventually collapse regardless of how robust individual components are.
-
Beware self-perpetuating structures. Any function that grows while the value it delivers shrinks is exhibiting autopoietic behaviour. It’s producing itself, not serving the system.
Principles for Regenerative Architecture
This brings us to the emerging Principles for Regenerative Architecture that the Architect Tomorrow community has been developing.
Here is where they align with Beer (he was a major influence):
Purpose Over Intention (“Judge systems by what they do, not what they’re meant to do”) is Beer’s POSIWID principle: the Purpose Of a System Is What It Does. When systems claim to “connect people” while measurably increasing isolation, POSIWID tells us their actual purpose is something else.
Ecosystems Over Enterprises maps onto Beer’s levels of recursion. The “castle and moat” mentality of optimising within organisational boundaries while treating external relationships as supplier transactions or externalities won’t work for ecosystem problems requiring ecosystem thinking.
Variety Amplification Over Attenuation is Beer’s core distinction, reframed. Systems can either simplify humans to make them easier to predict and control (variety attenuation) or enhance human capacity for self-determination and collective action (variety amplification). Note that the variety here is human: filtering the noise that reaches people is good, simplifying the people themselves is not. The dominant platforms chose the latter. I’d like to think we can choose differently even if that requires quite a bit of imagination.
Viability Over Optimisation is Beer’s homeostasis principle. Optimisation for one metric (engagement, efficiency, cost) creates fragility and externalises costs. Viability (the capacity to maintain existence across multiple dimensions over time) is a more robust goal.
Sufficiency Over Excess connects to the minimum data principle. More data, more compute, more features is not always better. Over-provisioning wastes resources; over-collection creates risks; over-complexity creates maintenance burden.
What This Means in Practice
If you’re an architect trying to apply this:
For AI Strategy
Stop treating AI as a general-purpose capability multiplier. It’s a variety handler. The question is: which side of the equation are you putting it on?
- Using AI to generate more content, more options, more complexity? That’s amplification on the wrong side.
- Using AI to identify exceptions, filter noise, surface what matters? That’s attenuation on the right side: it cuts the variety reaching you down to what your capacity can handle.
The AI Autumn framing is useful here: harvest what works (exception detection, pattern matching, content transformation with good data), drop what doesn’t (AGI promises, general reasoning claims, autonomous decision-making without oversight).
For Ecosystem Architecture
Define viable nodes before trying to compose them. What makes a team/service/organisation viable at one level of recursion? What constraints does it operate within? What autonomy does it have within those constraints?
As most Enterprise Architects recognise - focus on designing interfaces, not implementations. The centre specifies patterns, not content. API contracts, not detailed specifications. Guardrails, not prescriptions.
For Governance
How much of your governance function serves delivery teams vs perpetuates itself?
Specify patterns, not content. “This much can be spent on X” rather than “Spend it on these specific things.” Let decisions be made at the level with the most relevant context.
Design for recovery speed. If your governance process takes longer than the rate of change it’s trying to govern, it will never reach equilibrium.
Applying Cybernetic Principles
Beer ended Designing Freedom with an invitation to experiment. Not to implement his specific solutions, but to take seriously the cybernetic principles and apply them to whatever context you’re in.
The systems we design are not neutral. They extract or regenerate. They attenuate human variety or amplify it. They respect planetary boundaries or breach them. They support collective sense-making or fragment it.
As architects, we occupy positions of influence. Our decision support ripples outward, shaping what systems do, regardless of what they’re meant to do.
The technical elements of our roles are increasingly being automated. GenAI can generate code, draft configurations, propose patterns. What it cannot do is exercise judgement about whether those patterns serve human flourishing, financial or ecological sustainability, or democratic health.
As implementation (arguably) becomes commoditised, our distinctive value shifts from technical problem-solving to something harder (if not impossible?) to automate: taste and judgement. Not [just] aesthetic preference, but the cultivated capacity to distinguish systems that serve from systems that extract, architectures that empower from those that manipulate, solutions that endure from those that merely scale.
Beer’s cybernetics gives us a rigorous foundation for that taste. Not rules to follow, but principles to reason from. Sadly, I suspect that, like me until recently, not many architects are aware of cybernetics and holistic systems thinking (rather than just technical systems). As a result there will be some painful years ahead as we clean up the mess that is being built rather rapidly!
This piece draws on Stafford Beer’s “Designing Freedom” (1974), my own work on AI Autumn and responsible AI deployment, and the community-developed Principles for Regenerative Architecture. It’s part of the Ecosystem Architecture work exploring how architecture practice needs to evolve for the age of autonomous systems. The terms and laws are summarised in Cybernetics: A Quick Reference for Architects.
AI use: AI augmented this piece rather than replacing the author. Claude helped with research synthesis and drafting; the ideas, framing, judgement and any errors are mine. What aspects cause most concern for your organisation? Where do you see AI on the wrong side of the equation? Feel free to get in touch.