Application Design
Three design standards that applications and services must meet to support agentic ITSM participation: Agentic First, API First, Automation First
The twelve ITSM domain analyses in Section 4 describe what changes when agents participate in each practice. This section addresses a prerequisite: what applications and services must do to enable agent participation in the first place.
Agentic ITSM requires that the applications, platforms, and services that agents interact with are designed to support that interaction. An agent cannot resolve an incident involving a system it cannot query. It cannot provision access to an application that has no API. It cannot update a configuration record that has no integration point. The most capable agent in the world produces no value in an environment that was not designed to support its operation.
Three design standards define what that support requires.
The Three Standards
These three standards are interdependent and sequential. API First creates the technical conditions for agent access. Automation First establishes the operational discipline that makes agent action reliable. Agentic First sets the design philosophy that ensures both are applied with the right intent.
Standard 1: Agentic First
Definition: Every new application, service, or ITSM workflow design must define agent participation from the start, not as an add-on after human processes are established.
The Agentic First standard does not exclude humans from every process; it requires that the question “where do agents participate in this process?” be answered during design, not after deployment. Processes that are designed for humans and then automated retrofit AI participation onto a foundation that was not built to support it. The result is agents that handle the narrow slice of work that happened to be automatable in the existing process, rather than agents that are designed to take on the appropriate share of the work.
What Agentic First means in practice:
When designing a new incident resolution workflow, the first question is not “how do analysts triage tickets?” It is “which categories of incidents should agents resolve end-to-end, which should agents diagnose with human resolution, and which require human judgment from the start?” The workflow is then designed around those answers, with the human role defined by what agents cannot or should not do, rather than the agent role defined by what humans find it convenient to delegate.
When designing a new service catalog item, the first question is not “what form does the user fill out?” It is “can an agent fulfill this request autonomously, and if so, what does it need to do that?” The form is a fallback for the cases where agent intake is not appropriate, not the primary design.
What Agentic First rules out:
Designing processes that require manual steps at every stage and then asking agents to assist at specific points. That approach produces better-assisted humans, not agentic operations. It captures a small fraction of the value available from agentic transformation and forecloses the design changes that would capture the rest.
Application rationalization through the Agentic First lens:
Existing applications should be evaluated for their ability to support agent participation. Applications that require manual UI interaction for every operation, that have no API surface, or that cannot generate the telemetry that agents need to make decisions, are blockers to agentic ITSM. Application rationalization decisions should include agent-accessibility as a criterion alongside the traditional cost, functionality, and supportability considerations.
The three horizon model described in Section 2 provides context here. Applications that were adequate for Reactive or Proactive Operations may be blockers in Agentic Operations if they were not designed with programmatic access in mind. This does not mean replacing every legacy application immediately. It means understanding which applications limit agent participation and prioritizing their rationalization accordingly.
Standard 2: API First
Definition: Every application, service, and ITSM platform component that agents must interact with must expose its functionality through well-documented, stable, and secured APIs.
Agents cannot perform ITSM work in systems they cannot reach programmatically. An agent resolving an incident must be able to query CI data from the CMDB, create incident records in the ITSM platform, retrieve resolution procedures from the knowledge base, and execute actions in the affected application. Each of these requires an API.
The API First standard applies to new application development as an absolute requirement: no application that will participate in ITSM workflows should be deployed without an API that supports the ITSM operations that agents need to perform. For existing applications, the standard applies as a rationalization criterion.
What API First requires:
Every ITSM-relevant operation must be available through a documented API. This includes read operations (querying CI data, retrieving ticket status, searching the knowledge base) and write operations (creating records, executing provisioning steps, updating configuration data). Documentation must be accurate and current. Endpoints must be stable. Authentication and authorization must be enforced at the API layer.
Standards for API design should prefer established open standards such as REST with OpenAPI documentation, or GraphQL for complex data relationship queries. Proprietary or undocumented API surfaces create agent brittleness: when the API changes without notice, agents break silently.
What API First rules out:
Applications that are UI-only, requiring agents to use RPA to interact with interfaces designed for humans. RPA-based agent interactions are fragile, slow, and difficult to govern. They should be treated as a temporary bridge for legacy systems, not as a design pattern for new development.
Screen-scraping and UI automation are acceptable only as an explicitly time-limited approach for legacy systems with no viable API path, with a defined migration plan to proper API-based integration.
API surface as an ITSM integration requirement:
Organizations procuring new applications or SaaS services for their ITSM environment should include API surface quality as a mandatory evaluation criterion. An application that cannot expose its relevant functionality through a well-documented API cannot support agentic ITSM operations. This should be a disqualifying criterion for new procurement in environments committed to Agentic Operations.
Legacy ITSM platforms built on proprietary API surfaces create lock-in that limits agent portability. The API First standard is the design principle that prevents repeating that mistake with new systems.
Standard 3: Automation First
Definition: Before deploying agentic AI on any ITSM process, eliminate unnecessary manual steps from that process. Agents should automate streamlined processes, not replicate broken ones at machine speed.
This is the standard most often skipped in agentic adoption programs, and the one most responsible for agentic deployments that underperform expectations. Organizations deploy AI on processes they have not examined, inherit the inefficiencies of those processes into their agent designs, and then wonder why performance is not improving proportionate to investment.
The principle is simple: AI should accelerate good processes, not accelerate bad ones. A manual incident triage process that requires analysts to check five different systems and enter data into three forms is not a good process. An agent that executes that same sequence of checks and data entries faster than a human is an automation of a bad process. The right intervention is to redesign the process first, then apply agents to the redesigned version.
What Automation First requires:
Before beginning agent design for any ITSM domain or workflow, conduct a process analysis that identifies manual steps that exist not because they require judgment but because they are required by the current process design. Examples include manual data entry that duplicates information available in an integrated system, approval steps that exist to manage exceptions in a process that should not be generating exceptions, and sequential steps that could be executed in parallel.
Remove or redesign these steps before defining agent behavior. The agent should be designed to execute the improved process, not the current one.
Automation First in the context of application rationalization:
Applications that introduce unnecessary manual steps into ITSM processes, because they have poor integration with other systems, because they require UI-based data entry for operations that could be API-driven, or because they generate process exceptions through poor data quality, are candidates for rationalization as part of an Automation First program.
The Automation First assessment of an application portfolio asks: which applications require manual workarounds because they do not integrate well with the rest of the environment? Those workarounds are manual steps that agents cannot eliminate because the root cause is architectural. Addressing the root cause through application rationalization, rather than accepting the workaround as a permanent agent input, produces a better long-term outcome.
What Automation First rules out:
Deploying agents on unexamined processes on the assumption that making a process faster also makes it better. A faster bad process is not a better process; it produces the same problems at higher speed.
Applying All Three Standards Together
The three standards are designed to work together. An application designed with Agentic First intent (agents are planned participants) that exposes its functionality through well-documented APIs (API First) in a process that has been rationalized to eliminate unnecessary manual steps (Automation First) is an environment where agents can deliver their full potential.
Organizations that skip any of the three will find that their agentic deployment hits a ceiling determined by the standard they skipped. Skipping Agentic First produces processes designed for humans with agents bolted on. Skipping API First produces agents that cannot reach the systems they need. Skipping Automation First produces agents that execute bad processes at machine speed.
All three standards apply to new development as design requirements. For existing systems, they apply as rationalization and improvement criteria, prioritized by the domains where agent deployment is planned first.