Executive summary

logIQ is HCLTech's agentic incident investigation and remediation capability, built on AWS. Instead of giving engineers another dashboard to monitor, it gives them an always-on first responder. The moment an alert fires, logIQ begins investigating automatically and for failure classes it already recognizes, it resolves the issue before an engineer is paged.

The design is built around one strict separation: the agent that investigates is never the agent that acts. A second agent handles remediation and every change it makes, whether a live automation run or a pull request against infrastructure as code, happens inside the deployment controls the enterprise already has in place. The objective is straightforward: remove the 30 to 90 minutes every incident currently loses to manual triage before remediation can even begin.

Introduction

Most incident response processes look the same across organizations. An alert fires, an engineer is paged and before any fix can happen, the engineer spends the opening stretch of the incident establishing what happened: pulling logs, checking recent deployments and mapping affected resources. This busy work is the cost of getting to the fix and it is paid in full on every incident, regardless of time of day.

logIQ is built to close that gap: a cloud-native, agentic suite that treats investigation and remediation as two distinct, automatable tasks rather than a single undifferentiated job left to a single engineer. It provides a working model for moving from an alert to a documented resolution without relying on someone being available to begin the process.

The need

Consider what happens when an alert fires today. An engineer is paged and resolution is delayed before it even starts, because logs sit in one tool, deployment history in another and resource topology in a third, with nothing correlating them automatically. What should be a fast diagnosis becomes a manual investigation repeated identically on every incident, regardless of how routine the underlying cause turns out to be.

logIQ addresses the gap between an alert firing and someone acting on it. Rather than stopping at notification, it investigates automatically, executes a known fix where one exists and hands off a structured summary to an engineer only when the incident genuinely requires human judgment. This keeps incident response consistent, auditable and it operates within the change management processes enterprises already rely on: Git and infrastructure as code, not around them.

Solution architecture

• The platform runs as a three-stage pipeline: Detection, investigation and remediation. Any monitoring tool can trigger it; one agent performs the diagnostic work an engineer would otherwise do manually and a second agent acts on the finding without stepping outside existing change control
• Universal alert intake: logIQ accepts webhooks from any monitoring platform, including Datadog, Splunk, PagerDuty, New Relic, Grafana and ServiceNow. Indirect sources route through Amazon SNS and a signed Lambda function first, but the entry point behaves the same way regardless of which tool raised the alert: one authenticated event starts the chain
• Investigations that correlate: Once triggered, AWS DevOps Agent queries CloudWatch, CloudTrail and OpenSearch, then checks the findings against recent commit history in GitHub and GitLab. Most production failures trace back to something that changed, so this correlation step is usually the fastest route to a root cause, completed in minutes rather than the 45 to 90 that manual triage typically requires
• Remediation via three governed paths: Once the investigation produces a structured finding, the logIQ remediation agent selects exactly one path: a pre-authored SSM Automation runbook for known failures, a pull request against the infrastructure-as-code repository for changes that need to persist, or a full handoff to the on-call engineer for anything novel. There is no path that allows an unreviewed change to be applied directly to a live environment

The Agentic reasoning layer

The design rests on a firm separation between the agent that investigates and the agent that acts, coordinated through Amazon EventBridge.

• Investigation: handled by DevOps Agent. This agent has a single responsibility: build a structured finding by querying logs, metrics and live topology, then correlating symptom onset against deployment history. It recommends and does not execute. That boundary is what allows this agent to run on every alert automatically, without risk of acting on an incomplete picture of the incident
• Remediation: handled by logIQ Remediation Agent. This second agent receives the finding through EventBridge and Lambda and its decision space is deliberately narrow: known failure, persistent change, or novel incident. Each outcome maps one predefined action, which is what keeps remediation deterministic rather than improvised
• Change control is never bypassed because known failures run through SSM Automation behind an approval gate. Persistent changes are made via a pull request against the IaC repository, such as CloudFormation, rather than via a direct live edit. In both cases, the enterprise's existing review process remains the system of record for what changed and why. logIQ does not replace that process. It supplies it with the information needed to act faster

Technical Implementation

