Closed-Loop Control Explained Simply: Why Multi-Agent Systems Need a Thermostat, Not More Agents

In two years, the buzzword has changed twice. First it was “agent loops”. Then “agent graphs”.

The diagrams got prettier. The boxes got more colourful. And the arrows started curving back upward — toward a “control plane” that rearranges the system while the work is still happening.

The idea is good. It genuinely is.

The problem is that underneath the new name sits an engineering discipline about twenty years old, which almost everyone applies by halves. And applied by halves, it produces exactly the kind of system that looks flawless in a presentation and does strange things at 3am on a Tuesday.

This article explains the idea from scratch — assuming no control theory — and then gives the six practical rules. Each with a concrete example, so you can see plainly what breaks without it.

In short: a multi-agent system that changes its own structure is a control system. To work, it needs six things: fast signals separated from slow ones, damping thresholds so it does not oscillate, provenance on everything written to shared state, a hard cost ceiling on fan-out, a deadline with a conservative default on the slow loop, and cheap routing for known cases. Without them, “the graph that rewrites itself” is a pretty diagram, not an architecture.

1. What “closed loop” actually means

Let us set AI aside for a minute and talk about heating a house.

Open loop means you run the radiator at full power for two hours, because that is what you calculated should be about right. You measure nothing. You adjust nothing. If it suddenly warms up outside, you roast. If it freezes, you shiver. The system executes a plan decided in advance and never looks at the result.

Closed loop means you install a thermostat. It measures the actual temperature, compares it against the desired one, and turns the heat on or off depending on the difference. Then it measures again. And again. Forever.

The difference between the two is not sophistication. It is that the second one sees its own result and corrects itself.

That is all there is to it. Act → measure → compare against what you wanted → correct → repeat.

A multi-agent AI system that “reorganizes itself” does exactly the same thing. It just measures error rate, cost or output quality instead of temperature. And instead of switching on a radiator, it adds a verification agent or swaps the model.

Same shape. And, unfortunately, the same traps.

2. This is not a 2026 invention. It is from 2003.

Worth stating plainly, because it changes how you look at the whole subject.

The idea of a system that reconfigures itself based on what it measures has a name and a respectable age: autonomic computing. Kephart and Chess formalized it in 2003, in The Vision of Autonomic Computing. Their loop is called MAPE-K and it has five pieces:

Now look at any modern “dynamic agent org” diagram. You will recognise those exact five boxes. The names changed; the shape did not.

So what is genuinely new in 2026? That the Plan step can itself be a language model.

And that brings a failure mode autonomic computing never had. A thermostat never invents a temperature — it can be broken, but not creative. A language model asked to decide how the system reorganizes can hallucinate the reorganization: it can “decide”, with complete confidence and impeccable reasoning, that three verification agents are needed for a reason that does not exist.

Which is why control discipline matters more today, not less.

3. Rule 1: there are two loops, not one

This is where most architectures go wrong. And they go wrong quietly, which is worse.

The temptation is to treat all signals alike: something went badly → adjust. But signals are not all alike, and the difference between them decides what you are allowed to automate.

🚀 The fast loop runs on cheap, instant signals: how long it took, what it cost, whether the tool errored, whether the response matches the required schema. You can act on these automatically, with no human — the measurement is available immediately and it is objective.

🐢 The slow loop runs on delayed, expensive or high-stakes signals: was the extracted value correct? did the deliverable pass review? did what the system predicted actually hold up?

And here is the rule almost everyone breaks without noticing:

You cannot close a loop on a signal you do not have yet.

📌 Concrete example: the invoices with the misplaced decimal

A system reads invoices arriving by email and extracts the supplier, the amount and the due date.

What the fast loop sees, across 200 invoices processed in a week:

• valid schema: 200 out of 200
• average time: 1.2 seconds
• average cost: €0.003 per invoice
• tool errors: zero

The system draws the logical conclusion — this works beautifully — and promotes the cheap model as the default for everything.

