Skip to content
AegisOpsTechnologies

Reference workflow — a design pattern we engineer from, not a description of a past client deployment.

IT Incident Investigation

The challenge

During an incident, engineers move between monitoring, logs, change records, and tickets before they can say what broke. The first hour is collection, not judgment.

The agent’s job

The agent assembles the evidence and proposes a diagnosis. It never changes infrastructure without a technician’s approval.

When this isn’t the right fit

Not the right fit if there is no central logging or monitoring yet. Start with an assessment, not an agent.

Who would lead this

Muhammad Shayan Shamsi

Agent design and evaluation. Muhammad Moiz Uddin remains accountable for the engagement.

Architecture

Reference architecture — not a deployment

Your systems

  • Monitor
  • Logs
  • Change records
  • Tickets

Permission boundary

Agent

Reads the allow-list. Proposes. Does not approve itself.

Human approval

Technician approves a runbook step

Logged

The read, the recommendation, the approval or refusal, and the action.

Reference workflow

  1. 1

    Trigger

    An alert is received.

  2. 2

    Gather context

    Logs, metrics, recent deployments, and related tickets are collected.

  3. 3

    Gather context

    The evidence is correlated. Gaps are stated, not filled in.

  4. 4

    Reason and recommend

    An investigation summary lists likely causes and a confidence.

  5. 5

    Reason and recommend

    A remediation is proposed only from approved runbooks.

  6. 6

    Human approves

    A technician approves or refuses. Silence does nothing.

  7. 7

    Act and record

    The approved action is executed and checked.

  8. 8

    Act and record

    The ticket is documented with the evidence and the approval.

Integrations

  • Observability such as the monitor you already run
  • Logs
  • IT service management
  • The pipeline that shipped the last change
  • An approved runbook base
  • The channel where the on-call already works

Controls

  • Read-only by default
  • Actions limited to an approved runbook
  • A named technician approves any change
  • Every read, recommendation, and action is logged

Metrics we’d baseline

These are measures for a pilot. We do not quote improvements we have not measured with you.

  • Mean time to diagnose
  • Mean time to resolve
  • Engineer time per incident
  • Whether the ticket contains the evidence and the approval

What a pilot looks like

Four to six weeks on one service and its alert types. Read-only first. No production change until the approval path has been used.