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.
A finding is posted, and what the telemetry showed is kept apart from what it is taken to mean.
02
An hour is recorded on the finding, because Instruction 1 dates the determination from discovery.
Reason
03
A negative is asked for at hour two, and the agent returns the reads it can see, not the absence it cannot.
04
A breach is documented, and Article 33(5) makes that record the one a supervisory authority reads back.
05
A severity field is set, and under RTS (EU) 2025/301 that act starts the four-hour clock.
Decide
06
A finding contradicts what was already said in public, and it routes to the people who answer for saying it.
07
A conclusion is retracted, and the retraction is written as a new line with its own hour, not over the old one.
Out
08
A channel is summarised, and the raw messages stay beside the summary, because both are discoverable.
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
AgentHuman
1Signal receivedAlerting, logs, traces, the paging tool or a responder in the channel
2Observations assembledWhat the telemetry shows, the source of each line, the hour it was seen and what is still unknown
3Finding draftedThe observation, its sources, what it does not establish and confidence
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▼
6Incident and status records updatedOnly where write access and escalation policy allow it
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 required8 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 boundaryAgent 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 incidentIllustrative example
Incident
Recorded as
Observed
Evidence of record
Confidence
Held for
Payments API, degraded reads
Reads observed against one storage prefix
Observation only
Access log, 3 August 2026
Held unstated
The named commander, by name
As receivedTaken from the access logs and the paging record — the agent vouches for what was read, not for what it means.
What the record holdsAccess log linesPaging recordDeploy timeline
Why no conclusion hereConcluding that data was accessed is an act a named commander owns.
ActionStateAmendSend to responder review
What the score decidesBelow the configured threshold a finding gets a responder read before the commander sees it.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Each findingFrom 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.
04Build 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.
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 aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Suspected data exposure
11.1%
3.7×
Review
Third-party and vendor outages
7.9%
2.6×
Review
Newly onboarded services
4.9%
1.6×
Watch
Routine degradation incidents
2.2%
0.7×
Normal
Bar: correction-rate lift vs. routine-incident baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 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 stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Retracted-conclusion rate rises on one incident class.
02Diagnose
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.
03Improve
The change leaves numbered, with the findings that prompted it beneath it.
04Verify
One red finding case is enough to stop the release.
05Learn
It stays in the suite, and the escalation rules move with it.
Learn → DetectThe 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.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Incident discovery and automation-boundary definition.
02Paging, telemetry and channel sources.
03Statement-form and escalation-threshold rule mapping.
04Channel and log ingestion.
05Observation binding and finding logic.
06Confidence scoring and review routing.
07Commander statement workflow.
08Incident-system integration.
09Finding and escalation cases.
10Guardrails and statement controls.
11Finding-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal 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 priceConfirmed after discovery based on integrations, workflow complexity, incident volume, escalation controls and deployment requirements.
Separate from buildBuild 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.
You bringWe build with it
01Your live services and the incident classes each one raises→Incident capture and statement-rule versioningWeek 1
02Representative incidents, channels and telemetry→Source binding, observation logic and the finding baselineWeek 2
03Your on-call rota and the commanders it names→Statement mapping, escalation binding and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Paging, telemetry and channel assessment, then integration setupWeek 2
05Findings you would not want produced→Escalation cases and the evidence roundWeek 4
06What no finding may conclude→Confidence scoring, review routing, guardrails and statement controlsWeek 3
07A named commander who states the finding→Release to the named commander, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, 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.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Incident-workflow discovery, statement rules and the automation boundaryW2Paging and telemetry integration and the incident-record baselineW3Observation binding, finding logic and statement controlsW4Evaluation suite, escalation cases and failure-mode testingW5Channel integration, pilot incidents and targeted correctionsW6One incident quarter run under the reliability owner, then Agent Care handover
Reading the bandEach band covers the weeks its own work is named for, and the fifth is shared by design.
At the end of W6When the finding record validates, Agent Care assumes the agent.
DurationSix-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.
