§0 — Webhook Intake
ServiceNow incident fires webhook → Regisseur case auto-created, idempotent
Settings → Integrations shows the servicenow-incident-inbound event source. A ROUTE rule maps all ServiceNow INC payloads to the IT Incident Management template. MAP rules extract incident number, affected user, device ID, and category. Activation policy: auto_activate_when_valid — incidents are activated immediately.
ServiceNow INC0002002 arrived via outbound webhook. Regisseur auto-created incident management case "INC0002002 — Sara Patel device ownership mismatch" (intakeStatus: activated). No human action required — the INC ticket is now a structured Regisseur workflow visible in the active case queue alongside the access request process.
Workflow graph for webhook-created incident case INC0002002 — Sara Patel. The energy-incident-mgmt-v1 process template was instantiated automatically from the ServiceNow INC JSON payload. 6 nodes configured: Incident Intake (AI) → Classification & KB (AI) → Resolution Planning (AI) → Tech Lead Review (human) → Remediation (AI) → Closure & Writeback (AI). n1 — Incident Intake — is activated and running.
§1 — Control Center
Operating surface showing both access request and incident management cases
Workflow Control Center — the daily operating surface for the IT operations team. Live queue metrics showing both active processes: access provisioning and IT incident management. The energy vertical runs multiple AI-orchestrated processes in the same workspace.
Case queue shows both active processes in the same workspace: the pre-seeded INC0002001 (Alex Rivera, Intune device mismatch) and the existing REQ0001234 (James Kowalski, Access Request). Multi-process AI orchestration — one platform, multiple workflows, one unified operating surface for the energy operations team.
§2 — Integration Blueprint
ServiceNow ITSM and Microsoft Intune wired via MCP
Energy — Operations & ITSM package is installed. Four integrations configured: ServiceNow ITSM (access requests — port 39810), Access Provisioning (port 39811), ServiceNow INC/CMDB/KB (incident management — port 39812), and Microsoft Intune (port 39813). Both demos running from the same energy package installation.
MCP server registry shows servicenow-incident-mock (port 39812) and intune-mock (port 39813). 8 tools registered: snow_get_incident, snow_update_incident_state, snow_add_incident_note, snow_cmdb_lookup, snow_kb_search (ServiceNow) + intune_get_device, intune_update_device_owner, intune_verify_compliance (Intune).
Incident Classification Agent: uses snow_cmdb_lookup to retrieve the device asset record, then snow_kb_search to find relevant KB articles. LLM reasoning synthesizes the classification: device model, OS, owner UPN, compliance status, and top KB article recommendation. Graduated autonomy — operator review enabled. Pipeline: cmdb_lookup → kb_search → llm_reasoning → write.
§3 — Active Case Overview
Pre-seeded INC0002001 — Alex Rivera, LAPTOP-PRD-4892 non-compliant
Active IT incident case: INC0002001 for Alex Rivera (Operations Engineer, Permian Basin). Incident: Intune device ownership mismatch on LAPTOP-PRD-4892 after department transfer. Priority 2 — High. n1 — Incident Intake — is active (AI agent running). ServiceNow INC/CMDB/KB mock server is reachable on port 39812.
Case Record tab shows the initial intake data: INC0002001, Alex Rivera (alex.rivera@energy-client.com), device LAPTOP-PRD-4892, category: device_management, priority: 2 — High. The Incident Intake agent will enrich this record with the full ServiceNow ticket data and CMDB asset record.
§4 — Intake & Classification
Agent reads incident from ServiceNow, classifies via CMDB + KB lookup
Incident Intake node. Agent executor: energy-incident-intake-agent. Pipeline: snow_get_incident(INC0002001) → write incident details to case attributes. Enriches the webhook-created case with full ServiceNow ticket data.
Incident Intake agent triggered (cascade re-fire: true). Pipeline executing: snow_get_incident(INC0002001) → enrich case attributes. After intake completes, Classification & KB agent will be enqueued automatically.
Classification & KB complete (result: complete). Pipeline trace: snow_cmdb_lookup(LAPTOP-PRD-4892) → device: Dell Latitude 5540, Windows 11 Pro, owner: alex.rivera.upstream@energy-client.com (non_compliant). snow_kb_search(category=device_management, keywords=intune ownership) → KB0001042 cited. LLM classification: root cause confirmed — department transfer without Intune owner update. Recommended resolution: Intune ownership transfer per KB0001042.
Case attributes after n1 + n2 (n1: complete, n2: complete): classification.device_model (Dell Latitude 5540), classification.os (Windows 11 Pro 23H2), classification.compliance_status (non_compliant), classification.kb_article_id (KB0001042), classification.kb_article_title written. D-16: all writes via case_attributes. Full audit trail from first agent step.
§5 — Resolution Plan
Agent constructs Intune remediation steps from KB article KB0001042
Resolution Planning node. Agent executor: energy-incident-resolver-agent. Uses incident details, CMDB device record, and KB article recommendation to build a step-by-step remediation plan for tech-lead review. No external MCP calls — pure LLM reasoning over case state.
Resolution Planning complete (result: complete). LLM built a step-by-step remediation plan: 1. Use intune_get_device to confirm device state. 2. Use intune_update_device_owner → new UPN: alex.rivera@energy-client.com. 3. Use intune_verify_compliance to confirm compliance. 4. Verify SCADA Viewer access restored. Plan written to case.resolution.plan + case.resolution.steps. Tech lead can now approve.
Graph state after resolution planning (n3 result: complete): n1 (Intake), n2 (Classification), n3 (Resolution Planning) — complete. n4 — Tech Lead Review — is now active and waiting for approval. Tech lead can review the AI-built plan and approve or reject Intune remediation.
§6 — Tech Lead Review
Human gate: tech lead approves remediation plan with full incident context
Tech Lead Review node. The tech lead reviews the AI-built resolution plan: transfer LAPTOP-PRD-4892 ownership from alex.rivera.upstream@energy-client.com to alex.rivera@energy-client.com via Intune, then verify compliance. Approval note: plan is correct, Field Operations account confirmed. Approved.
Tech lead approval recorded (API result: true). Case cascade fires — Remediation Agent (energy-incident-remediation-agent) is now queued. n4 — Tech Lead Review — shows complete status. n5 — Remediation — is now eligible for execution.
§7 — Remediation Execution
3-tool Intune pipeline: get device → transfer owner → verify compliance
Remediation agent is queued (n5 eligible). Tech lead has approved the plan. Agent will execute 3 Intune tools: intune_get_device (confirm current state) → intune_update_device_owner (transfer ownership, 600ms simulated latency) → intune_verify_compliance (confirm compliant). This is a real state transition in the mock.
Remediation node do tab. Agent: energy-incident-remediation-agent. Pipeline: intune_get_device → intune_update_device_owner (new UPN: alex.rivera@energy-client.com) → intune_verify_compliance → write remediation results to case.remediation.*. The Intune mock server on port 39813 will process the real state transition.
Remediation complete (result: complete). Pipeline trace: intune_get_device(LAPTOP-PRD-4892) → current_owner: alex.rivera.upstream@energy-client.com, compliance: non_compliant. intune_update_device_owner(new_owner: alex.rivera@energy-client.com) → success, 600ms. intune_verify_compliance → compliance: compliant, all policies passing. case.remediation.intune_previous_owner, intune_new_owner, compliance_result written.
Case attributes after remediation (result: complete): remediation.intune_previous_owner (alex.rivera.upstream@energy-client.com), remediation.intune_new_owner (alex.rivera@energy-client.com), remediation.compliance_result (compliant). The Intune state transition is real — the mock server tracks ownership changes across requests and reports compliance based on the current owner UPN.
§8 — Closure & Audit Trail
Always-autonomous closure agent updates ServiceNow ticket; audit ledger generated
Closure & Writeback agent is queued (n6 eligible). Remediation is complete. Agent will generate professional closure notes, write them to ServiceNow as a work note, and close the incident as 'resolved'. Always autonomous — no human review required.
Closure & Writeback complete (result: complete). Pipeline trace: LLM generated professional resolution note (device ID, previous/new owner, compliance confirmed). snow_add_incident_note(INC0002001) → work note added for audit record. snow_update_incident_state(INC0002001, state=resolved) → incident closed. case.writeback.incident_state = resolved, case.writeback.closed_at written.
All 6 nodes complete (n6 result: complete): Incident Intake (AI) → Classification & KB (AI) → Resolution Planning (AI) → Tech Lead Review (human approved) → Remediation (AI, Intune transfer) → Closure & Writeback (AI, always_autonomous). INC0002001 is resolved. Alex Rivera's device is compliant. SCADA access restored.
Case audit ledger (n6 result: complete): Full event timeline — EXTERNAL_EVENT_RECEIVED (ServiceNow webhook) → JOB_ACTIVATED → n1 Incident Intake (agent events) → n2 Classification & KB (CMDB + KB tool calls) → n3 Resolution Planning (LLM reasoning) → n4 Tech Lead approval (human decision) → n5 Remediation (Intune ownership transfer + compliance verification) → n6 Closure (work note + INC resolved). Complete SOX/ISO 27001 audit evidence generated as a natural byproduct of execution.