Main site

Operations AI agent · Incident response

Incident Response & Continuity AI Agent

Write down the hour somebody first knew, keep the facts, effects and remedial action beside it, and leave what is notifiable to the named lead who decides it.

Typical delivery
4–6 weeks
Deployment
Your stack
Named lead
Awareness hour
After launch
Agent Care

What this agent does

Keeps the record, never the notification

In

  1. 01

    An incident opens, and the hour somebody first knew is recorded before anything else about it is.

  2. 02

    A clock starts on a state of mind, not an event: Article 33 runs from having become aware.

Reason

  1. 03

    An hour fixed in a meeting leaves no system record, so whatever evidences it is gathered and held.

  2. 04

    A breach sits below the notification threshold, and Article 33(5) still requires it documented.

  3. 05

    A deadline passes, and Article 33(1) reads where feasible, so a late notice carries its reasons.

Decide

  1. 06

    A high-risk breach reaches Article 34, which carries no seventy-two-hour clock of its own.

  2. 07

    A determination of materiality is made, and Item 1.05 runs four business days from that, not discovery.

Out

  1. 08

    An exercise is run, and ISO 22301 keeps clause 8.5 and clause 8.6 apart, voluntary though it is.

  2. 09

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

Product statement

Recording, evidencing and clock-keeping belong to the agent. Deciding a breach is notifiable, and notifying anybody, belongs to a named human.

Example workflow

One incident, first hour to filed record

  1. 1Incident openedAlert, ticket, call bridge, supplier notice or somebody saying it out loud
  2. 2Awareness evidencedThe messages, pages, bridge joins and tickets that show when somebody first knew, each with its hour
  3. 3Record assembledThe facts, the effects, the remedial action and the candidate awareness hour
  4. 4Controls appliedSource-hour checks, regime-scope checks, gap checks and awareness confidence

No human action required

Stages 1 to 4 run unaided, and nothing is notified at any of them — the agent is recording, and the lead lane opens at the awareness gate.

5DecisionSplits at the awareness gate
Hour well evidenced

Goes to the named incident lead.

Anything thin

Adds a legal counsel read first.

Lead review

The incident is held with its facts, its evidenced hours and what the record still lacks.

Confirm hour · Add evidence · Send to legal review

Confirmed — by the incident lead

  1. 6Incident and continuity records updatedOnly where write access and records policy allow it
  2. 7Outcome evaluatedHour accuracy, evidence currency, lead corrections and what review found

Corrections

Each incident-lead correction is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Confirming the hour the company became aware.
    • Deciding that a breach is notifiable.
    • Notifying a supervisory authority or anybody else.
    • Determining whether an incident is material.

  • Automation boundary

    Agent acts unaided

    • ✓Collect what shows the hour somebody first knew.
    • ✓Document any breach with its facts, effects and remedial action.
    • ✓Keep the exercise programme and the evidence it left.
    • ✓Show which clock each regime would run from, and from what moment.

    Nothing is notified except by a named human, inside the boundaries agreed at implementation.

    • Judging whether an exercise proved the plan.
    • Telling a regulator what a timeline means.
    • Signing a filing that carries a manual signature.
  • Changes to the classes, the clocks or the contacts.

Example output

One incident record, annotated

This serves an operations team whose notification would name a contact point under Article 33(3)(b) and sign nothing; below is one incident as the agent leaves it.

Incident record · single event

Illustrative example
Incident
Unauthorised access, one system
Recorded as
Documented, hour evidenced
Class
Personal data breach
Evidence of record
Bridge log, 14 August 2026
Confidence
Held unnotified
Held for
The named incident lead

As received

Assembled from the alert log and the bridge record on file, and it asserts nothing beyond them.

What the record holds

  • Alert log
  • Bridge record
  • Remedial action

Why no notification here

Deciding a breach is notifiable is a judgement a named lead makes.

What the score decides

Below the configured threshold the incident gets a legal read before the lead sees it.

Action

Confirm hourAdd evidenceSend to legal 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

Every incident

From the hour it became known

03Evidence

Where the record sits

