Autonomic software manages part of its own operation in service of a goal that
someone else set. The operator still owns the goal, the limits, and the cases
that require human judgment. The software handles the ordinary adjustments
inside those limits.

The word matters. "Autonomous" suggests an actor that can choose its own ends.
"Autonomic" describes a system that regulates itself against an assigned end.
A thermostat is a small example. A person chooses the target temperature. The
thermostat observes the room, turns heating on or off, and checks again.

For software engineering, the managed subject can be a repository, a service,
or a workflow. The loop may propose a patch, apply it in a limited environment,
observe the consequence, and decide whether to keep, revise, or discard it.

## The minimum loop

An autonomic system needs all of the following:

1. **A declared target.** The desired state must be specific enough to test. "Make
   it better" is not a target. "Keep the existing checkout cases passing while
   reducing median response time" is closer.
2. **A bounded action.** The system must know what it may change. That could be
   one patch, one configuration value, or one queued message. The boundary also
   says what it may not change.
3. **Observation after action.** The system must inspect the result of the change,
   not merely record that a command ran.
4. **A decision rule.** Evidence must lead to a named outcome such as keep,
   revise, stop, roll back, or ask for review.
5. **Another turn of the loop.** The verdict affects what happens next. A report
   that nobody or nothing acts on leaves the loop open.

The target and decision rule need protection from the part that proposes the
change. Otherwise the easiest route to success is to weaken the test.

## A concrete example

Consider a dependency update in a web service.

A conventional update bot opens a pull request and reports that the package
version changed. A more capable agent may also fix compile errors and rerun the
test suite. Both can be useful, but neither is necessarily autonomic.

An autonomic loop would work more like this:

1. Record the current revision and its results on a saved set of cases.
2. Propose the dependency update as a reviewable patch.
3. Apply the patch in an isolated workspace with a fixed time and cost budget.
4. Run protected checks, including cases the proposer cannot edit.
5. Compare the candidate with the saved baseline.
6. Discard the patch if a previously passing case fails. Keep or promote it only
   if the declared policy permits that outcome.
7. Record the proposal, observations, verdict, and next action.

The important step is not generating the patch. It is connecting post-change
evidence to the next action without letting the patch author redefine success.

## What does not qualify

A system can use AI and still have no autonomic behavior.

- A scheduled script is automation. It follows a sequence whether or not the
  result improved the managed subject.
- A retry loop is recovery logic. It can be part of an autonomic system, but a
  repeated command is not evidence of convergence.
- A coding agent that stops after its own self-review is still its own judge.
- A dashboard that shows metrics is observation without adaptation.
- A workflow that needs a person to choose every next step is human-operated,
  even if an agent performs each step quickly.

None of these are failures by default. Many tasks should remain simple
automation or human-led work. The distinction prevents a useful tool from being
given authority its design does not support.

## Boundaries stay human-owned

An autonomic loop should name its ordinary case and its exception class before
it runs. A low-risk formatting fix may advance after protected checks. A change
to payments, identity, access control, or irreversible data may always require a
separate approval.

The operator also decides the budget and blast radius. Running out of time,
money, or attempts should produce a recorded stop. It should never become a
silent pass.

Autonomic therefore does not mean "no humans." It means people define the
policy and the system can regulate a bounded subject under that policy. Human
attention moves to goals, exceptions, and changes to the rules themselves.

## A quick test

Ask five questions:

1. What state is the system trying to reach or preserve?
2. What can it change, and what is outside its authority?
3. How does it observe the consequence of its own change?
4. Who or what decides whether the evidence is good enough?
5. Does that decision reliably cause the next action?

If any answer is missing, the loop is open or the boundary is unclear. Fix that
before increasing autonomy.

## Related reading

- [Autonomic software engineering](/reference/autonomic-software-engineering)
- [The closure test](/reference/closure-test)
- [Control plane versus work plane](/guides/concept/control-plane-versus-work-plane)
- [Evidence before confidence](/guides/concept/evidence-before-confidence)