Are we missing something? Is AI building a house with many competing thermostats?

I’d always assumed that more feedback loops meant better control, and faster / smarter / optimal operations.

But what happens when each system has its own idea of what “smart” or “optimal” even means?

Are we, in fact, optimising our way into instability and inefficiency?

Could hundreds of competing feedback loops be automating misalignment faster than ever before?

These are just a few of the questions I’d like to pose to you, the AI experts, the architects, the readers, the many who are far, far smarter than me.

I’m looking forward to learning from your insights.

.

Do we switch from “more feedback loops” to “too many thermostats”?

Ever since I first learned about fuzzy logic and AI back at uni in the 1990s, “more feedback” or closed-loop sequences felt like an obviously good thing.

In control theory, in OSS, or in network operations, adding more closed-loop responses seemed like ways to reduce lag, correct errors faster and move closer to our optimised intent targets.

If we could sense more, decide more and act more often, surely the system would become more stable, more efficient, more intelligent. Closer to an optimal level (whatever “optimal” was) faster and for longer.

I still have images of damping effects in my mind analogous to suspension in vehicles (like the one below from restackor)

But you could say that mental model made sense in simpler environments. A limited number of well-understood loops. Clear boundaries. Humans still very much in the middle.

But I’m now wondering whether all the talk about agentic AI-based autonomy changes the game.

AI-driven tools are no longer just passively reporting or occasionally nudging. There’s talk of there being hundreds, even thousands of them, optimising in real-time.

They are acting, continuously and independently, based on their own definitions of “good”. They are tuning, scaling, rerouting, reprovisioning and healing, often at speeds and volumes that humans would never keep up with. Certainly at a complexity level plus speed that we’ll never keep up with.

So the assumption I carried, more loops equals better control, suddenly feels shaky. What if, at some scale, more loops stop adding control and start eroding it?

.

What happens when every system sets its own “optimal”?

But here’s where my mind was blown. Partly because of the possibilities of what could go wrong. But also partly because I don’t have the competence to really understand whether it would or not.

So let me describe my fears in terms of the way my feeble mind works.

Imagine a very simple house with two devices: a heater and a cooler:

  • The heater has a thermostat set to 23°C. Its job is to heat up the room whenever the temperature falls below 23°C
  • The cooler has a thermostat set to 20°C. Its job is to cool down the room whenever the temperature rises above 20°C

Each device has a perfectly reasonable goal….

  • The heater is great at making a cold house comfortably warm.
  • The cooler is great on a hot day here in Australia, trying to keep things cool.

But turn on both (like my kids sometimes do), without any coordination (ie. without my wife or I telling the kids to turn the bathroom heater off on a warm day), and the two systems are effectively at war.

As the heater pushes the temperature up towards 23°C, the cooler insists on dragging it back to 20°C. Each is “smart” in isolation. Together, they create instability, wasted energy and a room that never really settles.

Now map that onto a modern, AI-heavy environment such as a network being controlled via Autonomous Operations (AO) mechanisms. They’re not just optimising for temperature. And there’s not just 2 actors like our thermostat example.

Across layers of a network, or across any complex digital system, we have multiple loops:

  • One optimiser trying to minimise cost

  • Another trying to maximise utilisation

  • Another trying satisfy customer orders

  • Another trying to reduce CAPEX on network build
  • Another trying to hit some vendor-specific quality metrics like QoS, jitter, etc

  • Software defined networks / infra trying to juggle resources
  • Others trying to optimise for environmentals in the cabinet/DC/comms-room like temperature, humidity, etc

  • The list can go on endlessly

Each loop may be configured with different KPIs, target thresholds, and reward functions. Each might be “right” from its own point of view.

But when they all act at once, what does “optimal” even mean at the system level?

When two or more “smart” systems disagree, who decides which version of “smart” takes priority? What “temperature” do we actually want it to be? My choice, or my wife’s? (We already know the right answer to that question 😉 )

.

How many hidden thermostats are in our stacks already?

There’s another layer that makes me uneasy.

Some feedback loops we at least know about. They’re built internally, so “temperature setting” and configuration rules are well known to the operator.

