How Aegis InsightOps reasons across operational tools, what it integrates with, and how automated remediation is governed

Technical evaluators reading the InsightOps overview accept the offering at a workflow level. The questions that remain are about engineering substance: how the unified model represents an environment, what the reasoning layer does that existing tools do not, what the security and data handling posture looks like, and how the platform fits alongside the existing Aegis service set.

InsightOps operates as five layers, each with internal structure that matters at the engineering level. The unified model is the layer that makes the rest possible. The reasoning layer is where most of the operational value gets realized.

Read-only ingestion from monitoring (LogicMonitor, Splunk, Datadog, Dynatrace, Catchpoint, CloudWatch, Azure Monitor), network observability (Arista CloudVision, Meraki, Cisco Crosswork), source of truth (NetBox), ITSM (ServiceNow, Jira Service Management), configuration (Red Hat Ansible Automation Platform, Terraform state, Git events), cloud (AWS Config, Azure Resource Graph), and CX (Amazon Connect, Cisco Webex Contact Center). Bidirectional connections are scoped per integration during onboarding.

An entity catalog (hosts, services, applications, devices, sites, sessions, change events, incidents), a relationship graph anchored in NetBox topology and enriched from monitoring and ITSM, and a temporal alignment layer that normalizes clock skew across sources. Updated continuously; historical state retained for baseline-based pattern detection.

Operates in three modes. Reactive performs timeline reconstruction and produces hypotheses with cited evidence. Proactive surfaces emerging patterns before threshold alerts fire. Predictive forecasts capacity and incident patterns and is treated as advisory. Every output carries a confidence score and the specific evidence cited - there is no black box.

Role-based context for NOC operators, application owners, and SREs. Recommended next steps tied to cited evidence. Direct links into ITSM tickets, runbooks, dashboards, and source-system drill-downs. Operator overrides are first-class; rejection reasons feed back into the model.

Governed remediation with three execution modes (advisory, approval-gated, automated). Promotion criteria include defined success measures, rollback procedure, confidence threshold, execution window, and demonstrated success rate over a baseline period. Every automated action produces a full audit log entry.

When a high-severity event arrives in the unified model, the reasoning layer follows a defined methodology. The output is correlation, summarization, and pattern matching with confidence scoring. It is not autonomous intelligence, and we frame the platform honestly to that effect.

The reasoning layer pulls signals from the affected entity and its upstream dependencies over a configurable window (default 30 minutes), placed on a unified timeline. Signals are read from the normalized stream, not by querying source systems at inference time.

Recent change events on the affected entity, its dependencies, and shared infrastructure are surfaced. A configuration push at T-12 minutes on an upstream load balancer is weighted higher than a routine patch at T-3 hours on an unrelated service.

The current symptom pattern is compared against historical incidents involving the same entity or symptom shape. Past resolution paths are surfaced as candidates, anchored to the historical state retained in the unified model.

One or more probable root cause hypotheses are produced, each with supporting evidence and a confidence score. Multiple hypotheses are surfaced when the evidence is genuinely ambiguous rather than forcing a single answer.

Each hypothesis includes a recommended next step (roll back a change, restart a service, escalate, open a ticket with prepopulated context) with links to relevant runbooks. Operators can accept, modify, or reject any recommendation.

Each integration is scoped per environment during the Operational Intelligence Assessment. The minimum viable unified model in most environments includes a primary monitoring source, an ITSM source, and a topology source.

Alert events, metric data, topology, and datasource configurations via REST API. Optional bidirectional write-back of enriched alert summaries as alert notes.

Saved-search ingestion of log events, HTTP Event Collector for streaming high-priority events, and direct Splunk Enterprise Security notable event ingestion. Optional write-back of enriched event summaries to a designated index for SOC visibility.

Read-only ingestion of devices, interfaces, IP, racks, sites, and virtual machines. Provides the topological anchor for the unified model relationship graph. NetBox remains the source of truth; InsightOps does not modify it.

Bidirectional incident lifecycle via Table API. CMDB read for entity correlation. Change request read for change-event correlation. InsightOps can open, enrich, and resolve incidents per configured workflows.

Streaming telemetry ingestion for network state, configuration state for change-event correlation, and analytics-derived anomaly indicators surfaced in the unified model.

