Assemble outage notices from confirmed incident evidence, track the notification clocks that run from discovery, and hold each notice for the duty officer, who decides what is released and when.
Ingest incident records, alarm evidence and impact data from supported assurance, ticketing or incident sources.
02
Normalise element names, timestamps and time zones, and carry each fact forward with the system it came from.
Reason
03
Assemble the notice for one audience at a time — customer, enterprise account, public safety or regulator.
04
Apply the notification rules configured for that audience and that jurisdiction.
05
Bind each stated fact to confirmed incident evidence, and mark what is still unverified.
Decide
06
Track the clocks that run from discovery, and surface which deadline falls next.
07
Route the notice to the duty officer, who decides whether it is released.
Out
08
Retain the evidence, the notice, the officer's edits and what went to whom.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
The agent assembles notices, one audience at a time; the duty officer decides what is released, and the carrier stays the party the regulator holds to the duty.
Example workflow
One incident, discovery to release
AgentHuman
1Incident confirmedAssurance alarm, NOC incident ticket, field report or planned-work record
2Evidence assembledStart time with time zone, services and area affected, each with the system it came from
3Notice assembledAudience, content fields and confidence
4Controls appliedEvidence checks, audience and jurisdiction rules, duty-by-duty clock checks and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing is sent at any of them — the agent is assembling, and the duty officer's lane opens at the confidence gate.
5DecisionBranches at the confidence threshold
High confidence
Goes to the duty officer to approve.
Low confidence
Adds an incident-lead read first.
Duty-officer approval
The notice is held with its evidence, its unverified marks and the confidence.
Approve · Edit · Escalate to incident lead
Approved — released to send▼
6Notification systems updatedOnly where write access and approval policy allow it
7Outcome evaluatedTime to notice, edit distance, clock margin and corrections issued after the fact
Edits
Every officer edit is counted, and so is every notice corrected after it went out.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Releasing a notice to customers or the market.
Declaring an all-clear or a final assessment.
Filing or attesting anything to a regulator.
Granting, promising or calculating an SLA credit.
Automation boundaryAgent acts unaided
✓Assemble a notice for one audience from confirmed evidence.
✓Carry each stated fact forward with the system it came from.
✓Track each clock from discovery and surface the next deadline.
✓Hold the notice for the duty officer, and log what went.
Any send happens inside the boundaries agreed at implementation, never ahead of the officer's release.
Sending a PSAP or 988 facility notification.
Deciding whether a reporting threshold is met.
Treating one activation as covering another duty.
Changes to notification, jurisdiction or approval rules.
Example output
One outage notice, annotated
Everything the agent assembles is attached to the incident it was drawn from.
Notice output · single incidentIllustrative example
Incident
Drafted line
Start time
Source of record
Confidence
Audience
Regional voice fault
Voice calls are failing for subscribers in two metropolitan areas
02:45 UTC
Assurance incident record
88%
Enterprise account contacts
As receivedTaken from the incident record and the assurance evidence — nothing on this side is written by the agent.
Base rates differ by incident class, so an aggregate correction rate is only a weighted average of cohorts that do not behave alike. Nestack reports the officer-correction rate by slice, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Multi-jurisdiction incidents
8.6%
3.6×
Review
Enterprise account notices
6.0%
2.5×
Review
Planned-maintenance events
4.1%
1.7×
Watch
Single-market voice incidents
2.2%
0.9×
Normal
Bar: officer-correction-rate lift vs. single-market baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
The loop closes on a test, not a report
The cycle does not end in a post-mortem. It ends in a case the next release has to clear, and that suite is what the next notice out is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Officer-correction rate rises in an incident class.
02Diagnose
The duty officer who picked it up walks back through the notices and the evidence behind them until one cause holds.
03Improve
Each change carries a version and the notices that forced it.
04Verify
Release waits on the affected cases going green again.
05Learn
The case is kept for good, and the notification playbook is rewritten.
Learn → DetectThe return edge. The next detection runs against a suite that is 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, notification workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Incident communication workflow discovery and boundary definition.
02Assurance and incident source assessment.
03Jurisdiction, audience and notification-rule mapping.
04Incident ingestion and normalisation.
05Notice assembly and evidence binding.
06Confidence scoring and clock routing.
07Duty-officer approval workflow.
08Notification-channel integration.
09Clock and all-clear cases.
10Guardrails and release controls.
11Notice-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 network, one marketProductionProduction incident systemsAdvancedMultiple markets / jurisdictions
Introduced at Pilot
Assembly from your incident record✓✓✓
Duty-officer approval✓✓✓
Notice-accuracy baseline✓✓✓
Introduced at Production
Reporting by incident class—✓✓
Approval workflow in your systems—✓✓
Approved channel write-back—✓✓
Incident-system integration—✓✓
Introduced at Advanced
Multi-jurisdiction notification rules——✓
Multi-stage incident approvals——✓
High incident volume——✓
Multi-jurisdiction notice controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, transaction volume, approval 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 incident classes and notification triggers→Incident ingestion and evidence mappingWeek 1
02Representative notices from past incidents→Assembly baseline, wording extraction and evidence bindingWeek 2
03Your approved notice templates and standing wording→Jurisdiction, audience and notification-rule mappingWeek 1
04Access to relevant APIs, feeds or exports→Assurance and incident-source assessment, then integration setupWeek 2
05Notices you would not want sent→All-clear cases and failure-mode testingWeek 4
06What a notice may never declare on its own→Confidence scoring, clock routing, guardrails and release controlsWeek 3
07Named duty officers to review notices→Duty-officer approval workflow, 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
The bands sit on the weeks the work occupies, which is why the fifth carries two kinds at once.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Incident communication discovery, rule mapping and the automation boundaryW2Assurance and incident integration, and the assembly baselineW3Notification workflow, clock logic and release controlsW4Evaluation suite, all-clear checks and failure-mode testingW5Channel integration, pilot incidents and targeted correctionsW6One incident cycle communicated under the duty officer, then handover
Reading the bandEach bar covers only the weeks its work is named in. The fifth-week overlap is real work, not padding.
At the end of W6The cycle closes the validation and Agent Care takes over monitoring.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Telecom AI agent
Build an outage-communication agent around your incident process.
Show us your incident record and who holds the duty phone. Which clock would you struggle to evidence today? We'll map the workflow, set the boundary and name what stays with the officer.