Banking owns DORA for financial entities, telecom owns the NIS2 Article 23 clocks and admin owns workplace injuries; this is an ordinary company keeping its own record of when it knew.

01Approved path

The clock starts when you knew

Nothing in the stack holds the moment somebody first knew, because it happens in a meeting, on a call, or in the head of the person who noticed.

02Human review

What was checked, and not found

Checked in the current text: CIRCIA has no final rule, and 6 U.S.C. 681b(a)(7) defers even its preservation duty, so nothing there binds today; the Cyber Resilience Act reaches manufacturers from 11 September 2026, not the companies using their products.

04

Build an evidence trail

The incident, the hour it became known and the person who knew stay together.

Integrations

Typical integrations

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

  • Detection and alerting

    • SIEM
    • EDR
    • monitoring
    • Paging and on-call records

  • Incident and service management

    • ServiceNow
    • Jira Service Management
    • PagerDuty
    • Opsgenie
    • xMatters

  • Collaboration records

    • Bridge recordings
    • chat channels
    • Meeting invitations and call logs

Agent

Incident response and continuity

  • Reads the hours
  • Builds the record
  • Holds for the lead

  • Continuity and exercise records

    • Business impact analyses
    • Exercise plans, reports and evaluations

  • 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 notice

Six shutters on one window, the last the slowest. What is seen is drawn in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeNarrow the agent to listing hours when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt and class rules, and note the version each incident was recorded under.Track
L4TraceabilityRecord each incident, the hours evidenced under it, the record built and every change to the file.Record
L3Lead releaseHold the incident for a named lead; the hold governs release, not whether the hour is right.Gate
L2Record guardrailsTest each record against the regime it was scoped to, and refuse an hour with no source under it.Restrict
L1Confidence thresholdsRoute a thinly evidenced hour to a legal read before the incident reaches the lead.Require review
Model coreIncident recorded — the hour, its sources, the facts, the effects and the gaps
L1 – L2
Test whether a record may stand
L3
Leaves the notification to a named human
L4 – L5
Keep the report and the hour behind it
L6
Records the hour and stops when signals degrade

How Nestack evaluates it

Evaluate the whole record — not only the hour that comes out of it.

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

Surface — the hour a supervisory authority asks about

  1. E1Final-output evaluationDid the record hold the hour it was actually evidenced from?
  2. E2Step-level evaluationDid the agent read the right alerts, the right bridge and the live class rules?
  3. E3Tool evaluationDid it read and write the correct incident and the correct evidence file?
  4. E4Confidence calibrationDo low-confidence hours actually attract more lead corrections?
  5. E5Slice evaluationHow does performance change across specific incident classes?
  6. E6Business outcomeHow many incidents needed a correction before the lead confirmed?

Floor — the hour a notification rests on

Failure modes

Where each failure originates in the agent

Seven failure modes, each placed at the stage where it first appears.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • NA-03

      Missed awareness signal

      The earliest message showing knowledge is not read.

    Stage gathers

    The alerts, the pages, the bridges and the hours

  2. 02 · Reasoning

    2 modes

    • NA-04

      Clock run from the wrong moment

      A duty is dated from the ticket, not the hour.

    • NA-06

      Regime scoped in without basis

      A record is built to a rule that does not bind.

    Stage proposes

    The hour, its sources, the facts and the effects

  3. 03 · Tool / write

    2 modes

    • NA-02

      Thin awareness record passed on

      An incident moves on without the legal read.

    • NA-05

      Evidence bound to wrong incident

      The file is stored against another incident.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • NA-01

      Notified, hour unrecorded

      The record shows a notice but not when you knew.

    Stage returns

    The record a lead confirms and an authority reads

  5. 05 · Change / Version

    1 mode

    • NA-07

      Silent class drift

      A class rule widens while stored records keep the old one.

    Stage tracks

    Model, prompt, class rules and contact records

  • Sev-1 · a notice sent on an unrecorded hour
  • Sev-2 · a wrong hour reaches the record
  • Sev-3 · source degrades, incident held open
See the complete Operations failure-mode catalogue

