How does autonomic computing differ from ordinary automation?

Automation can execute a predefined task. Autonomic self-management emphasizes observing the system and adapting actions towards goals through feedback.

Is it the same as an autonomous AI agent?

No. An agent might implement part of the management loop, but the concept concerns system self-management and does not require a particular AI architecture.

Who remains responsible for policy?

The organization operating the system defines objectives, authority and accountability. Delegating routine control does not remove the need for ownership and oversight.

AI Glossary / MLOps and deployment / Intermediate

Autonomic computing

Definition

Autonomic computing is an approach to building computing systems that manage aspects of their own operation according to human-defined goals and policies. It aims to reduce the need for people to continually configure, tune, repair and protect complex infrastructure.

What it means

The word autonomic draws an analogy with bodily processes that operate without continuous conscious direction. In computing, it describes self-management within an engineered system, not consciousness or unlimited independence.

An administrator might specify an availability target and a resource budget. The system then observes conditions and chooses permitted operational responses. People still define priorities, boundaries and acceptable trade-offs.

The classic vision includes self-configuration, self-optimization, self-healing and self-protection. These are related capabilities rather than a guarantee that one product handles every possible operational problem. A system can automate one narrow function while relying on human judgment for others.

How it works

A common architectural pattern is a feedback loop with monitoring, analysis, planning and execution, supported by knowledge about the managed system. Monitoring collects operational signals. Analysis interprets them relative to goals. Planning selects an action, and execution applies it through available controls.

The loop then observes the consequences. This feedback matters: performing a scheduled action without checking its effect is weaker than managing towards an operational objective.

Knowledge can include configuration, dependencies, historical observations and policies. Decision-making may use rules, control algorithms, optimization or machine learning. Autonomic computing does not require a language model.

Multiple managers also need coordination. One component's attempt to reduce cost may conflict with another's attempt to increase capacity. Delays and noisy measurements can cause repeated overcorrection. Limits, stabilization periods and escalation paths help make the resulting behavior understandable and controllable.

Three practical examples

1. Self-configuration: A newly added service instance receives an approved configuration and registers with the components that need to find it. The system verifies that it is ready before using it.

2. Self-healing: A manager detects an unhealthy worker and replaces it under an established policy. Replacing a worker restores capacity only if the underlying problem is not shared by every replacement.

3. Self-optimization: A controller adjusts the number of processing workers as demand changes, while respecting cost and capacity limits. Performance is checked after the adjustment rather than assumed.

Think of it this way

Think of a building's climate controller. People set comfort limits, sensors measure conditions and the controller adjusts heating or cooling. It can handle routine variation without someone moving a dial every minute.

A computing system is usually more complicated: it may have conflicting objectives, uncertain diagnoses and many interacting controllers. The analogy does not imply that all incidents can be resolved automatically or that administrators become unnecessary.

Worked example

Consider an invented service with four identical workers. Each can sustainably handle 50 requests per second under the assumed workload. A policy targets no more than 70% of that capacity per worker, giving a planning allowance of 35 requests per second per worker.

Measured demand is 210 requests per second. The controller estimates a required count of ceiling(210/35) = 6 workers. It plans to add two, subject to a maximum of eight workers and successful readiness checks.

After six workers become ready, the average planned load is 210/6 = 35 requests per second per worker. The controller then measures actual response times and errors. Uneven traffic, slow dependencies or changed request complexity could invalidate its simple capacity assumption.

If demand falls to 105 requests per second, the same arithmetic suggests three workers. A stabilization rule may require the lower demand to persist before removal, avoiding repeated expansion and contraction during brief fluctuations.

This is a toy policy calculation, not a universal scaling formula. It demonstrates how a goal, observations, constraints, action and subsequent verification fit into a self-management loop.

Illustrative case study

Illustrative case study - fictional

A fictional document-processing company wants its queue service to recover from routine worker failures. It starts with a bounded policy that replaces a failed worker and records the reason.

Testing reveals that malformed input can crash each replacement. The team adds a retry limit, isolates the problematic item for review and alerts an operator when the same failure recurs. It also verifies that retries do not create duplicate completed records.

The resulting design distinguishes restoring service from fixing every root cause. This invented case demonstrates a manageable scope for automation and claims no measured reliability improvement.

Common misconceptions and mistakes

Autonomic computing does not mean the system chooses its own unrestricted business goals.
A restart script alone does not establish comprehensive self-management.
Self-healing is not a promise that every software defect repairs itself.
Machine learning is optional; explicit rules can support useful self-management.
A locally beneficial action can still harm the wider system if controllers ignore shared dependencies.

Business use

Autonomic computing is useful for discussing infrastructure that adapts to demand or handles recurring operational incidents. Start with a measurable objective and a limited set of permitted actions.

Define what the system observes, what it can change and when it must escalate. Test actions against realistic failures, delayed metrics and unavailable dependencies. Keep a record of observations, decisions and results so operators can understand unexpected behavior. Evaluate reduced operational effort alongside service quality and cost; fewer manual interventions are not a benefit if they conceal unresolved failures.

Check your understanding

A service restarts a failed worker forever, even though every replacement fails on the same input. Has it demonstrated successful self-healing?

Answer: No. Repeating an action is not evidence of recovery. The system needs to check outcomes and follow a bounded response when the action does not solve the problem.

Related terms

Feedback loop
Observability (software)
self-healing
self-configuration
self-optimisation
self-protection
policy-based management
observability
autoscaling

Learn next

Map a recurring operational issue into monitor, analyze, plan and execute steps. Add the knowledge each step needs, an action limit and a test that distinguishes successful recovery from merely repeating the action.

Sources

Sources: Kephart and Chess, The Vision of Autonomic Computing: https://jmvidal.cse.sc.edu/library/kephart03a.pdf ; IBM Research, An architectural approach to autonomic computing: https://research.ibm.com/publications/an-architectural-approach-to-autonomic-computing . Relevant self-management and manager-architecture sections and the architectural paper's abstract were reviewed. The service calculations and company scenario are original illustrations.

Previous: Automaton Next: Autonomic networking