// triage agent
The AI-assisted operational intake layer
Schedule workflows that ingest operational issues from email and Azure DevOps, investigate them with CygNet-aware connector steps, update work items with findings, and notify your engineers when triage is waiting. Same run engine. Same write safety. Same changesets.
Status: available in the Narya Command beta today. Build the five-minute email triage loop — or start with read-only investigation — and scale autonomy as your team earns confidence.
// signature workflow
Triage in practice
Most teams start with a scheduled workflow that watches the inbox for CygNet help requests, opens an Azure DevOps work item, runs diagnostics, writes findings back, and pings the on-call engineer.
- 01Schedule — Run this workflow every five minutes
- 02Email scan — Check inbox for new CygNet help requests
- 03AI analyze — Classify the request and extract device, symptom, urgency into strict JSON
- 04Azure DevOps — Open or update a work item with the request and assigned engineer
- 05CygNet diagnostics — Query points, recent alarms, and trend context for the device
- 06Write findings — Update the Azure DevOps work item with the diagnostic summary
- 07Notify the Engineer in the Command Center — A new item needs to be triaged
// the problem
High-value problems start outside the SCADA app
Many operational problems begin in email, Azure DevOps, or an internal queue — not inside CygNet Studio. The Triage Agent is how Narya Command turns those requests into investigated, tracked, actionable work without sacrificing the preview/apply safety model your team already trusts.
// autonomy modes
You choose the autonomy level
Three policy levels you configure per workflow. Most customers start with Mode 1 or Mode 2. Mode 3 is for narrow, repetitive remediations after a deployment has matured.
Mode 1
Read-Only Triage
The workflow ingests and classifies issues, correlates likely assets, queries CygNet for evidence, summarizes probable cause, and recommends next steps. No writes.
Best for
- Conservative customers
- Initial rollout
- Environments where AI may assist but not modify
Mode 2
Human-Approved Remediation
The workflow investigates, selects a known remediation pattern, generates a preview or changeset, and waits for human approval before any write executes.
Best for
- Customers who want time savings without surrendering control
- Operational changes where preview and approval are required by policy
Mode 3
Bounded Autonomous Remediation
Pre-approved classes of remediation run under explicit policy constraints — workflow allowlist, action allowlist, step limit, time limit. Mandatory audit log and changeset generation. Hard stop on ambiguity or low confidence.
Best for
- Mature deployments
- Narrow, repetitive remediations with low blast radius
- Customers willing to accept controlled automation
Changesets are the boundary between reasoning and execution
- 1. Ingest the issue.
- 2. Investigate with read-only tools.
- 3. Determine whether a known workflow or remediation pattern applies.
- 4. Generate a structured preview of proposed changes.
- 5. Persist that proposal as a changeset or workflow execution preview.
- 6. Require approval — or execute automatically — depending on customer policy.
- 7. Record the final outcome, including any rollback reference.
Same write-safety model whether an engineer clicks Run or a scheduled workflow fires overnight.
// intake
Where issues come from
Each source normalizes into a common case model — source channel, requester, affected entities, severity, confidence, recommended next action. Built-in connectors for CygNet, Email, and Azure DevOps handle the intake today.
Outlook Classic / O365
Azure DevOps work items
Scheduled workflow triggers
Operational alert queues
// preferred
Delegated user approval
Workflows investigate using configured connector credentials. Execution occurs only after approval by an authorized human. Sensitive writes preserve or attribute back to the approving user wherever feasible. This is the default.
// narrow whitelist only
Service account automation
Workflows run under a dedicated service identity for allowlisted remediations. Reads and writes are attributable to that identity. Acceptable only for narrow, pre-approved workflow classes where governance is explicit.
80% resolvable from accumulated knowledge
The long-term goal is a coverage-driven triage layer: 80% of incoming operational problems at a mature site resolvable from your accumulated CygNet knowledge alone — without fresh learning every time. WAIS is the substrate. The Triage Agent is the surface — shipping in Narya Command today.
// the metric
coverage_ratio — distinct (device_type × action × outcome) tuples observed at your site, divided by the known-possible surface. A measurable quantity, not a vibe.
Higher coverage never means looser safety. Preview, confirm, changeset, rollback, and human-in-the-loop approval remain the default at every autonomy level — including scheduled triage workflows.
Start conservative, scale autonomy
- On-premises Windows app. Customer-controlled infrastructure with CygNet runtime in place.
- Scheduled workflows + built-in connectors. Email (Outlook Classic or O365), Azure DevOps, and CygNet ship today.
- Read-only triage and human-approved remediation. Mode 1 and Mode 2 are the recommended starting point.
- Known workflow patterns + changeset preview. Pick from validated workflows — don't invent new operations on every run.
- Rollback where supported. Same 30-day retention, same conflict detection.
// get started
Put triage workflows in front of your team
Download the beta, connect Email and Azure DevOps, and schedule your first intake workflow. Need help designing the loop for your site? We're happy to walk through it.