However, some are hidden inside vendor “black box” systems like RAN controllers. We’re increasingly seeing “black-box” controllers:

  • Vendor self-optimisation tools in EMS / NMS / VIM

  • Proprietary AI-driven features baked into platforms

  • Closed-source algorithms that act on data we may not even see

  • Optimisation solutions inside OSS/BSS

.

We might see their effects. A parameter changes, a route is adjusted, a resource is scaled, but we don’t ever understand their inner logic. We can’t see their “thermostat setting”. We can only infer that something somewhere decided to nudge the system.

Regardless of whether the control mechanisms are known or unknown, I find myself asking: how many thermostats are already operating inside our “house”?

How many of them are visible, and how many are hidden? How often are they making adjustments?

If we can’t truly have an inventory of our controllers, how do we reason about their interactions or potential to go nuts?

Surely the heater and cooler manufacturers never collaborated, so who has the responsibility for any interoperability testing? Was there even any interop testing done or were they simply tested by their buyers in isolation? If there was interop testing done, was it reflective of production-like scenarios?

As we discussed in Telco is a Circus with Thousands of Balls in the Air, we have 3 layers of control:

  1. Optimising each juggler (ie optimising the performance of each juggler)
  2. Optimising each juggler chain (ie optimally getting one ball / transaction from beginning to end)
  3. Optimising the overall performance of the entire circus (ie all results of all juggler chains and jugglers are as best they can be)

.

Do we need a master thermostat, an intent layer, or something else?

This leads me to further questions I don’t feel qualified to answer:

Do we need a master controller? And how would it work?

In thermostat terms, imagine a master device that says, “The house should optimally be 23°C, but am comfortable with it being around 21°C.” The master controller doesn’t set a specific temperature. Instead, it tells the heater and cooler, “You operate within this band. Do not aim for your old hard limits. Work together within these constraints.”

But here’s the next problem. The master controller doesn’t directly heat or cool the room itself. It has to talk to the heater and cooler to achieve those objectives.

Even if the heater and cooler have APIs / interfaces that allow external inputs (which many legacy units won’t), are they using a standardised control protocol? Do they allow for a temperature range or just a single target number?

In more technical terms, you might call the master controller an intent layer or an intent broker. Something that:

  • Understands the overall objectives at a system level, not just the heater or the cooler

  • Translates those into ranges and constraints for individual loops

  • Arbitrates when local optimisations clash

  • Knows enough about the heater and cooler to talk with any past / present / future air processing units via their disparate APIs

.

But there are obvious questions and risks that follow:

  • Would a master thermostat really reduce conflict, or just become one more feedback loop in the crowd?

  • How much centralisation is viable / sensible, and how much undermines the benefits of distributed intelligence?

  • Is it feasible to manage everything from a single controller or is do we need to spread the load? Do we need it to be highly resilient?
  • What kind of standards or shared language would be needed so independent systems can understand and respect common intent?

I don’t know the right answers here. I’d love to hear from you if you do!

Regardless, it feels like a series of questions we need to ask before we blindly keep adding more and more control loops.

.

Open questions for the AI and architecture community

So I’ll finish with questions rather than conclusions, because I don’t have the answers:

  • At what point does adding more autonomous feedback loops stop helping and start hurting system performance?

  • How do you detect that you have entered the “competing thermostats” regime? What are the tell-tale symptoms?

  • Do you believe in the idea of a master thermostat or intent layer, or is there a better pattern for coordinating many independent loops?

  • How do you deal with black-box controllers in your architecture? Do you constrain them, wrap them, monitor them differently?

  • Are there examples from other domains (power grids, aviation, finance, distributed computing) where this problem has been tackled more rigorously? And solved already?

I’m very aware that I’m poking at the edges of disciplines like control theory, AI safety and complex systems where many of you are far more experienced than I am.

If you have patterns, warnings, better metaphors or complete disagreements with this framing, I would love to hear them. My fear is that we are quietly building a house full of competing thermostats. My hope is that we can design (or already have designed) something more coherent.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.