Closing the Loop with AI
A Systematic Way to Combine Humans and AI in Management
Oliver Grasl
23.7.2026
This post takes a systems-thinking perspective on how to combine human and artificial intelligence to manage an enterprise better — and turns it into a systematic method you can apply to your own organisation.
The Management Control Loop, from First Principles
A question that has occupied my mind for some time is this: how can we make enterprises — their business models and market strategies, their operating models, their day-to-day operations — amenable to computational approaches, and to Generative AI in particular? And, more importantly still, how can we make the decision-making and management of a company amenable to AI?
To get at that, I want to take a step back and look closely at the control loop that underlies every decision and action we take. The simplest version I could arrive at is this:
Any decision is triggered by a gap between where we are now and where we would like to be. We observe that gap, we decide, we act, and then we observe again — to see whether the action moved us closer to where we wanted to be. Then we go round again.
That single loop is the atom of management. And an enterprise is nothing but loops within loops: strategic loops that set direction, a great many operational loops that run processes and organisations, and — underneath it all — the personal loops that govern our daily work.
Cybernetics, the science of control and communication that gave us this way of seeing, offers two laws worth holding onto. The first is Ashby's law of requisite variety: a controller needs at least as much variety as the system it steers. This is the deepest reason AI matters for management — it lets the controller keep pace with a world grown too complex to steer by hand.
The second goes further. Conant and Ashby's good regulator theorem states that every good regulator of a system must contain a model of that system. To steer an enterprise well — whether the controller is a management team or an AI — you have to carry a model of it inside the loop.
This old cybernetic law has just been given a striking modern proof on the AI side: in General agents contain world models, researchers at Google DeepMind show that any agent able to handle a sufficiently diverse range of goal-directed tasks must have learned an accurate predictive model of its environment — and that the model grows more accurate the more capable the agent becomes. The good regulator theorem, reborn for the age of AI agents.
That is not an analogy we reach for after the fact; it is the reason we built Metapad, and we will come back to it below.
Managing these loops well is hard even without AI. So before we bring AI into the picture, we have to be clear about what a loop is actually made of. Behind the everyday example of a thermostat controlling the air conditioning in a room, there are six elements — and naming them gives us something to reason with:
- Reference — where we want to be. On the thermostat, the temperature you set.
- Sensor — how we know where we are. The thermometer.
- Comparator — the size of the gap between the two.
- Controller — the logic that decides what to do about the gap.
- Actuator — the thing that acts. The compressor that cools the air.
- Feedback — measuring again, and closing the loop.
For a thermostat, all six are trivial. In an enterprise, every one of them is hard — and each is hard in its own characteristic way. It is worth walking through them, because this is where the framework earns its keep: it tells you why your loops misbehave, and where AI can help.
Reference — the fuzzy goal. Defining where a company wants to be is genuinely difficult. Shared objectives have to be negotiated across many people who often mean different things by the same words. This is precisely why methods such as Objectives and Key Results exist.
At transentis our approach has always been to model both the current and the desired state of an enterprise, gathering the picture from every relevant stakeholder.
This is the good regulator theorem made practical: a good controller needs a model of the system it steers, so we build one — and, to make that model usable by an AI as well as by people, it has to become a shared context with an API. That is exactly why we built Metapad: to make an enterprise computational and put its shared context — the model that both human and artificial intelligence steer by — within reach of both.
Sensor — blind, or blind for too long. Knowing the current state of an enterprise means gathering an immense amount of information, and that gathering itself takes time. Take something every company must do: assess its own financial state. Even here, many organisations run at least a month behind, often much more. Getting to a daily, near-real-time picture is genuinely hard. For a loop to be automatable, the sensor has to be automatable too — which means an enterprise-level API that reports the current state without the lag.
Comparator — the gap nobody computes. On a thermostat the gap is obvious. In an enterprise, someone actually has to bring the reference and the sensor together and compute the difference — and very often nobody does. This is one of the quiet places AI adds value: continuously surfacing the gap that no human had the time to calculate.
Controller — tacit decision logic. Deciding what to do about a gap draws on judgement that usually lives, unwritten, in people's heads. AI can propose actions here — but only if the reference and the state have been made explicit enough for it to reason over.
Actuator — the lossy handover A thermostat cools the air directly. An enterprise hands the decision from the people who decide to the people who act — and intent leaks away in the handover. To automate an action you have to encapsulate it behind an API, the way control theory encapsulates an actuator, so that it can be triggered cleanly.
Feedback — the open loop. This is the hardest step of all, and the most neglected. Nobody really enjoys following up. So actions get deferred, done half-way, or quietly dropped, and the loop is never truly closed. What makes this worse is that enterprise actions take a long time to show any effect, and it takes many small actions to move an enterprise at all. Each one feels too minor to chase — yet their effect compounds, which is exactly why chasing them matters.
And here is the point I want to draw out, because it reframes what AI is for in management. We tend to imagine AI's contribution as the clever part — the deciding. But the element enterprises fail at most consistently is the dull part: closing the loop. An AI does not get bored, does not defer, and does not forget to follow up. Its most valuable gift to an enterprise may be the least glamorous one — that it tirelessly closes the loops we leave open.
We can gather these characteristic failures into a short diagnostic list. When a loop misbehaves, it is almost always one of these:
- Blind sensing — you don't know the current state, or you learn it too late.
- Politicking — the facts are on the table, but the decision is driven by internal agendas rather than by the evidence. The loop still turns; it is simply steering by a goal no one has stated out loud. Where blind sensing means the controller cannot see the state, politicking means it chooses not to act on it.
- Fuzzy reference — there is no shared, explicit goal to steer towards.
- Lossy handover — intent is lost between the people who decide and the people who act.
- Open loop — nobody follows up, so the loop never closes.
- Delay and weak signal — effects lag, each action feels too small to matter, and the compounding is ignored.
There is a striking exception to all of this, and it is worth pausing on, because it looks like the opposite of everything above. Some of the best-run loops in any organisation run on pure instinct — a team that reacts without meetings, without dashboards, seemingly without process, and gets it right. When this works, it is not because there is no model. It is because there is a shared mental model, so well-worn that people can act on it instinctively — the good regulator is present, it is simply carried tacitly, distributed across the people involved. In a sense this is the ideal state: the loop is so internalised that everything just flows. It is also the hardest to reach; it takes years of shared practice to earn.
And it is dangerously fragile. Because the model lives in specific heads rather than on any shared surface, the loop breaks the moment a key player leaves — the model walks out of the door with them, and often no one realises how much of the loop that one person was holding together until it stops working.
This is the deepest argument for making a loop explicit: not to replace instinct with process, but to make the shared model durable — resilient to turnover, teachable to newcomers, and, as it happens, legible to an AI.
Making the model explicit is how you keep the good regulator when the regulator itself changes shape.
Two things follow from all of this. First, a loop can only be automated once its elements have been made explicit — you cannot put behind an API a reference, a sensor, or an action that lives only in someone's head.
Making your loops computational is therefore the real work of getting an operating model ready for AI. Second, the framework is diagnostic: it tells you which element is failing, and therefore where a human, an algorithm, or an AI should sit. With that in hand, let us watch the loop in action.
A Loop That Automates Well: Software as a Service
With the anatomy in hand, let us watch the loop in action — and start where it behaves best, because that tells us what "good" looks like before we look at where it breaks down.
Software engineering is the obvious place to begin. AI has made its most visible progress here, and the reason is not that programmers are special — it is that the software loop happens to have crisp versions of all six elements. The current state of a system under development is captured almost perfectly by its code base. The reference can be written down: use cases, user stories, requirements stated so they can be measured. And the sensor is exceptionally good — does it compile? is a question answered in seconds, and a suite of automated tests gives an unambiguous, machine-readable verdict on whether the system does what it should. When your sensor and your reference are both this sharp, the comparator is trivial and the loop almost closes itself.
That gives us the innermost loop — call it the build loop:
- Reference: the next feature to implement, expressed as user stories and test cases.
- Sensor: which features are implemented and passing, which remain or have broken.
- Comparator: the failing tests and the backlog — the gap between them.
- Controller: decide what to change and which tests to add.
- Actuator: write the code, build the system, run the tests.
- Feedback: the test results feed straight back into the sensor.
That loop, on its own, is enough to build software — and because every element is explicit and machine-readable, it is the part AI now runs largely by itself.
But a build loop only answers "are we building the thing right?" It says nothing about "are we building the right thing?" — and that is a second, outer loop: deciding which features to build. This one is harder, because its reference is set by people rather than by a test file, but it can still be defined cleanly:
- Reference: a prioritised picture of what users actually need.
- Sensor: how users use the product, what they ask for, what surveys and support tickets reveal.
- Comparator: the gap between what users need and what the product does today.
- Controller: decide which use cases to flesh out next.
- Actuator: turn the chosen candidates into specified user stories that fill the build loop's backlog.
Can this be automated? A good way, yes. Feature requests can be gathered through a form on the site and through surveys, clustered automatically, and drafted into first-pass user stories — which people and LLMs then refine together.
Notice the sensor has already grown fuzzier than the compiler's: "what users need" is inferred, not measured, so this loop is a natural home for AI-augmented work rather than full automation.
Spin outward once more and we reach commercial viability: are we actually making money, and which feature would make us more?
For an online service this is surprisingly tractable, because revenue per user and per action is known, and — with good cost tracking — so is the cost of building and running each feature.
The sensor here is money, and money is countable on both sides — which lets us rank features by the profit each one actually contributes, price them accordingly, and drop the ones that cost more than they return.
The hardest of the SaaS loops is the outermost: growth — acquiring new users at all. Identifying the right prospects is the difficult part, followed by reaching them, earning their interest, and reading their response. Yet even this loop can be defined and measured, which is exactly why automated outbound and inbound marketing have become such a fertile field for AI.
Step back and a pattern emerges. As we move outward — from code, to product, to revenue, to market — the loop does not change shape; the same six elements recur at every level. What changes is the quality of the sensor and the sharpness of the reference.
The compiler is a perfect sensor; what users need is a fuzzy one; "who might become a customer" is fuzzier still. Automatability tracks the crispness of the sensor and the reference, not the importance of the loop. That single observation is what lets us reason about a domain where the loops are far less obliging.
The diagram below shows how these loops interact:
The dashed arrows are the handoffs — where one loop's output becomes another's input: the build loop's implemented features carry an operating cost, the growth loop's users generate the usage, and the profitability loop sets the price. That last handoff is why the profitability loop looks slightly different here than it did on its own. Seen alone, it steers profit = revenue − cost. Seen in company, revenue itself breaks apart — revenue = price × usage — so the loop's own lever is price, while usage arrives from the growth loop and cost from the build loop. It is the same loop drawn at two resolutions: profit when it stands alone, price when we can see what profit is made of.
A Loop That Resists Automation: Delivering Custom Software
To see why this matters, keep the industry the same but change the game. Instead of a product we own and evolve, take the delivery of a bespoke software project for a client. The technology is identical; the loop is not. This is a case where automation gets much harder — and, because the framework tells us where it gets harder, it is also where the framework is most useful.
Walk the same six elements and watch nearly every failure mode from our list appear at once:
- Reference — fuzzy, and moving. There is no test file for "the client is satisfied." The real requirements are discovered during the project and change as they are discovered. The goal you are steering towards keeps moving, and different stakeholders hold different versions of it.
- Sensor — blind and political. "Are we on track?" has no compiler to answer it. The infamous "90% done" can persist for half the project. The true state lives in people's heads and in the temperature of the client relationship — expensive to read, and easy to read wrong.
- Comparator — contested. Because both the reference and the state are soft, the size of the gap is a matter of opinion, and the opinions that matter most are not always the loudest.
- Actuator — lossy. The actions are carried out by teams coordinating with each other, moving tacit knowledge that was never written down. Intent leaks at every handover.
- Feedback — slow, noisy, deferred. Effects show up at milestones, or at the retrospective when it is already too late. The loop closes rarely, and often not at all.
The naïve conclusion is "so AI can't help here." That is exactly the conclusion the framework saves us from. It does not tell you *whether* AI helps; it tells you *where*.
First, the innermost build loop is still the same crisp loop it was in the SaaS case. Inside a bespoke project the code still compiles or does not, the tests still pass or do not — so AI runs that inner loop just as well here as anywhere. The gains from AI on delivery are real; they are simply concentrated in the inner loop, not spread evenly across the project.
Second, the outer loops — scope, expectations, whether the thing is on track — stay with humans, because they turn on judgement, negotiation and trust. But staying human is not the same as staying illegible. You can still make the reference and the state explicit: model the requirements, the scope, the milestones and the risks as a shared, computational context. Do that, and the comparator becomes visible, AI can take on the parts it is good at — drafting the status, flagging scope drift, surfacing a risk before it lands, keeping the follow-up honest — while people keep the controller. The loop stays human-led, but it stops being an open loop.
This is the good regulator theorem showing up a second time, and it is the real difference between our two examples. Software as a service arrives with its model built in: the code base is the sensor, for free. Custom delivery hands you no such gift, so you have to construct the shared context deliberately. That construction is the work — and it is what Metapad exists to make possible.
From Two Examples to a Method
Both examples are the same procedure applied with different amounts of luck. Written out, that procedure is the method:
- Map the loops. Identify the control loops that actually run your enterprise — strategic, operational, personal — and choose the ones that matter.
- Decompose each into the six elements. Reference, sensor, comparator, controller, actuator, feedback. Being forced to name each one is itself diagnostic: the element you cannot fill in is usually the element that is failing.
- Draw the human/AI line, element by element. For each, decide whether to fully automate it (a fixed algorithm or an LLM), keep a human over an AI-prepared draft (AI-augmented), or leave it purely human. The crispness of the sensor and the reference tells you how far you can safely go.
- Make it explicit, then live the loop. Build the shared model the loop needs — its reference and its state as computational context — and run the loop by hand first. Don't automate too early; let it prove its worth. This is also how you build the model a good regulator requires when the domain won't give you one for free.
- Automate what has earned it. Once a loop has proven itself, push its automatable elements as far as they will go — and give AI the job humans do worst: closing the loop, every single time.
None of this is really about AI. It is about seeing your enterprise as a set of loops, and doing the unglamorous work of making each one explicit enough to steer. That work has always paid off — it is simply that, done properly, it now leaves your operating model ready for AI as well as for the people who run it. A good regulator needs a model of the system it regulates. Building that model, and closing the loops it reveals, is the whole game.
Services
Resources
All Rights Reserved.