• An alert fires from any monitoring tool, including Splunk, Datadog, New Relic, Grafana, or PagerDuty
• The alert is delivered as an HTTP POST to a webhook endpoint. Indirect sources route through Amazon SNS and a signing Lambda function first, so every event reaching the endpoint is authenticated
• The webhook hands off to DevOps Agent, which queries Amazon CloudWatch, AWS CloudTrail and Amazon OpenSearch, as well as connected external observability tools such as Splunk and then correlates the symptoms against commit history in Git
• DevOps Agent builds a live topology of affected resources and produces a structured finding with a recommended remediation plan
• The finding routes through Amazon EventBridge and via Lambda to the logIQ Remediation Agent
• For a known failure, the remediation agent triggers an SSM Automation runbook, which executes behind an approval gate
• For a persistent infrastructure change, the remediation agent opens a pull request against the IaC repository, such as CloudFormation, keeping the change inside existing deployment controls
• For a novel incident, the remediation agent sends the full findings and recommended plan to the on-call engineer through Amazon SNS. Every incident, including the ones that require human handling, begins with context rather than a blank investigation

Technical Architecture and AWS Services

AWS services used in the solution:

• Amazon SNS: Receives and forwards alerts from indirect monitoring sources into the detection pipeline
• AWS Lambda: Signs incoming webhook events and routes structured findings from investigation into remediation
• AWS DevOps Agent: Performs the automated investigation, querying logs, metrics and topology, then correlating findings against deployment history
• Amazon CloudWatch: Supplies the metrics and operational telemetry used during the investigation
• AWS CloudTrail: Supplies the audit and API activity history used to identify recent changes
• Amazon OpenSearch: Provides log search and correlation across the affected environment
• GitHub / GitLab (native integrations): Supply commit and deployment history used to connect symptoms to a specific change
• Amazon EventBridge: Routes structured findings from the investigation agent to the remediation agent
• logIQ Remediation Agent: Maps each finding to one of three governed remediation paths and executes the decision
• AWS Systems Manager (SSM) Automation: Executes pre-authored, validated runbooks for known failure classes, behind an approval gate
• Infrastructure as Code Repository (CloudFormation): Receives pull requests for persistent infrastructure changes, keeping them inside existing review processes

Value for users:

• Stop paying the triage tax on every incident: Investigations begin within seconds of an alert, automatically correlating logs, deployment history and live resource state, replacing the 45 to 90 minutes of manual triage typical of a P2 incident
• Resolve faster, with less variability: Known failure classes run through pre-authored, validated runbooks, removing the variability that comes from which engineer happens to be handling a given incident
• Change control that is never bypassed: Persistent infrastructure changes go through a pull request rather than a live edit, so every change still passes through the review process that the organization already relies on
• Clear separation between investigation and action: Investigation and remediation run under separate roles, approval gates are built into the execution path and every action is logged
• Coverage that expands over time: When an engineer resolves a novel incident, that resolution becomes a candidate runbook, so the set of failure classes that logIQ can remediate automatically continues to grow

Call to action: No incident should ever start cold!

• Assess in days: A rapid review of current alerting sources, on-call load and recurring failure classes produces a prioritized list of candidates for automated coverage
• Pilot Fast: A proof of concept run against representative failure scenarios from your environment validates investigation accuracy and remediation safety before a wider rollout

"From alert to action: Detect, investigate, remediate."

• Detect: Accept alerts from any monitoring tool through a single authenticated webhook entry point
• Investigate: Correlate logs, topology and deployment history into a structured finding, automatically, on every alert
• Remediate: Route each finding to a governed action, whether a validated runbook, a pull request, or a full handoff to an engineer, without ever bypassing existing controls with a live, unreviewed change

Enterprises and AWS partners can engage HCLTech to schedule a logIQ briefing or demo and see what an agentic DevOps capability can do to reduce MTTR without requiring any compromise on governance

Tags: DevOps, Incident Management, AIOps, Agentic AI, AWS DevOps Agent, Root Cause Analysis, SSM Automation, Infrastructure as Code, MTTR Reduction, GitOps