Three weeks later, accounting runs the reconciliation. On 12 invoices, the amount 4,870.00 had been read as 48,700.00.

The schema was valid. The response was fast. The cost was low. And the figure was wrong by a factor of ten.

Where was the design mistake? The system measured that it worked, not that it was right. “Valid schema” is a fast signal. “The amount matches reality” is a slow signal — it only shows up at reconciliation, weeks later. The system closed a slow loop using a fast signal.

✅ What to do instead

Keep the two explicitly separate. Fast signals get free auto-routing: retry, model swap, real-time adjustments. Slow signals promote nothing until they actually arrive — until then, the old configuration stays the default.

And for the invoices, concretely: a sample of extractions goes to cross-verification — a human or an independent second model — before you declare the cheap model “good for everything”.

A thermostat working the way that system did would conclude the room is warm because nobody has screamed in the last five minutes.

A test you can run today: take every automatic decision your system makes and ask “what measurement is this based on, and when does that measurement become available?” If the answer is “well… we infer it”, you have just found a slow loop closed with a fast signal.

4. Rule 2: topology must be damped, or it oscillates

The underlying principle is correct and intuitive: task complexity decides the number of agents, not the other way around. Simple task — collapse to a single agent, it is faster and cheaper. Ambiguous, high-stakes task — fan out to specialists and add a verification step.

The part missing from nearly every diagram I have seen is damping.

Picture a hypersensitive thermostat that fires the heat at 22.9°C and cuts it at 23.1°C. What does it do? On, off, on, off — dozens of times an hour. It burns enormous energy, wears itself out, and never properly heats anything. Heating engineers call this short-cycling. The engineering fix is called hysteresis: you refuse to react until the deviation crosses a clear threshold.

📌 Concrete example: the reviewer that appears and disappears

A system classifies support tickets and routes them to the right team.

Monday, 09:40 — a ticket lands wrongly with billing. The system reacts and adds a reviewer agent that checks every classification.

Tuesday and Wednesday — two days without errors. The system reacts again and removes the reviewer, to save time and money.

Thursday, 11:15 — another misrouted ticket. The reviewer goes back in.

Friday — the whole story repeats.

What actually happens: average response time swings between 4 and 11 minutes depending on the day. The support team cannot promise any SLA, because nobody knows whether today’s tickets go through review or not. And costs climb, because the system pays for reorganization over and over.

The mistake? The system treated one isolated failure as a signal. One wrong ticket out of 300 does not mean the model broke. It means there is variance, as there is everywhere.

✅ What to do instead

Set explicit thresholds, in numbers. To add the reviewer: at least 6 wrong classifications out of 20, in the same category, within a 4-hour window. To remove it: at least 200 consecutive correct classifications — not two good days. And whatever changes, the topology stays stable for at least 24 hours afterwards.

Those numbers are not universal, to be honest. They depend on your volume and on how expensive a failure is. But the principle holds: a single failure is noise, log it and move on; a cluster of correlated failures is signal, now you act.

Watch the symmetry too: promotion needs a threshold exactly as demotion does. Two successes are luck, not evidence. And in high-stakes domains, promotion never removes human verification — it only makes it rarer.

This is also the conclusion that falls out of the LLM agent failure taxonomy: errors do not add up linearly, they compound. A critic agent added to the loop, itself 90% reliable, can multiply error surfaces rather than reduce them. More agents does not automatically mean more reliability.

5. Rule 3: shared state must carry provenance

The industry consensus is that agents should be stateless: anything that must survive a step is written to a shared store, which every agent reads before acting.

Correct. But almost everyone skips the second half: every piece of information written there must say where it came from, how confident it is, and whether anyone confirmed it.

📌 Concrete example: the deadline that never existed

Four agents prepare a compliance report for a client.

The research agent looks up the applicable legal deadlines. On a specialist forum it finds a comment saying the deadline is 22 July. It writes that to shared state: deadline: 22 July.