Pre-filters and routes telemetry before ingestion, reducing unified model storage cost and noise. InsightOps appears as a Cribl destination. Recommended for high-volume, low-signal log sources.

Server health, firmware compliance, and lifecycle events. Server profile changes ingested as change events. Hardware fault correlation with VM and service-level signals.

FlashArray health, capacity, and performance events. Storage-side change correlation for AIM environments.

Every runbook in InsightOps runs in one of three modes. New runbooks default to advisory; promotion requires demonstrated success and explicit criteria. The governance surface is shared with Aegis CM, so operations teams do not maintain a parallel governance system for automated actions.

The reasoning layer surfaces a recommended action with cited evidence. No execution. The operator decides. This is the default for new runbooks and is best fit for new or unproven runbooks, high-consequence actions, and environments early in their AIOps maturity where every recommendation should be reviewed by a human. The tradeoff is that all resolution stays operator-driven, so MTTR improvements come from faster diagnosis rather than execution speed.

The reasoning layer queues an action. A designated approver (role, group, or specific operator) signs off in-band. The action executes after approval. This is best fit for actions that are routine and well-understood but carry enough consequence that a human checkpoint is appropriate before execution. The tradeoff is that approver availability becomes part of MTTR, and off-hours coverage requires explicit escalation paths.

The action executes when conditions are met. The operator is notified after execution. Used only where the rollback path is clean and the success rate has been demonstrated over a baseline period in approval-gated mode. This is best fit for high-frequency, low-consequence remediation with proven success rates and clean rollback (for example, restarting a stuck process on a redundant node). The tradeoff is that it requires the most governance investment up front: defined success criteria, rollback procedure, confidence threshold, and execution window.

A handful of architectural choices distinguish InsightOps from a generic AIOps overlay. These are the elements that matter most to an engineer reviewing the platform for production fit, and they are the ones IVI is most often asked to defend in technical evaluations.

Source-specific signals are mapped to a common schema per entity type. Source fields are preserved as extensions; common fields are uniform. Reasoning operates on the normalized layer, not on raw source streams. Without normalization, cross-tool reasoning is statistics on inconsistent shapes. With it, an alert is an alert and a change event is a change event regardless of which tool produced it.

Every signal is associated with one or more entities in the catalog and enriched with the entity's current relationships before reaching the reasoning layer. A LogicMonitor alert on host sfo1-db-3 ties to the host entity, identified through NetBox, the ServiceNow CMDB, or LogicMonitor device records. The host's service, application, and customer-facing workflow context is attached at ingest.

Each automated execution produces an audit log entry containing the triggering signal, reasoning evidence, confidence score, runbook executed, outcome, and rollback path. Audit logs are retained per the customer's compliance requirements and accessible via the Aegis CM surface. Per-customer data partitioning at the unified model layer; tenant isolation by design.

The reasoning layer is correlation, summarization, and pattern matching with confidence scoring. Reasoning quality is bounded by unified model quality, which is bounded by source-system data quality. For environments with weak monitoring foundations, Aegis PM is sequenced first. Reasoning value scales with the maturity of the underlying observability and configuration data.

Delivered as a co-managed service running in an IVI-operated AWS environment with regional placement available. All ingestion is via authenticated API or message bus, outbound from the customer environment by default. For air-gapped or network-restricted environments, an in-line collector pattern is available. A small footprint relay runs in the customer network and forwards normalized data to InsightOps.

InsightOps is purpose-built to operate alongside Aegis PM, CM, IR, and LM. The Operational Intelligence Assessment determines whether InsightOps lands as the entry point or follows foundational services. Aegis PM provides the observability foundation that InsightOps reasons over. Aegis CM provides the change-management workflow whose events become correlation evidence. Aegis IR provides the incident response operating model that InsightOps accelerates. Aegis LM events are correlated with operational impact to inform future scheduling.

InsightOps is not a fit for every environment. The architecture assumes existing operational data, co-managed delivery, and human oversight of automated actions.

This architecture fits environments with multiple operational tools already in production where consolidation is not on the near-term roadmap, teams that have invested in monitoring but still struggle to reason across signals during incidents, environments where change management and topology data exist (or can be brought to standard), organizations with audit requirements that demand full action trails for any automated remediation, and operations groups that prefer co-managed delivery over building internal AIOps engineering capability.