Main site

Engineering AI agent · Incident response

Incident-Response Copilot AI Agent

Observe before you conclude: post what the telemetry shows, with its source and its hour, and leave the sentence that concludes anything to the named incident commander who owns it.

Typical delivery
4–6 weeks
Deployment
Your stack
Named commander
Observation
After launch
Agent Care

What this agent does

Observes the incident, never concludes it

In

  1. 01

    A finding is posted, and what the telemetry showed is kept apart from what it is taken to mean.

  2. 02

    An hour is recorded on the finding, because Instruction 1 dates the determination from discovery.

Reason

  1. 03

    A negative is asked for at hour two, and the agent returns the reads it can see, not the absence it cannot.

  2. 04

    A breach is documented, and Article 33(5) makes that record the one a supervisory authority reads back.

  3. 05

    A severity field is set, and under RTS (EU) 2025/301 that act starts the four-hour clock.

Decide

  1. 06

    A finding contradicts what was already said in public, and it routes to the people who answer for saying it.

  2. 07

    A conclusion is retracted, and the retraction is written as a new line with its own hour, not over the old one.

Out

  1. 08

    A channel is summarised, and the raw messages stay beside the summary, because both are discoverable.

  2. 09

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

Product statement

Observing, sourcing and holding belong to the agent. Concluding, and saying anything outside the channel, belongs to a named incident commander who answers for it afterwards.

Example workflow

One finding, telemetry to statement

  1. 1Signal receivedAlerting, logs, traces, the paging tool or a responder in the channel
  2. 2Observations assembledWhat the telemetry shows, the source of each line, the hour it was seen and what is still unknown
  3. 3Finding draftedThe observation, its sources, what it does not establish and confidence
  4. 4Controls appliedSource checks, conclusion-form checks, negative-assertion checks and confidence threshold

No human action required

Stages 1 to 4 run unaided, and nothing leaves the channel at any of them — the agent is observing, and the commander lane opens at the statement gate.

5DecisionSplits at the statement gate
Observation only

Goes to the named commander to state.

Anything conclusive

Adds a second responder read first.

Commander review

The finding is held with its sources, what it does not establish and the confidence.

State · Amend · Send to responder review

Stated — by the named commander

  1. 6Incident and status records updatedOnly where write access and escalation policy allow it
  2. 7Outcome evaluatedSource accuracy, retracted conclusions, commander corrections and what the review found afterwards

Corrections

Each commander correction is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Determining that an incident is material.
    • Notifying a regulator, a customer or the market.
    • Stating that no customer data was affected.
    • Classifying an incident as major under DORA.

  • Automation boundary

    Agent acts unaided

    • ✓Post what the telemetry shows, with its source and hour.
    • ✓Keep the observation and the conclusion apart in the same record.
    • ✓Mark what a finding does not establish, alongside what it does.
    • ✓Hold each finding for the commander who states it.

    Nothing leaves the channel except by a named commander, inside the agreed boundaries.

    • Declaring the incident resolved.
    • Deciding what the status page says.
    • Naming a root cause in a regulator-facing report.
  • Changes to escalation rules or statement thresholds.

Example output

One finding, annotated

An operations agent records the hour somebody first knew and a banking agent builds the notification packs; this one is in the channel while nobody yet knows. Below is one finding as the agent leaves it.

Finding output · single incident

Illustrative example
Incident
Payments API, degraded reads
Recorded as
Reads observed against one storage prefix
Observed
Observation only
Evidence of record
Access log, 3 August 2026
Confidence
Held unstated
Held for
The named commander, by name

As received

Taken from the access logs and the paging record — the agent vouches for what was read, not for what it means.

What the record holds

  • Access log lines
  • Paging record
  • Deploy timeline

Why no conclusion here

Concluding that data was accessed is an act a named commander owns.

What the score decides

Below the configured threshold a finding gets a responder read before the commander sees it.

Action

StateAmendSend to responder 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 finding

From the telemetry that carries it

03Observation

Where the observation is used