The planning agent reads shared state and builds an implementation calendar starting from 22 July.

The recommendations agent reads the calendar and writes: “Top priority — only 3 days left.”

The synthesis agent writes the executive summary: “Urgent action required before 22 July.”

The report that reaches the client is perfectly coherent. Every section supports the others. The tone is confident. The argument holds together impeccably.

And it is wrong, because the real deadline was something else. The forum comment was somebody’s opinion, not statute.

What happened mechanically: a wrong value written at step 1 did not stay a local error. It became a premise for steps 2, 3 and 4. And the system defended it more and more convincingly at each step, because each new step rested on it.

It is as if the thermometer reported a temperature it never measured. The loop keeps running perfectly — and heats the wrong way, with conviction.

Research on retrieval pipelines shows how little it takes for a single poisoned source to propagate downstream — see threats across the RAG retrieval and generation stack.

✅ What to do instead

Every record in shared state carries three fields:

With that, the planning agent at step 2 sees in black and white that it is working from unconfirmed, low-confidence information. And it has two correct exits: either verify it against a primary source, or mark the entire calendar as provisional.

If shared state cannot distinguish between “I read this somewhere” and “I verified this”, you do not have a memory. You have a rumour with persistence.

Nothing becomes “fact” merely because it was written down. And in high-stakes domains — financial, legal, medical, audit — confirmation stays human.

6. Rule 4: fan-out needs a hard ceiling

“Complex task → fan out to more agents” sounds reasonable until you hit the pathological case: an ambiguous task spawns agents, which spawn sub-agents, until cost explodes.

The uncomfortable truth is that ambiguity is not always resolved by width. Sometimes width only makes it more expensive.

📌 Concrete example: “do me a market analysis”

A user writes exactly that: “do me a market analysis.”

The system judges the request complex and ambiguous — quite rightly — and applies the “complex → fan out” rule:

The outcome: €47 spent and a long document that answers nothing useful.

Why? Because the analysis was not the hard part. The request was unclear. Which market? What period? What decision is the human about to make from it?

Twenty-three agents cannot discover what the user meant. One question could.

The ignored signal: cost rose 15-fold while measured quality stayed flat. That is precisely the definition of the stop condition.

You do not fix a cold room by installing twenty radiators. You fix the thermostat or you insulate the window.

✅ What to do instead

Set a hard, absolute ceiling — a maximum number of concurrent agents, or a maximum spend per request. When it is reached, no further agents are spawned. It is not advisory, it is a limit.

Then write the budget-versus-progress condition explicitly: if consumed budget rises significantly while the quality score does not move, the system collapses to the single best path.

And most importantly, escalate to a human, not to width: the system asks “which market, what period, what decision are you preparing?”. That question costs almost nothing.

Here a consequence surprises teams: per-unit cost attribution stops being an accounting concern and becomes a control sensor. Without per-tenant accounting for LLM workloads, the condition “budget exceeds progress” cannot be evaluated in real time. You find out the following month, on the invoice, when nothing can be done about it.

7. Rule 5: the slow loop has a deadline, and the default is conservative

If the slow loop waits on human confirmation, you must define explicitly what happens while you wait. Otherwise chance decides on your behalf.

📌 Concrete example: the clause sent to legal

A system processes 400 contracts. In one it finds an unusual liability limitation clause and sends it for legal review. The lawyer is on holiday for two weeks.

Wrong option A — the system blocks. The pipeline waits for confirmation. The other 399 contracts queue behind a single one. After two days, someone in operations disables the check “temporarily”, to unblock the work. Nobody ever puts it back.

Wrong option B — the system assumes. After 24 hours without a response, the timeout flips to “probably fine”, and the contract goes out for signature with the clause included. No error. No alert. Nothing in the log that looks abnormal.

The second is more dangerous than the first, precisely because it is invisible.

✅ What to do instead

