Main site

Engineering AI agent · Root-cause analysis

Root-Cause Analysis AI Agent

Evidence each cause before you name it: assemble the timeline, keep the facts and the conclusion in separate fields, and hold the review for the named engineer who signs it.

Typical delivery
4–6 weeks
Deployment
Your stack
Named engineer
Evidence first
After launch
Agent Care

What this agent does

Writes the review, never the sign-off

In

  1. 01

    A review is written, because DORA Art. 13(2) compels one and no rule consulted protects it.

  2. 02

    A cause is named, and 49 CFR 835.2 shields a conclusion while letting the facts beneath it in.

Reason

  1. 03

    A factor is added, and Burrage reads each one as another but-for antecedent open to a plaintiff.

  2. 04

    An action item is opened, and the gap before it closes is the theory Wyndham lost on.

  3. 05

    An action item is never taken, and Rule 407 excludes a fix that happened, not one that did not.

Decide

  1. 06

    A report is drawn for a regulator, and any divergence from the internal review is surfaced first.

  2. 07

    A review is written by norm alone, and Dowling read voluntary safety reviews as unprotected.

Out

  1. 08

    A cause is written for engineers, and FRE 801(d)(2)(D) admits it against the company unqualified.

  2. 09

    Execute write actions only inside the approval boundaries agreed during implementation.

Product statement

Assembling the timeline, attaching the evidence and holding the draft belong to the agent. Naming the cause and signing the review belongs to a named engineer, who answers for it afterwards.

Example workflow

One review, incident to sign-off

  1. 1Incident record receivedThe incident channel, the paging record, deploy history, tickets or telemetry
  2. 2Evidence assembledWhat each system shows, the source of each line, the hour it was seen and what is still unexplained
  3. 3Review draftedThe timeline, the candidate causes, the evidence under each and confidence
  4. 4Controls appliedEvidence checks, conclusion-form checks, action-item checks and confidence threshold

No human action required

Stages 1 to 4 run unaided, and nothing is signed at any of them — the agent is evidencing, and the engineer lane opens at the sign-off gate.

5DecisionSplits at the sign-off gate
Evidenced throughout

Goes to the named engineer to sign.

Anything unevidenced

Adds a service-owner read first.

Engineer review

The review is held with its timeline, its evidence and what it does not establish.

Sign · Amend · Send to owner review

Signed — by the named engineer

  1. 6Incident and tracker records updatedOnly where write access and records policy allow it
  2. 7Outcome evaluatedEvidence accuracy, amended causes, action items closed and what the next incident found

Corrections

Each engineer objection is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Naming the cause a review stands on.
    • Deciding what the regulator-facing report says.
    • Running a second, counsel-directed investigation.
    • Signing off a review for circulation.

  • Automation boundary

    Agent acts unaided

    • ✓Assemble the timeline from the systems of record.
    • ✓Attach the evidence under each candidate cause and mark what is missing.
    • ✓Keep the stated cause and the facts beneath it in separate fields.
    • ✓Hold the review for the engineer who signs it.

    Nothing is signed or circulated except by a named engineer, inside the agreed boundaries.

    • Closing an action item as done.
    • Judging whether an incident was preventable.
    • Deciding what a customer is told afterwards.
  • Changes to review rules or circulation scope.

Example output

One review, annotated

A telecom copilot ranks hypotheses against alarms and a manufacturing agent reconciles stop records; this one writes the software postmortem, a document with a second readership. Below is one review as the agent leaves it.

Review output · single incident

Illustrative example
Incident
Checkout API, failed writes
Recorded as
Connection pool exhausted under retry
Stated cause
Candidate cause
Evidence of record
Deploy log, 3 August 2026
Confidence
Held unsigned
Held for
The named engineer, by name

As received

Taken from the deploy log and the trace store — the agent vouches for what was read, not for what it caused.

What the record holds

  • Deploy log lines
  • Trace samples
  • Paging record

Why no cause is fixed here

Naming the root cause is a determination a named engineer owns.

What the score decides

Below the configured threshold a review gets an owner read before the engineer sees it.

Action

SignAmendSend to owner review

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Each review

From the incident that raised it

03Evidence

