The homeostat: why autonomy needs a set point

An agent with goals and no set point does not stay autonomous for long; it drifts, and somebody has to come and correct it. The concept that fixes this is seventy years old and almost absent from current agent architectures: Ross Ashby’s homeostat, a machine whose entire purpose was to hold a set of variables inside acceptable bounds by changing its own behaviour until they were.

The difference between a goal and a set point

A goal is a destination: reduce delivery time, increase margin, clear the backlog. Goals are how people brief each other, and they are almost useless as the sole instruction to an autonomous system, because every goal pursued far enough starts eating something else.

A set point is a range a variable must stay inside. Cash above this. Utilisation between these. Delivery time under that. Error rate below this. Individually they look modest. Together they describe the envelope in which the business is still the business.

An autonomous system needs both. Goals tell it which direction to push. Set points tell it what it may not break on the way — and it is the second list, not the first, that makes a system safe to leave running overnight.

What Ashby actually built

The homeostat was four units, each with a variable, each wired to the others, and each able to change its own internal configuration when its variable went out of range. It did not know what the right configuration was. It searched until every variable was back inside its bounds, and then it stopped searching.

Two properties matter here. It was self-correcting without being told how — it did not need a model of the disturbance, only a way to notice it was out of range. And it was bounded by construction: the acceptable range was the machine’s definition of success, not an afterthought.

That second property is what most agent systems are missing. They have objectives and tools; they do not have a definition of “still inside acceptable” that the system itself continuously checks.

What this looks like in a business system

Concretely, a homeostat in an operating system for a company is a small set of variables the system watches without being asked, each with a range and a response.

Cash below a floor: stop discretionary commitments, escalate. Order lead time above a ceiling: reallocate before anyone asks. Model confidence on a class of decisions dropping: narrow the agent’s scope automatically and hand more back to humans. Error rate on automated postings rising: revert that process to proposal-only.

The last two are the interesting ones, because the variable being regulated is the system’s own behaviour. An agent that reduces its own autonomy when its accuracy degrades is doing exactly what the homeostat did — changing its configuration to get a variable back into range.

Why this beats a longer list of rules

The instinct when an autonomous system misbehaves is to add a rule. That works for the case you just saw, and does nothing for the next one, and after two years the rulebook is a liability nobody fully understands.

A homeostat inverts it. Instead of enumerating forbidden actions, you declare the small number of things that must remain true. The system is free inside that space and self-correcting at its edges. The rulebook stops growing, because the boundary is defined by outcomes rather than by an ever-longer list of anticipated failures.

The honest limits

A homeostat only regulates what it can measure. A variable nobody instrumented can drift freely, which means choosing the set points is a business decision and the most important one in the whole design.

It also does not replace human judgement about which envelope is right. Ashby’s machine held its variables in range; it had no opinion about whether that range was the correct one for the world outside. Neither does ours. That question stays where it belongs — with the people who own the company.