When the deadline expires, the item stays unconfirmed. It does not ship. It is not promoted. It appears visibly on a dashboard, flagged “awaiting review for 3 days”. And the other 399 contracts move on.

Two things to hold on to: one blocked item must never block the system, and an expiry must never quietly flip to “we assume it is fine”. The latter is the exact inverse of control — a system reading its own lack of information as approval.

8. Rule 6: cheap routing is an architectural decision

The control plane costs something too. If you have a language model decide how another model organizes itself for every request, you have added latency, tokens and a failure mode of its own — at a step that often has a well-known answer already.

📌 Concrete example: 10,000 questions a day

An online store receives 10,000 messages daily. The real distribution:

• 8,500 — “where is my order?”, in every possible phrasing
• 1,000 — returns or exchanges
• 500 — genuinely complicated matters: compound complaints, edge cases, situations requiring judgement

The expensive option: the control plane, an LLM, analyses each of the 10,000 messages to decide who handles it. Cost: 10,000 routing calls. Plus latency on every message. Plus the risk that on a few hundred of them it “decides creatively” something that makes no sense.

The correct option: a deterministic rule — pattern match plus a check for whether an order number exists — handles the 8,500 at near-zero cost and in milliseconds. The intelligent planner only ever sees the 500 that are genuinely ambiguous.

The difference: 10,000 expensive calls become 500. And those 8,500 answers come back faster and more predictably too.

✅ The rule

What is known goes to deterministic routing: lookup table, simple rule, cheap classifier, zero LLM. What is genuinely ambiguous goes to the intelligent planner, where the expensive model actually earns its cost.

The same logic underpins cost-aware routing between models: the expensive model is for the hard decisions, not the frequent ones.

Your thermostat does not call in a heating engineer to decide whether 21 is less than 23.

9. The decision log: how you make the system defensible

A system that reorganizes itself must be able to explain why it did. Every topology change is written down with a reason and a timestamp.

2026-07-20T09:14:22Z control.reorg  run=4c91
  trigger=failure_cluster  n=6  window=45m  step=extract
  action=insert_review_gate  scope=step:extract
  rationale="6 of 9 extractions below threshold, same document type"
  budget_used=0.62  progress_delta=0.03
  human_confirmed=false  status=awaiting_review

Read in plain language: the system saw a cluster of failures — six out of nine, not one isolated case — within a 45-minute window, on the same document type. It added a reviewer. It noted that budget rose 62% while progress moved only 3%, a sign it is approaching the collapse condition. And it flagged clearly that nobody has confirmed the decision yet.

A log like this answers all three questions from the opening: who closed the loop, on what signal, after how long.

In regulated domains this is not hygiene, it is a requirement. For operators falling under the AI Act and Directive (EU) 2022/2555, post-market monitoring means being able to document system behaviour after the fact. “It reorganized itself” is not an answer you can defend to an auditor without the decision log.

10. Authority stays at the top

The last rule is not negotiable.

The loop optimizes HOW the work gets done. It does not decide WHAT should be done, nor WHETHER it ships.

Goals, the quality bar and final approval stay human. You set the target temperature; the thermostat only decides when the heat comes on. A thermostat that picks its own target temperature is not smarter — it is broken.

An agentic system that can rewrite its own success criteria is not autonomous. It is unsupervised. The same distinction is drawn by the propose-then-act model: the agent proposes, the human confirms, the system executes.

11. Where to start, concretely

If you already have agents in production, this is the order that works:

1. Classify your signals into fast and slow. Most teams discover right here that they are promoting configurations based on signals they do not have yet.
2. Add provenance — source, confidence, human-confirmed — to everything written to shared state. Before adding any new agent.
3. Set the cost ceiling on fan-out and write the budget-versus-progress condition explicitly.
4. Define the slow loop’s deadline and what happens when it expires.
5. Add hysteresis: how many correlated failures, in what window, trigger a restructure — and how long it stays stable afterwards.
6. Only then talk about dynamic topology.

