ServiceNow AI Agent for Incident Triage with Human Approval
How an anonymized enterprise used a governed AI agent to triage ServiceNow incidents, retrieve operational evidence, recommend assignment and escalate high-risk cases with auditability.
System map
Incident intake, evidence retrieval, human approval and controlled action are separated into clear governance boundaries.
A large enterprise service desk was receiving incidents across applications, data pipelines and shared infrastructure. The team already had ServiceNow, monitoring tools, runbooks and historical incident records, but first-level triage still depended heavily on manual inspection and individual experience.
The client wanted to use AI, but not as a free-form chatbot. The requirement was operational: read the incident, classify the issue, inspect approved systems, retrieve supporting evidence, recommend assignment or escalation and keep a trace of the decision.
| Case study area | Details |
|---|---|
| Client profile | Enterprise operations team managing incidents across multiple applications and platforms |
| Business function | ITSM, platform operations and service reliability |
| Main issue | Inconsistent triage, repeated manual searches and limited evidence behind recommendations |
| Systems involved | ServiceNow, monitoring/log data, runbook repository, knowledge graph or dependency data |
| Delivery focus | Controlled agent workflow, tool allowlist, human approval and auditability |
The challenge
The service desk had enough information to triage incidents, but that information was scattered. Similar incidents were in ServiceNow history. Operational metrics were in dashboards or warehouse tables. Known fixes were in runbooks. Ownership and dependency relationships were partly documented and partly tribal.
This created two problems. First, triage quality varied based on who handled the ticket. Second, the reasoning behind a recommendation was rarely captured in a structured way. A ticket might be assigned correctly, but the evidence trail was not reusable for future automation or process improvement.
- Repeated incidents were investigated as if they were new.
- Assignment groups were sometimes selected without complete context.
- Support teams manually searched runbooks, dashboards and related tickets.
- High-risk actions needed approval, but approval logic was not part of the AI workflow.
- Leaders wanted automation without giving an LLM uncontrolled write access to ServiceNow.
The solution
AgentFaktory designed the incident triage agent as a governed workflow. The agent first determined whether an incident was eligible for automation. It then used a tool policy layer to decide which approved systems could be queried. Every tool call returned structured observations that were written into an evidence store.
The agent could recommend assignment, add an internal work note, link a related incident or escalate the ticket. Risky actions, such as external customer communication, priority changes, production runbook execution or incident closure, required human approval.
ReAct-style triage loop
The operational loop was intentionally simple:
- Read the incident description, CI, priority and metadata.
- Classify the issue family and automation eligibility.
- Decide what evidence is needed next.
- Call an approved tool such as ServiceNow history, Snowflake logs, runbook search or dependency graph traversal.
- Observe the returned evidence.
- Update the likely cause and recommended next step.
- Route the recommendation to safe automation or human approval.
- Write the result and evidence back to the audit trail.
Outputs delivered
- Incident eligibility and classification logic
- Approved tool list for ServiceNow, operational metrics, runbook search and dependency graph traversal
- Evidence schema for observations, sources, timestamps and confidence notes
- Recommendation templates for assignment, work notes and escalation
- Human approval path for risky actions
- Audit trail covering input, tools, evidence, recommendation and final action
Evidence model
A core design element was the evidence model. The agent did not simply append a generated note to a ticket. It stored each observation as structured evidence: tool name, query parameters, returned record identifiers, timestamp, confidence, user scope and the specific recommendation that used the observation.
Representative evidence records
| Evidence item | Example use |
|---|---|
| Similar incident match | Supports assignment or known-error recommendation |
| Recent deployment event | Explains why an application incident may have started |
| CI dependency path | Shows upstream/downstream service impact |
| Runbook match | Provides approved remediation steps |
| SLA/customer impact flag | Triggers escalation or human approval |
Rollout approach
The rollout was intentionally conservative. The first phase ran the agent in recommendation mode. It read tickets, gathered evidence and suggested assignment groups or internal notes, but did not perform ticket updates automatically. This allowed service owners to compare the agent’s recommendation against human triage without operational risk.
Once the evidence quality was accepted, low-risk actions were enabled. Examples included drafting internal work notes or linking related incidents. Higher-risk actions, such as changing priority or sending customer-facing messages, continued to require approval.
How success was measured
- Percentage of incidents for which the agent found useful related evidence.
- Assignment recommendations accepted by service owners.
- Reduction in time spent searching runbooks and historical incidents.
- Number of recommendations routed to human approval instead of unsafe automation.
- Completeness of audit trail for ticket recommendations.
Outcome
The client moved from a chatbot-style AI concept to a controlled incident workflow. The AI agent improved the speed and consistency of triage because it could gather the same evidence a skilled operator would normally check manually. The workflow also made the reasoning visible, which increased trust among support teams.
By separating recommendation from execution, the client could start with read-only triage support and later introduce controlled write-back where the risk was acceptable.
The value was not that the agent could write ticket notes. The value was that it could show which evidence led to the note.
AgentFaktory role
AgentFaktory designed the workflow, tool boundaries, evidence schema, approval model, architecture and production rollout approach for the ServiceNow triage agent.