Where the evidence is used

Medicine has 42 U.S.C. 299b-22. Software has four district courts that split, and the two upholding privilege did so where the engineers were kept from the report.

01Approved path

The record outlives the outage

Six years of retention under 45 CFR 164.316(b)(2)(i), a search index and a link from the ticket: the reach that makes a review useful is the reach that makes it evidence.

02Human review

What was checked, and not found

No rule consulted confers a privilege on the internal review, requires the analysis to be correct, or requires an action item to be closed. NIS2 Art. 23(4)(d)(ii) asks only for the cause likely to have triggered the incident, and CIRCIA shields the report handed to CISA, not the wiki.

04

Build an evidence trail

The cause, the evidence beneath it and the engineer who signed it stay together.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Incident and paging

    • PagerDuty
    • Opsgenie
    • incident.io
    • Rootly
    • FireHydrant
    • Jeli

  • Telemetry and traces

    • Datadog
    • Grafana
    • New Relic
    • Honeycomb
    • OpenTelemetry

  • Trackers and action items

    • Jira Software
    • Linear
    • Shortcut
    • ServiceNow
    • Azure DevOps Boards

Agent

Root-cause analysis and reviews

  • Reads the evidence
  • Drafts the review
  • Holds for sign-off

  • Version control and deploys

    • GitHub
    • GitLab
    • Jenkins
    • Argo
    • Spinnaker
    • deploy and release logs

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six shutters between the model and the record

Six shutters over one window, the last the tightest. What is kept is set out in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeNarrow the agent to timeline assembly when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt and review rules, and note the version each review was drafted under.Track
L4TraceabilityRecord each review, the evidence under it, the hour it was drafted and who it reached.Record
L3Engineer sign-offHold the review for a named engineer; the hold governs release, not whether the cause is right.Gate
L2Evidence guardrailsTest each stated cause against its evidence, and return one the evidence does not carry.Restrict
L1Confidence thresholdsRoute a thin or unevidenced review to a service-owner read before the engineer sees it.Require review
Model coreReview drafted — the timeline, the candidate causes, the evidence under each and confidence
L1 – L2
Test whether a review may stand
L3
Leaves the sign-off to a named engineer
L4 – L5
Keep the cause and the evidence behind it
L6
Names contributing factors only when signals degrade

How Nestack evaluates it

Evaluate the whole review — not only the cause that comes out.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the review the incident record carries

  1. E1Final-output evaluationDid each stated cause stay inside the evidence attached to it?
  2. E2Step-level evaluationDid the agent read the right window, the right deploys and the live review rules?
  3. E3Tool evaluationDid it read and write the correct incident and the correct review?
  4. E4Confidence calibrationDo low-confidence reviews actually attract more engineer amendments?
  5. E5Slice evaluationHow does performance change across specific service classes?
  6. E6Business outcomeHow many reviews needed an amendment before the engineer signed one?

Floor — the record a supervisory authority reads back

Failure modes

Where each failure originates in the agent

Seven failure modes, each set where it first shows in the review.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • RW-03

      Stale evidence read

      The window read is not the window that failed.

    Stage gathers

    The logs, the deploys, the tickets and the window

  2. 02 · Reasoning

    2 modes

    • RW-04

      Cause asserted, not evidenced

      A cause is named with no reads beneath it.

    • RW-06

      Retired review rule read as live

      A superseded review rule is worked as current.

    Stage proposes

    The timeline, the causes and the evidence

  3. 03 · Tool / write

    2 modes

    • RW-02

      Thin review passed forward

      A review moves on without the owner read.

    • RW-05

      Review bound to wrong incident

      The review is filed against another incident.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • RW-01

      Signed, evidence unrecorded

      The record shows a sign-off but not the reads under it.

    Stage returns

    The review the record carries and a court later reads

  5. 05 · Change / Version

    1 mode

    • RW-07

      Silent conclusion drift

      A causal rule loosens while the stored review keeps the old one.

    Stage tracks

    Model, prompt, review rules and evidence config

  • Sev-1 · a cause signed on no evidence
  • Sev-2 · a wrong cause reaches the record
  • Sev-3 · evidence degrades, review held back
See the complete Engineering failure-mode catalogue

