The terms Agentic Web and Autonomic Web overlap. They are not competing standards with a universally accepted boundary between them. What follows is the working distinction I use when deciding what kind of system I am actually building.
That qualification matters. Agentic Web research already includes persistent agents, multi-agent coordination, protocols, economics, and governance. It would be inaccurate to define every agentic system as a short-lived assistant. At the same time, the older autonomic-computing tradition gives us a useful vocabulary for something more specific: systems that manage their own behavior under high-level intent while adapting to changing conditions.
The distinction is therefore not “smart agent versus smarter system.” It is a difference in operating model, authority, duration, and responsibility.
Agentic Web: delegated agency on the web
The Agentic Web begins with software acting on behalf of a person or another principal. An agent may search, compare, negotiate, coordinate with other agents, operate a website, or complete a transaction. The defining movement is delegation: intent passes from a user or organization to software that can plan and act.
A familiar version is bounded. You ask for a flight comparison, a purchase, or a completed form; the agent performs the task and returns an outcome. But that is only one part of the emerging field. W3C discussions include agents operating browsers and interacting with web applications through machine-facing capabilities. MIT's NANDA work describes a decentralized Internet of specialized agents that interact with one another. Recent Agentic Web research similarly covers persistent identities, orchestration, collaboration, and agent economies.
So “one request, one session, one outcome” is a useful product pattern, not a complete definition. An agent can be a visitor with better tools, but an ecosystem of agents may also become part of the web's permanent operating layer.
Autonomic systems: self-management under intent
The autonomic tradition starts elsewhere. Its central concern is not whether software can perform a delegated task, but whether a system can manage aspects of itself as conditions change.
IRTF RFC 7575 defines autonomic behavior through self-management: self-configuration, self-protection, self-healing, and self-optimization, guided by high-level intent. It also makes a useful distinction between automatic and autonomic. Automatic execution follows a predefined sequence without human intervention. Autonomic behavior adapts when the environment changes instead of requiring a person to rewrite every step.
For the web, I extend that idea to systems whose visible experience is produced by a standing decision process. The page is not only a fixed artifact visited by an agent. Its content, emphasis, sequence, or available actions may be composed in response to context and constraints. The interface becomes the current output of a managed loop.
This is the idea behind the 10 Directions of Autonomy manifesto and the argument for a seed instead of a conventional CMS. The durable asset is not merely a page. It is a bounded set of goals, rules, identity constraints, and material from which the system can decide what the page should become.
A two-axis model, not two boxes
The cleanest distinction I have found uses two axes.
The first is where operational intent originates. At one end, a user delegates a goal to an agent. At the other, a system operates under standing policy and reacts to changes without waiting for a new user request.
The second is how long the decision process persists. At one end is a bounded task. At the other is a loop that continues to observe, evaluate, and adapt over time.
Real systems can occupy mixed positions. A persistent personal agent remains agentic because it acts for its user. An autonomic publishing system may expose a task-oriented agent as one of its interfaces. A workflow can be automatic without being either deeply agentic or autonomic.
This model avoids forcing every project into a label. It asks more useful questions: Who supplied the intent? What may the system change? How long does its authority last? What state survives? Who can stop or reverse it?
What changed while building this project
I began with too much emphasis on generation. If a system could accept context, create structured content, attach an image, and render a page, it appeared to have completed the publishing task. Multi-domain experiments showed why that assumption was wrong.
A generated entity can be valid and still be generic. A technically successful pipeline can preserve a weak premise all the way to a polished page. A shared content model can reduce engineering duplication while quietly spreading the same editorial shape across domains that should feel unrelated.
The correction was to introduce explicit states and boundaries. Generated material is a candidate. Reviewed material has survived checks for meaning, evidence, duplication, disclosure, and domain fit. Published material is a separate decision for which a person remains accountable. I describe that boundary more fully in Generation Is Not Publication.
This experience changed my definition of autonomy. A system is not mature because it removes the operator from every step. It is mature when routine work can proceed without constant intervention while consequential decisions remain observable, constrained, and reversible.
Different operating models create different risks
A bounded agent can still cause serious harm. A purchase, message, permission change, or financial action may have lasting consequences even if the agent runs for only a few seconds. Agentic does not mean harmless.
The additional risk in a standing autonomic loop is accumulation. A bad objective, weak signal, or missing constraint can affect repeated decisions before anyone notices. The failure is not only one incorrect task; it may become a continuing policy expressed through many interactions.
That changes what must be engineered and governed:
- Authorization: whose intent is the system allowed to pursue?
- Persistence: which decisions and observations survive the current interaction?
- Blast radius: does a failure affect one task, one user, or the system's behavior over time?
- Observability: can an operator see what changed and why?
- Reversal: can an action, publication, or policy be withdrawn without rebuilding the system?
- Override: can a person stop the loop without destroying the useful automation around it?
These questions matter more than the label attached to the architecture.
My working definition of Autonomic Web
I use Autonomic Web for web systems whose behavior is continuously adapted under explicit intent, constraints, observable state, and retained human authority. Agentic capabilities may participate in that process, but the defining concern is self-management of the system rather than task execution alone.
This is a proposal and an engineering standard for the work published here, not a claim that the wider field has settled on the same taxonomy. Its value should be judged by whether it leads to safer and more legible systems.
Agentic and autonomic approaches can converge in the same product. The important thing is to know which authority has been delegated, which loop remains active after the interaction ends, and who is responsible when adaptation produces the wrong result.