Guiding Principles
Seven principles that govern the design, deployment, and governance of agentic ITSM programs
These seven principles define the design philosophy of the Open Agentic ITSM Framework. They are a manifesto the framework will implement, not a list of aspirations. When facing a design choice, a governance question, or a deployment decision, these principles should produce a clear answer. If they do not, more refinement will be needed.
Principle 1: Agents Are First-Class Participants
Observation: In domains where they are deployed, agentic AI systems function as participants in ITSM work, with defined roles, permissions, accountability structures, and performance expectations, rather than as tools that merely assist the humans performing it.
Practice: Every ITSM process design must explicitly define the same types of boundaries, guidelines, etc. that are done where people participate, such as:
- specifically which agent(s) are responsible for which tasks
- what authority they hold
- what actions they may take autonomously and which require human review
- what escalation paths exist when agent judgment is insufficient.
Designing any process without defining the agent’s role is as incomplete as designing a process without defining the human roles.
Implication: If all you do is treat agentic AI as an automation layer bolted onto existing human-centric processes, you’ve missed the opportunity. That approach captures a fraction of the available value and creates governance gaps that compound over time. Organizations that deploy agents to assist humans in doing what humans always did will not see the outcomes that justify the investment.
Principle 2: Data Readiness Precedes Agent Readiness
Observation: Agentic AI amplifies data quality, in both directions. With accurate, complete, and current data, agents (just like people) can make good decisions at machine speed. However, with stale CMDB records, inconsistently categorized tickets, or fragmented or out-of-date documentation and knowledge bases, agents will make poor decisions at machine speed. The damage compounds faster than any human-operated process could produce.
Practice: Before deploying agents into any ITSM domain, the data foundations that agents will reason over must be assessed and remediated to agreed-to and defined standards. The scope of the data depends directly on the areas in which agents are to be effective: CMDB accuracy and relationship completeness, historical incident categorization consistency, knowledge base coverage and currency, and SLA configuration accuracy. In each of these areas, data readiness is a prerequisite, not a parallel workstream.
Implication: “We’ll clean the data after we see what the agents surface.” That approach produces confident agents making confident mistakes. We’ve seen these results time and time again with AI-assisted development, where agents will confidently assert complete code coverage, yet fundamental issues in the use case tests themselves miss critical issues. Gartner estimates that agentic ITSM actions driven by poor data quality will cause at least 2,000 incidents per medium-sized organization by 2028. The investment in data readiness before deployment is not optional.
Principle 3: Governance Cannot Be Retrofitted
Observation: Agents that operate without audit trails, without defined action boundaries, without human override mechanisms, and without accountability structures are not governed; they are deployed. Those are different things, and the difference matters when something goes wrong at machine speed.
Practice: Agent governance requirements, including identity management, least-privilege access controls, tamper-proof audit logging, confidence thresholds, human-in-the-loop escalation paths, and override mechanisms, must be architected into agent deployments from the first day of production operation, not after the first incident or during the first audit.
Implication: Treating governance as a documentation exercise to satisfy compliance reviews does not qualify. Governance that exists only in policy documents but is not enforced technically is not governance. Every agent action must be traceable, every escalation path must be tested, and every override mechanism must function under production conditions before an agent is authorized to operate autonomously.
Principle 4: Human Judgment Defines Agent Boundaries
Agents are capable of executing complex multi-step workflows with speed and consistency that no human team can match. They are not, at the current state of the technology, capable of the contextual judgment that humans apply to novel situations, ethical edge cases, high-stakes decisions with ambiguous consequences, or situations where organizational relationships and trust are at stake. The boundary between what agents do and what humans do should be defined by this distinction, not by convention or cost.
What this means in practice: Every agentic ITSM program must maintain explicit, versioned documentation of which decisions agents may make fully autonomously, which decisions require human review before execution, and which decisions require human initiation with agent support. These boundaries must be reviewed and updated as agent capability matures and organizational trust develops.
What this rules out: Setting autonomy boundaries based on what is technically possible rather than what is organizationally appropriate. The fact that an agent can make a decision does not mean it should.
Principle 5: Interoperability Over Lock-In
ITSM operates across heterogeneous environments, multiple platforms, varied toolchains, and organizational boundaries that span internal teams, managed service providers, and SaaS vendors. Agentic ITSM capabilities must be designed to operate across this heterogeneity, not to require its elimination.
What this means in practice: Agent designs must prefer open protocols, standard APIs, and platform-neutral integration patterns. Agents should be capable of operating across ITSM platforms, observability tools, identity providers, and configuration systems without requiring a single-vendor stack. This framework’s guidance is written to be applicable regardless of which ITSM platform an organization uses.
What this rules out: Accepting agent architectures that create proprietary dependency on a single vendor’s orchestration layer, data model, or API surface. Maes (2026) correctly identifies that legacy ITSM platforms were built around proprietary database cores and deterministic workflow engines that create lock-in. Agentic architectures must not replicate that pattern at the agent layer.
Principle 6: Outcomes Over Activity
The measure of an agentic ITSM program is not how many agents are deployed, how many tickets they touch, or how much automation has been introduced. The measure is whether IT services are more reliable, more responsive, and worth more to the business than they were before.
What this means in practice: Every agentic deployment must define its intended outcome before it is built, measure against that outcome during operation, and be held accountable to that measurement. The metrics framework in Section 6 provides five vendor-neutral measures designed specifically for this purpose. Activity metrics such as “tickets processed by AI” are inputs to outcome measurement, not outcomes in themselves.
What this rules out: Reporting agentic AI adoption as a success based on deployment counts, automation rates in isolation, or cost reductions that are not validated against service quality outcomes. Dumas et al. (2026) describe the shift from design-driven to data-driven process management; this principle applies that shift to how ITSM programs are evaluated.
Principle 7: Continuous Improvement Is a Design Requirement
Agentic systems that do not improve over time degrade over time. The environment they operate in changes. The data they reason over evolves. The edge cases they encounter accumulate. An agent designed and deployed without feedback loops, performance review cycles, and improvement mechanisms will drift from acceptable performance in ways that may not be visible until a significant failure occurs.
What this means in practice: Every agent deployment must include, from day one, telemetry instrumentation, performance review cadences, feedback mechanisms for human operators to flag agent errors, and defined processes for updating agent behavior based on performance data. An agent’s lifecycle continues past deployment, through monitoring, feedback, and improvement, until it is retired.
What this rules out: Treating agent deployment as a project with a completion date. Agentic ITSM capability is an operational discipline, not an implementation project. The organizations that will sustain value from agentic AI are those that build teams and processes capable of continuously evaluating, improving, and governing their agent ecosystems.
Applying the Principles
These principles work together. A program that achieves data readiness but neglects governance will eventually produce a well-informed agent that takes consequential actions without accountability. A program that governs agents carefully but treats them as activity-based automation rather than outcome-oriented participants will under-invest and under-deliver.
Applying all seven principles simultaneously is the baseline expectation for any organization claiming to operate an agentic ITSM program that is aligned with this framework.
References
Dumas, M., Milani, F., & Chapela-Campa, D. (2026). Agentic Business Process Management Systems. arXiv preprint arXiv.18833.
Maes, S. H. (2026). Agentic Smart ITIL, And The Disruption Of The Market Of Conventional Enterprise Applications. Stephane H. Maes’ Blog on WordPress / Multi-Agent Research Notes.
Gartner. (2025). Gartner Predicts Agentic AI Will Autonomously Resolve 80 Percent of Common Customer Service Issues Without Human Intervention by 2029. Gartner Newsroom.