Work-product protection turned, in the rulings consulted, on whether the analysis reached the responders; an agent whose value is that it reaches them cannot be configured to preserve it.

01Approved path

Somebody now knows

The triggers in force run off states held by engineers — discovery, awareness, reasonable belief, determination — and the law reads them off whatever the channel wrote.

02Human review

What was checked, and not found

No rule consulted sets a time to restore a service, requires an incident commander to exist, or obliges anyone qualified to be in the room. CIRCIA is the exception most often cited, and it binds nobody: reporting is not required until the effective date of a final rule that has not been published.

04

Build an evidence trail

The finding, the hour it was written and the responder who wrote it stay together.

Integrations

Typical integrations

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

  • Alerting and paging

    • PagerDuty
    • Opsgenie
    • Splunk
    • Incident.io
    • Rootly
    • Blameless

  • Telemetry and logs

    • Datadog
    • Grafana
    • Honeycomb
    • Splunk
    • Elastic
    • CloudWatch

  • Channel and comms

    • Slack
    • Microsoft Teams
    • Zoom bridges
    • Statuspage
    • Instatus
    • Twilio

Agent

Incident response and findings

  • Reads the telemetry
  • Drafts the finding
  • Holds the statement

  • Ticketing and records

    • Jira Service Management
    • ServiceNow
    • Confluence
    • evidence stores

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

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

Agent controls

Six doors between the model and the channel

Six doors off one corridor, the last the heaviest. What passes is drawn in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeNarrow the agent to raw observations when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt and statement rules, and note the version each finding was drafted under.Track
L4TraceabilityRecord each finding, the sources under it, the hour it was written and every read of the record.Record
L3Commander releaseHold the finding for a named commander; the hold governs release, not whether the finding is right.Gate
L2Statement guardrailsTest each finding against its sources, and return one that states a conclusion those sources do not carry.Restrict
L1Confidence thresholdsRoute a thin or unsourced finding to a second responder read before the commander sees it.Require review
Model coreFinding drafted — the observation, its sources, what it does not establish and confidence
L1 – L2
Test whether a finding may stand
L3
Leaves the statement to a named commander
L4 – L5
Keep the finding and the hour behind it
L6
States the observation only when signals degrade

How Nestack evaluates it

Evaluate the whole channel — not only the finding that comes out.

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

Surface — the finding the incident record carries

  1. E1Final-output evaluationDid the finding stay inside what its sources actually showed?
  2. E2Step-level evaluationDid the agent read the right logs, the right window and the live escalation rules?
  3. E3Tool evaluationDid it read and write the correct incident and the correct record?
  4. E4Confidence calibrationDo low-confidence findings actually attract more commander corrections?
  5. E5Slice evaluationHow does performance change across specific incident classes?
  6. E6Business outcomeHow many findings needed a correction before the commander stated one?

Floor — the record a regulator later reads

Failure modes

Where each failure originates in the agent

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

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • QX-03

      Stale telemetry read

      The window read is not the window that matters.

    Stage gathers

    The alerts, the logs, the window and the responders

  2. 02 · Reasoning

    2 modes

    • QX-04

      Conclusion drafted from absence

      A negative is stated where nothing was seen.

    • QX-06

      Retired escalation rule read as live

      A superseded statement rule is worked as current.

    Stage proposes

    The observation, its sources and what is unknown

  3. 03 · Tool / write

    2 modes

    • QX-02

      Thin finding passed forward

      A finding moves on without the responder read.

    • QX-05

      Finding bound to wrong incident

      The observation is filed against another incident.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • QX-01

      Stated, sources unrecorded

      The record shows a statement but not the reads under it.

    Stage returns

    The finding the incident record carries to a regulator

  5. 05 · Change / Version

    1 mode

    • QX-07

      Silent statement drift

      A conclusion rule loosens while the stored record keeps the old one.

    Stage tracks

    Model, prompt, statement rules and escalation config

  • Sev-1 · a conclusion stated on no evidence
  • Sev-2 · a wrong finding reaches the record
  • Sev-3 · sources degrade, finding held back
See the complete Engineering failure-mode catalogue