Affected slices

Repeat incidents absorb the amendments

A service-level evidence figure can read clean while repeat incidents on one service carry most of the amended causes. Nestack reports the amendment rate by service class, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Repeat incidents on one service7.9%3.7×Review
Multi-service cascading failures5.6%2.6×Review
Third-party and vendor causes3.5%1.6×Watch
Single-service degradations1.8%0.8×Normal

Bar: amendment-rate lift vs. single-service baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

What one open action item cost

A cycle ends when the action item nobody closed is a standing case. That suite is what the next review written is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Amendment rate rises on one service class.

  2. 02

    Diagnose

    The sentence that reads as candour in the room and as notice in a deposition is worked back through the evidence until one cause is left standing.

  3. 03

    Improve

    The change ships numbered, with the reviews that prompted it filed beneath.

  4. 04

    Verify

    One red review case is enough to hold the release back.

  5. 05

    Learn

    It is kept for good, and the reviewing rules are amended in that same commit.

  6. Learn → Detect

    The return edge. The next review is measured against a suite one case longer.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, review workflow, evaluation, integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Review discovery and automation-boundary definition.Week 1
  2. 02Telemetry, deploy and tracker sources.Week 1, Week 2
  3. 03Review-format and action-item-tracking rule mapping.Week 1, Week 2
  4. 04Incident-record ingestion.Week 2
  5. 05Evidence binding and review logic.Week 2, Week 3
  6. 06Confidence scoring and review routing.Week 3
  7. 07Engineer sign-off workflow.Week 3, Week 4
  8. 08Tracker-and-incident integration.Week 5
  9. 09Cause and evidence cases.Week 4, Week 5
  10. 10Guardrails and circulation controls.Week 4
  11. 11Review-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne service, one incident classProductionProduction review workflowAdvancedMultiple services / regimes
Introduced at Pilot
Reviews to your evidence rules✓✓✓
Named engineer sign-off✓✓✓
Incident-history baseline✓✓✓
Introduced at Production
Reporting by service class—✓✓
Owner review workflow in your systems—✓✓
Approved tracker write-back—✓✓
Telemetry-and-tracker integration—✓✓
Introduced at Advanced
Multi-regime review rules——✓
Cross-team review packs——✓
High incident volume——✓
Multi-service review controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, incident volume, review controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01Your live services and the incidents each one raises

    Incident capture and review-rule versioning

    Week 1

  2. 02Representative postmortems, tickets and telemetry

    Evidence binding, causal logic and the review baseline

    Week 2

  3. 03Your on-call rota and the service owners it names

    Review-format mapping, evidence binding and the automation boundary

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Telemetry, deploy and tracker assessment, then integration setup

    Week 2

  5. 05Reviews you would not want disclosed

    Evidence cases and the evaluation round

    Week 4

  6. 06What no review may conclude

    Confidence scoring, review routing, guardrails and circulation controls

    Week 3

  7. 07A named engineer who signs the review

    Release to the named reviewer, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

Widths come from the work and not the grid, and week five carries two because both truly run there.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Review-workflow discovery, review rules and the automation boundary

W2Telemetry and tracker integration and the incident-history baseline

W3Evidence binding, causal logic and circulation controls

W4Evaluation suite, evidence cases and failure-mode testing

W5Tracker integration, pilot reviews and targeted corrections

W6One reliability quarter run under the service owner, then Agent Care handover

Reading the band
A band spans the weeks its own work is named in, and nothing else. The week five overlap is real.
At the end of W6
Once the review record validates, Agent Care takes the agent on.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Engineering AI agent

Build a root-cause analysis agent around the postmortem your last incident left behind.

Show us one postmortem you would rather not produce, and the action item still open in it. It is read later by a regulator, by a plaintiff under FRE 801(d)(2)(D), and by whoever holds your job in six years. Aviation bought candour with statute; software bought a norm.

Typical delivery
4–6 weeks
Deployment
Your incident reviews
Named engineer
Evidence first
After launch
Agent Care available

Nestack Agents · Root-cause analysis

AGT-ENG-10 · Agent Care available after launch

Build a root-cause analysis agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your reviews

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.