The reverse order — dynamic topology with no provenance, no ceiling and no deadline — produces precisely the system that looks impressive in the diagram and oscillates in production.

Frequently asked questions

What does “closed loop” mean in a multi-agent AI system?

A closed-loop system measures its own result and corrects itself based on that measurement, instead of blindly executing a plan decided in advance. The cycle has four steps that repeat indefinitely: act, measure the result, compare it against the target, correct. A thermostat is the classic example. An agent system that changes its structure based on a measured error rate does exactly the same thing, it just measures something other than temperature.

What is the difference between the fast loop and the slow loop?

The fast loop runs on signals that are immediate and objective — latency, cost, tool errors, schema validity. The system can act on these automatically, with no human involved. The slow loop runs on delayed or high-stakes signals — whether the extracted value was actually correct, whether the deliverable passed review, whether the outcome held up in reality. The fundamental rule is that you cannot close a loop on a signal you do not have yet; promoting a configuration because “it worked twice” confuses the absence of a complaint with the presence of a verified success.

Why does an agent system’s topology oscillate, and how do you stop it?

It oscillates because it reacts to every isolated deviation: it adds a reviewer after one failure, removes it after two successes, adds it back again. This is the equivalent of short-cycling in a heating system. The fix is hysteresis — explicit numeric thresholds. For example, add the reviewer only after at least 6 failures out of 20 in the same category within a 4-hour window, remove it only after 200 consecutive successes, and keep the topology stable for at least 24 hours after any change.

What does data provenance mean in shared agent state?

It means every piece of information written to the shared store carries three attributes: the source it came from, how confident it is, and whether a human confirmed it. It is necessary because a downstream agent inherits whatever an upstream agent wrote, so a wrong value written early does not stay a local error — it becomes a premise for everything that follows. Without provenance, the system cannot distinguish between “I read this somewhere” and “I verified this”.

How do you cap costs in a system that fans tasks out across multiple agents?

Through two mechanisms. The first is a hard, absolute ceiling — a maximum number of concurrent agents or a maximum budget per request; once reached, no further agents are spawned. The second is the budget-versus-progress condition: if spending rises significantly while measured quality stays flat, the system collapses to the single best path and escalates to a human. An ambiguous request is not resolved by width; twenty agents cannot discover what the user meant, but one clarifying question can.

What is MAPE-K and how does it relate to AI agents?

MAPE-K is the control loop described by Kephart and Chess in 2003, in the paper that defined autonomic computing. It has five components — Monitor, Analyze, Plan, Execute and Knowledge — the last being the shared state the other four read from and write to. Any modern “dynamic agent org” diagram reproduces those same five components under new names. What is specific to 2026 is that the Plan step can itself be a language model, which can hallucinate the reorganization — a failure mode autonomic computing never had.

Conclusion

Closed-loop control is not a new buzzword. It is a discipline over twenty years old, now applied to a control plane that, unlike the thermostat on your wall, can be wrong creatively.

A broken thermostat reports the wrong temperature. An LLM-based control plane can produce a reorganization that is entirely coherent, impeccably argued and completely unfounded — exactly like the compliance report built on a forum comment.

That is why the six rules — two loops, damping, provenance, ceiling, deadline, cheap routing — are not bureaucracy. They are precisely what turns “the graph that rewrites itself” from a pretty diagram into a system you can leave running overnight.

Further reading

• Agentic AI Safety Lives in Topology, Not Model Weights
• LLM agent failure taxonomy: six clusters
• Observability of AI agents: what to monitor in production
• Threats across the RAG retrieval and generation stack

External references

• Kephart & Chess — The Vision of Autonomic Computing (IEEE Computer, 2003) — the origin of the MAPE-K loop
• Anthropic — Building Effective Agents — when to split and when to unify agents
• Anthropic — How we built our multi-agent research system — production lessons on orchestration
• LangGraph — stateful graph agents with shared state and runtime rerouting
• Microsoft AutoGen — multi-agent framework with orchestrated roles and conversations