# Incident Commander: Incidents Coordinated, Lessons Turned Into Fixes > The Incident Commander is the AI incident management agent in the Ai1 platform by MyZone AI: when a problem spans your apps and agents, it opens one incident record, brings in each owner, closes only on evidence and runs a blameless postmortem, while owners make the fixes. Canonical page: https://myzone.ai/pages/agents/ai-incident-commander-agent Part of Ai1, by MyZone AI. Book a Commander walkthrough: https://calendly.com/d/ct6h-tcy-8qf/ai1-demo?a1=Incident%20Commander&utm_source=myzone.ai&utm_medium=agent-page&utm_content=ai-incident-commander-agent-final Last updated: 2026-10-14. Reviewed by the MyZone AI team. One record, the right owners and proof of the fix when systems fail together. ## At a glance - **It steps in for:** Problems that hit more than one app or shared service; a single app's bug goes to its owner - **One record:** A single timeline, decision log and evidence index, with facts and guesses kept apart - **The owners:** Each affected owner is called in, acknowledgements are tracked and updates keep a steady rhythm - **Closing:** Only when there is evidence for every exit test, never on someone's word alone - **Afterwards:** A blameless postmortem with owned actions followed to a verified close - **What it never does:** Make the fix itself, or put secrets, raw logs or private customer records in the record ## What the Incident Commander does - **Declares the incident:** When a problem hits more than one app or shared service, it checks the evidence, rates the severity and opens one incident record. - **Keeps one incident record:** A single timeline, decision log and evidence index, with facts, guesses, decisions and risks kept clearly apart. - **Brings in the owners:** It calls in the owner of each affected system, sets the update rhythm and tracks who has acknowledged. - **Verifies the fix:** It checks recovery against the agreed exit tests, using evidence from the people who made the fix. - **Runs blameless postmortems:** It sorts root and contributing causes, turns them into owned actions and follows each one to a verified close. - **Drills your response:** Practice incidents with sample data test how fast your team declares, responds and recovers, before a real one does. ## How the Incident Commander differs from a scramble in a group chat In a group chat, facts and guesses blur together, and people drift off without anyone noticing. The Incident Commander keeps a single record, calls in each affected owner and tracks who has acknowledged. It closes an incident only on evidence for every exit test, then runs a blameless postmortem with owned actions. The owners make every fix in their own systems, so the commander never touches them. How this differs from the Uptime Monitor (https://myzone.ai/pages/agents/ai-uptime-monitoring-agent): To find out when a site goes down, use the Uptime Monitor; the Incident Commander takes charge when an outage spans your apps and agents and keeps one record until it is fixed. ## How it works 1. **Spot and declare** (The moment a problem crosses apps): A problem touching several apps becomes a declared incident with a severity rating. A single app's bug goes straight to its owner. 2. **Convene the owners** (Straight after it is declared): The owner of each affected system is called in, acknowledgements are tracked and updates follow a steady rhythm. 3. **Command while owners fix** (While owners fix): Owners make the fixes in their own systems while it keeps the record, the decisions and the blockers in one place. 4. **Close on evidence** (Before the incident closes): Recovery is checked against every exit test. If the evidence is not there, the incident stays open. 5. **Learn and prevent** (After recovery): A blameless postmortem names the causes, gives every action an owner and adds what was learned to your runbooks. ## When to use it - **Several apps slow down at the same time:** One incident is declared, every affected owner is called in and everyone follows the same record. - **A fix is reported done but users still see errors:** Recovery is checked against the exit tests, and the incident stays open until the evidence holds. - **The same outage keeps coming back:** The postmortem finds the contributing causes and tracks each preventive action until it is verified closed. - **You want to know your team is ready:** A practice incident scores how quickly owners respond and recover, and shows what to tighten. - **A shared service fails during a busy period:** Owners get on with the fix while the commander handles updates, decisions and the timeline. ## What you get - One incident record per event, with timeline, decision log and evidence - A severity rating for every declared incident - Consolidated status updates with acknowledgements tracked - Evidence-backed resolution against agreed exit tests - Blameless postmortems with owned, verified actions - A growing runbook index and practice drill results ## Example: incident report and blameless postmortem Example with a fictional company. Names, people and figures are invented to show the agent's output. Any resemblance to a real company or person is unintended. What it was asked: Tell me exactly what happened on Friday, whether it is really fixed, and what we are changing so it does not happen again. This is an illustrative example of the incident report and blameless postmortem Incident Commander is being built to produce: timeline, single incident record, evidence-based exit criteria and owned actions. It was written by hand from the agent's design for an invented company with an invented incident, teams and figures. No real systems or people were involved, and nothing was sent, posted or changed. Run date: 14 October 2026. ### What it found - A renewed access key reached only one of two places, stalling order sync for 2 hours; all 412 held orders reached the warehouse, with none lost or charged twice. - The incident was declared 8 minutes after the first alert and resolved only when all five exit criteria had evidence, including a matched count of 412 orders. - Five postmortem actions each have an owner, proof and date; two are done, and this is the second key-expiry incident this year. ## Guardrails - Your Ai1 team will tell you when the Incident Commander is ready for your account. - It coordinates and verifies. It never makes the fix itself, and every change to your systems stays with its owner. - It closes an incident only on evidence for every exit test, never on someone's word alone. - Security incidents have one owner, the Security Agent, and Incident Commander supports only when asked. - Secrets, raw logs and private customer records never go into the incident record or its reports. ## Frequently asked questions ### What does an incident commander actually do during an outage? They coordinate rather than fix: declare the incident, rate its severity, call in the owner of each affected system, set the update rhythm and keep one record of decisions. The Incident Commander does this for your apps and agents while the owners make the fixes. ### How do you run a blameless postmortem that changes things? Look at root and contributing causes in the system, not at who to blame, then turn each cause into an action with an owner and a finish line. The Incident Commander follows every action to a verified close and adds lessons to runbooks your team can reuse. ### How do you coordinate several teams when systems fail together? Give everyone one source of truth and track who has acknowledged. Incident Commander opens a single record, calls in each affected owner, keeps updates on a steady rhythm and logs facts, guesses, decisions and risks separately, so nobody works from an old message. ### What does AI incident management from Incident Commander cover? Problems that hit more than one of your apps, agents or shared services. It declares the incident, keeps one record, brings in the owners, verifies the fix and runs a blameless postmortem. ### Does it fix the problem itself? No. The owner of each system makes the fix. Incident Commander keeps everyone coordinated, records decisions and checks the evidence that the fix worked. ### What if only one app is broken? That goes straight to the app's owner as a normal bug. Incidents are kept for problems that cross apps or shared services. ### What makes the postmortems blameless? They look at causes and contributing factors in the system, not at who to blame. Every action gets an owner, a finish line and proof that it was done. ### Can we practise before a real incident? Yes. Practice drills use sample data to test how quickly your team declares, responds and recovers, and the findings go to the right owners. ### Is the Incident Commander available now? Not yet. Your Ai1 team will tell you when the Incident Commander is ready for your account. You can talk to us today about how your team handles outages. ## More on this topic - [Multi-Agent Development: Why the Future of Software Is Built by AI Teams](https://myzone.ai/pages/blog/multi-agent-development): Discover how multi-agent AI systems are transforming software development. Teams of specialised AI agents build products 10x faster at lower cost. ## About Ai1 Ai1 is the AI operations platform by MyZone AI, where each client runs on its own private server. The Incident Commander is not sold on its own: every Ai1 agent, including this one, is included on Developer Pro and every Fully Managed option, with no per-agent charge. Developer Core includes the development agents. Pricing: https://myzone.ai/pages/services/ai1-pricing. Security: https://myzone.ai/pages/security.