ServiceNow · TypeScript · REST APIs · PostgreSQL · Responsible Automation

AI-Assisted Incident Operations

Designing safer IT service management workflows through guarded automation, evidence-based decisions, and auditability.

The challenge

IT support teams need to triage and update incidents efficiently, but automating changes to service records introduces risks: incorrect assignments, premature resolution, insufficient evidence, and poor traceability. Drawing on hands-on ServiceNow and enterprise support experience, I wanted to explore a workflow that could accelerate incident handling without giving an AI agent unrestricted write access.

What I built

OpsPilot is a development-stage prototype for analyzing ServiceNow incidents and applying tightly controlled updates. It combines incident retrieval, structured analysis, validation rules, guarded write-back, and PostgreSQL-based audit records. The goal is to make proposed actions understandable and reviewable before they affect an ITSM record.

System architecture

Workflow design

Read incident → Analyze evidence → Propose action → Validate guardrails → Apply permitted update → Record audit evidence.

ServiceNow REST APIs provide the integration surface. TypeScript supports application logic and validation, while PostgreSQL (Neon) provides an audit-data foundation. The design separates recommendations from permitted write operations so that high-impact changes can be constrained.

Application walkthrough: synthetic account lockout

The current MVP interface demonstrates AI-assisted triage using a synthetic account-lockout ticket. It presents a proposed P3 priority, clarifying questions, likely causes, and a technician-reviewable troubleshooting path. The interface explicitly requires human approval rather than automatically sending or executing recommendations.

These screenshots show the MVP’s demonstration interface. ServiceNow is marked unavailable in this session, so the pictured ticket was not imported from or written back to a live ServiceNow instance. Separate developer-instance testing established the controlled incident-update functionality described below.

Implementation evidence

In a ServiceNow personal developer instance, I successfully tested controlled updates to a sample incident, including reassignment to a hardware support group and subsequent resolution after supplying the required resolution information. I also implemented safeguards to prevent modification of closed incidents.

These are developer-instance tests, not evidence of a production deployment, customer adoption, or quantified operational savings.

Engineering challenge: authentication

A later integration attempt using OAuth client credentials encountered an access_denied response in the ServiceNow developer environment. I investigated configuration and grant-type settings, but the flow remained unresolved in that test. Documenting this limitation is part of the engineering story: reliable automation depends on secure, correctly configured authentication as much as it depends on application logic.

Why the safeguards matter

ITSM automation should not treat every proposed action as safe. Guarded updates, state checks, and audit trails reduce the risk of silently changing records that should be protected. OpsPilot explores how operational judgment from enterprise support can be translated into software controls.

What I learned

This project deepened my practical experience with REST API integration, TypeScript, ServiceNow incident lifecycles, database-backed audit design, and the challenges of authenticating automation against enterprise platforms. It also reinforced the importance of testing edge cases and keeping a human accountable for consequential workflow decisions.

Next steps

Complete and validate a supported authentication flow, broaden developer-instance tests across incident states, improve audit coverage, and evaluate controlled human-in-the-loop approvals before considering any real-world deployment.