Affected slices

Suspected exposure absorbs the corrections

A class-level statement figure can read clean while suspected data exposure carries most of the retracted conclusions. Nestack reports the correction rate by incident class, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Suspected data exposure11.1%3.7×Review
Third-party and vendor outages7.9%2.6×Review
Newly onboarded services4.9%1.6×Watch
Routine degradation incidents2.2%0.7×Normal

Bar: correction-rate lift vs. routine-incident baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

What one line at three in the morning said

A loop ends when the conclusion stated before the evidence is a standing case. That suite is what the next incident run is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Retracted-conclusion rate rises on one incident class.

  2. 02

    Diagnose

    The line posted at three in the morning that told a regulator when the company knew is read back through the channel until a single cause remains.

  3. 03

    Improve

    The change leaves numbered, with the findings that prompted it beneath it.

  4. 04

    Verify

    One red finding case is enough to stop the release.

  5. 05

    Learn

    It stays in the suite, and the escalation rules move with it.

  6. Learn → Detect

    The return edge. The next incident runs 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, finding workflow, evaluation, integration, then production validation and handover.

Workstream

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

  1. 01Incident discovery and automation-boundary definition.Week 1
  2. 02Paging, telemetry and channel sources.Week 1, Week 2
  3. 03Statement-form and escalation-threshold rule mapping.Week 1, Week 2
  4. 04Channel and log ingestion.Week 2
  5. 05Observation binding and finding logic.Week 2, Week 3
  6. 06Confidence scoring and review routing.Week 3
  7. 07Commander statement workflow.Week 3, Week 4
  8. 08Incident-system integration.Week 5
  9. 09Finding and escalation cases.Week 4, Week 5
  10. 10Guardrails and statement controls.Week 4
  11. 11Finding-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 incident channelAdvancedMultiple services / regimes
Introduced at Pilot
Findings to your escalation rules✓✓✓
Named commander statement✓✓✓
Incident-record baseline✓✓✓
Introduced at Production
Reporting by incident class—✓✓
Responder review workflow in your systems—✓✓
Approved record write-back—✓✓
Paging-and-telemetry integration—✓✓
Introduced at Advanced
Multi-regime statement rules——✓
Cross-team escalation packs——✓
High incident volume——✓
Multi-regime escalation controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, incident volume, escalation 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 incident classes each one raises

    Incident capture and statement-rule versioning

    Week 1

  2. 02Representative incidents, channels and telemetry

    Source binding, observation logic and the finding baseline

    Week 2

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

    Statement mapping, escalation binding and the automation boundary

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Paging, telemetry and channel assessment, then integration setup

    Week 2

  5. 05Findings you would not want produced

    Escalation cases and the evidence round

    Week 4

  6. 06What no finding may conclude

    Confidence scoring, review routing, guardrails and statement controls

    Week 3

  7. 07A named commander who states the finding

    Release to the named commander, 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

These bands are sized by the work inside them, so the fifth holds two and none was padded to match.

Phase

W1

W2

W3

W4

W5

W6

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

Week focus

W1Incident-workflow discovery, statement rules and the automation boundary

W2Paging and telemetry integration and the incident-record baseline

W3Observation binding, finding logic and statement controls

W4Evaluation suite, escalation cases and failure-mode testing

W5Channel integration, pilot incidents and targeted corrections

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

Reading the band
Each band covers the weeks its own work is named for, and the fifth is shared by design.
At the end of W6
When the finding record validates, Agent Care assumes the agent.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Engineering AI agent

Build an incident-response copilot around the sentence your last incident should not have written.

Show us one incident channel and the line in it that first said what had happened. Not how quickly you fixed it. What you said while you did not yet know, and the hour you said it. A conclusion the evidence did not carry comes back as a finding.

Typical delivery
4–6 weeks
Deployment
Your incident channel
Named commander
Observation first
After launch
Agent Care available

Nestack Agents · Incident response

AGT-ENG-05 · Agent Care available after launch

Build an incident-response copilot

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

About you
Your incidents

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