Human-centered design systems and product experiences
Core services
01UI/UX Design02Web Development03Software Development042D/3D Experiences05App Development06AI Agents & Automation07Website DesignTechnical services
Frontend Engineering
React DevelopmentNext.js DevelopmentWeb ApplicationsEnterprise DashboardsSaaS PlatformsBackend & Infrastructure
API DevelopmentCloud InfrastructureDevOps & CI/CDBackend SystemsCustom SoftwareIndustries we serve
Technology & Software
AI Incident Response Coordination Agent Development
The timeline kept while you fix it
An agent for the middle of an outage.
An agent for the middle of an outage. It keeps the timeline, runs the read-only checks your runbooks allow, tracks who is doing what, drafts the stakeholder updates for the incident lead to send and prepares the review afterwards. It changes nothing in production.
During an incident the people who can fix it are also expected to write things down, update stakeholders and remember what was tried. They do not, because they are busy. Half an hour in, someone joins and asks what has happened so far, and three people stop to explain. Afterwards the review is reconstructed from chat scrollback, and the detail that mattered is missing.
This page describes a workflow we propose to build as a custom project. It does not exist as software yet. It would reuse the action log that every one of our demonstrations keeps, where each step is recorded with its result, and the approval routing from our IT helpdesk demonstration, where sensitive actions are requested and never carried out. Incident tooling connections, the timeline and status updates are not built.
From the First Signal to the Record
An example of one case, in 6 steps. The same steps play in the picture at the top of this page.
Incident declared
An engineer declares an incident after checkout errors rise.
Timeline started
The agent starts the timeline and names the incident lead from the rota.
Checks run
It posts the error dashboard, the deployments of the last two hours and the service's recent logs.
Summary kept
A manager joins and reads the current summary. Nobody stops work to explain.
Update drafted
A customer-facing update with confirmed facts only is drafted. The lead edits and sends it.
Review prepared
After resolution the timeline, the open questions and four follow-up actions are ready for the review.
Where the Time Goes Now
Nobody is writing it down
The timeline exists only in a fast-moving chat.
What has happened so far
Every person who joins asks the same question.
Updates that never go out
Stakeholders hear nothing for an hour.
Two people doing the same thing
And nobody doing the third thing.
Changes nobody recorded
A config was altered mid-incident and forgotten.
Reviews from memory
The post-incident review misses what really happened.
Six jobs it carries through
01Timeline
Keeps the record as it happens.
- Events with their times
- Decisions and who made them
- Actions taken and their results
- Built from the incident channel and tools
02Situation summary
Answers "what has happened so far".
- A short, current summary
- What is known and unknown
- What has been tried
- Updated as things change
03Permitted checks
Runs read-only checks from your runbooks.
- Dashboards and health checks
- Recent deployments and changes
- Logs for the affected service
- Results posted to the channel
04Role and task tracking
Tracks who is doing what.
- The incident lead and roles
- Tasks and their owners
- Tasks nobody has picked up
- Reminders at your interval
05Update drafting
Drafts updates for the lead to send.
- Internal and customer-facing versions
- Your templates and tone
- Only confirmed facts
- Sent by the incident lead
06Review preparation
Prepares the post-incident review.
- The full timeline
- Contributing factors raised during the incident
- Open questions
- Follow-up actions with owners
What We Need to Scope This
- The process as it runs today, in a few lines.
- The systems it touches, for example incident tooling, chat, monitoring, deployments.
- Rough monthly volume, and who approves what.
Read-Only During the Incident, and the Lead Sends Every Update
An incident is the worst moment for an automated system to change something. The agent has read access to monitoring and deployment history and no ability to roll back, restart or reconfigure. It gathers, records and drafts.
Updates to customers and executives contain only confirmed facts and are sent by the incident lead. The post-incident review is prepared from the record, and its conclusions are the team's.
- Read-only access during incidents
- No rollbacks, restarts or changes
- Summaries state what is unknown
- Updates sent by the incident lead
- Confirmed facts only
- A complete timeline for the review
The Systems Around It
The systems named here are the kind this agent works with. Which ones it connects to in your case is settled in the scope.
Incident tooling
- PagerDuty
- Opsgenie
- incident.io
- or your process
Chat
- Slack
- Microsoft Teams
Monitoring
- Dashboards, alerts and logs
Deployments
- Your release and change history
Status page
- Customer-facing updates, sent by a person
Runbooks
- The checks and procedures you approved
Straight Answers
Can it fix the incident?
No. It has no ability to change production. It can run the read-only checks your runbooks list and put the results in front of the people who can fix it. Whether to automate any remediation is a separate decision for your engineering leadership.
How is this different from the security alert triage agent?
Triage works on individual security alerts and decides whether one is real. This agent starts once an incident of any kind is declared, and its job is coordination: timeline, tasks, updates and the review.
How is this different from the workflow exception agent?
The exception agent investigates individual failed records while systems are up. This agent supports people during a declared outage. A burst of exceptions is often the first sign that an incident should be declared.
What exists today?
Not as software yet. This page describes a proposed workflow. It would reuse the action log that every one of our demonstrations keeps, where each step is recorded with its result, and the approval routing from our IT helpdesk demonstration, where sensitive actions are requested and never carried out. Incident tooling connections, the timeline and status updates are not built. A project starts by mapping your process, then proving the first steps on test data before anything touches a live system.
Read Your Last Incident's Chat Log
Count how often someone asked what had happened so far, and how long stakeholders waited for the first update.