Affected slices

Third-party incidents absorb the corrections

A class-level awareness-timing figure can read clean while third-party and supplier incidents carry most of the corrections. 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
Third-party and supplier incidents11.3%3.7×Review
Incidents first raised verbally8.1%2.6×Review
Weekend and out-of-hours onsets5.1%1.7×Watch
Routine single-system alerts2.5%0.8×Normal

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

2 of 4 slices over threshold

Evidence-linked improvement

What an unrecorded hour costs

The cycle ends when the hour nobody recorded is a regression case. That suite is what the next timeline assembled is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Correction rate rises on third-party and supplier incidents.

  2. 02

    Diagnose

    The hour somebody first said out loud that this looked bad, which no system recorded, is worked backwards until one cause is left standing.

  3. 03

    Improve

    Changes ship numbered, with the timelines that drove them filed underneath.

  4. 04

    Verify

    Nothing ships while one timeline case is still failing.

  5. 05

    Learn

    One case joins the suite, one line joins the notification rules.

  6. Learn → Detect

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

Workstream

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

  1. 01Incident-classification and automation-boundary work.Week 1
  2. 02Alerting, ticketing and bridge sources.Week 1, Week 2
  3. 03Awareness-evidence and clock-derivation mapping.Week 1, Week 2
  4. 04Incident and evidence ingestion.Week 2
  5. 05Hour, source and record binding.Week 2, Week 3
  6. 06Awareness scoring and review routing.Week 3
  7. 07Lead confirmation workflow.Week 3, Week 4
  8. 08Service-management integration.Week 5
  9. 09Awareness and timeline cases.Week 4, Week 5
  10. 10Guardrails and notification controls.Week 4
  11. 11Timeline-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 class, one siteProductionProduction incident workflowAdvancedMultiple sites / regimes
Introduced at Pilot
Incident recording to your classes✓✓✓
Named lead confirmation✓✓✓
Dependency-mapping baseline✓✓✓
Introduced at Production
Reporting by incident class—✓✓
Lead review workflow in your systems—✓✓
Approved write-back—✓✓
Alerting-and-paging integration—✓✓
Introduced at Advanced
Multi-regime record sets——✓
Cross-site evidence packs——✓
Large incident volumes——✓
Multi-regime notification controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, incident volume, approval 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 incident classes and the rule each is scoped to

    Class capture and clock derivation

    Week 1

  2. 02Representative alerts, bridges and exercise reports

    Evidence binding, hour logic and the record baseline

    Week 2

  3. 03Your escalation path and the leads it names

    Class mapping, clock derivation and the automation boundary

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Alerting, ticketing and bridge-record assessment, then integration setup

    Week 2

  5. 05Timelines you would not want reconstructed

    Awareness cases and the evaluation round

    Week 4

  6. 06What no timeline may conclude

    Awareness scoring, review routing, guardrails and release controls

    Week 3

  7. 07A named incident lead who confirms the hour

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

Where the bands overlap, the phases overlap; the fifth week is a measurement and not a compromise.

Phase

W1

W2

W3

W4

W5

W6

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

Week focus

W1Class discovery, clock derivation and the automation boundary

W2Source integration and the incident-record baseline

W3Evidence binding, awareness logic and release controls

W4Evaluation suite, awareness cases and failure-mode testing

W5Service-management integration, pilot incidents and targeted corrections

W6One exercise cycle run under the continuity lead, then Agent Care handover

Reading the band
Each bar covers only the weeks its own work is named for, and week five is shared by design.
At the end of W6
When the timeline 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 · Operations AI agent

Build an incident response agent around the hour nobody wrote down.

Show us one incident from last year and the hour you first knew of it. Every clock here starts on a state of mind — reasonably believes, becoming aware, having become aware, a materiality determination — never on the event. The general US duty is state law, not federal.

Typical delivery
4–6 weeks
Deployment
Your incident record
Named lead
Awareness hour
After launch
Agent Care available

Nestack Agents · Incident response

AGT-OP-11 · Agent Care available after launch

Build an incident response agent

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.