Key takeaways
- Draft updates from timestamped evidence, keeping measured impact distinguishable from a working explanation.
- Give responders and customers the detail they need without carrying sensitive internal information into a public message.
- Have an authorized person review the exact version being sent, and revisit earlier messages when the evidence changes.
You are in the middle of an incident. Someone is checking a deployment, another person is comparing error rates and a customer-facing team needs an update it can send now. The facts are changing while you are trying to turn them into a coherent explanation.
An agent could gather timestamped alerts, service measurements and responder notes, then use them to draft updates for each audience. A designated person reviews the evidence and approves the exact message before it is sent. As the investigation changes, the agent compares new findings with earlier messages and flags statements that need correcting.
This article describes a proposed incident-communication workflow. The examples are fictional; they are not a Moring deployment or performance claim.
Give the communication work an owner
Google’s incident-response guidance describes separate incident-command, operations and communication responsibilities. That separation is helpful when the people investigating should not also have to answer every request for a status update.
An agent fits into the communication workflow as drafting support. Your incident process determines who approves a message: perhaps a communications lead, the incident commander or another designated person. It need not make one already-busy person the approver for every audience.
The reviewer needs a quick way to inspect the evidence behind a sentence. A confident paragraph without its source observations leaves them doing the investigation again.
Assemble a view of what is known now
For each proposed update, the agent could gather the latest relevant alerts, service measurements, changes and responder notes. The record should preserve when the event occurred, when the source was checked and which incident it belongs to.
Those times can differ. A monitoring query completed now may describe an earlier interval. A delayed message might refer to a mitigation that has already been abandoned. If sources disagree, the draft should surface the disagreement for review.
A practical evidence view separates:
- Observed impact: what the available measurements or confirmed reports show, over a stated period.
- Working explanation: a possible cause responders are investigating.
- Unknowns: areas not checked, unavailable data and questions still open.
- Actions: what has actually been approved or started, distinguished from a suggestion in the incident channel.
“No errors in the available measurements” has a narrower meaning than “no customers are affected.” The agent needs to preserve that difference. It also needs to avoid treating a recent deployment as the cause merely because it preceded the incident.
A worked example: checkout failures
The following times and measurements are invented to illustrate the workflow.
At 14:07 UTC, an alert reports elevated failures on a checkout endpoint. At 14:22 UTC, responders have verified that the measured request error rate is 18%. A deployment happened at 13:55 UTC, but its role is still being investigated. The available evidence does not yet establish the number of affected customers, whether transactions were lost or when service will recover.
An internal responder draft could say:
Responder update, 14:22 UTC: Checkout endpoint failures remain elevated. The current measured request error rate is 18%. Responders are investigating the 13:55 deployment as a possible contributor. Cause and recovery time remain unconfirmed. Transaction reconciliation is still pending.
A customer draft would need less diagnostic detail:
Customer update, 14:22 UTC: Some checkout attempts are failing. The team is investigating and will provide another update by 14:40 UTC.
The next-update time is a commitment the communications owner has chosen for this example. It is not a prediction that the incident will be resolved by then.
Atlassian’s incident-communication guidance emphasizes planning for different audiences and keeping people informed. In this workflow, that means generating each draft from the same evidence while changing the level of detail. An executive update may also include confirmed business impact and any decision leadership needs to make. It should not invent a revenue estimate because the template has a field for one.
An improving graph does not settle the investigation
Continue the fictional example. At 14:38 UTC, an authorized responder begins a rollback. The communications owner sends the promised 14:40 UTC update to say the work continues. At 14:47 UTC, the measured error rate has fallen to 6%. Responders have not yet established a sustained recovery or completed transaction reconciliation.
An updated customer draft could say:
Customer update, 14:47 UTC: The team has rolled back a recent change and checkout errors have decreased. Some attempts are still failing. We are monitoring the service and will update you again by 15:00 UTC.
That message reports progress without declaring the incident resolved. The internal draft can retain the rollback version, approval and measurement window for responders who need them.
When an earlier update turns out to be wrong
Consider a variation of the same fictional incident. Suppose an earlier public message said that saved-card checkout was unaffected, based on the checks available then. Later transaction checks reveal failures on that path too. A falling overall error rate does not repair the earlier statement.
The agent could flag the conflicting claim and draft this for review:
Correction: Our earlier update said saved-card checkout was unaffected. Further checks have confirmed that some saved-card checkout attempts are also failing. That checkout path is included in the ongoing investigation. We will provide the next update by 15:00 UTC.
The reviewer can now examine what the new checks establish and whether the correction describes the affected path accurately. Retaining the previous message alongside the correction also preserves what customers were told and when the understanding changed.
Review the exact message that will be sent
Approval should apply to a particular version, audience and destination. If the agent changes the text after review, the changed message needs review again. Otherwise, the approved wording and the sent wording can diverge.
Treat permissions in the same concrete way. The agent may need read access to monitoring systems and permission to prepare a draft. It does not automatically need permission to publish to the status page or execute a rollback. Those are separate operations with separate consequences.
This is part of the broader question of who governs agents participating in operations. A communication agent needs boundaries even when it cannot change infrastructure, because the words it sends can create expectations your team must meet.
A checklist for trying this workflow
- Can the reviewer open the evidence behind each material statement in a sample draft, including the measurement time and source?
- When a source is unavailable, does a test draft expose that gap instead of interpreting it as no impact?
- Does the draft distinguish confirmed actions from proposed actions?
- Are customer-impact claims supported by the available evidence?
- Are recovery estimates included only when an authorized responder has supplied a basis for them?
- Does the public draft exclude sensitive details that customers do not need?
- Is the exact approved message retained with its recipient, time and approver?
- In a replay where later evidence contradicts an earlier update, does the agent identify the affected statement and prepare an explicit correction?
You can evaluate this using a past incident, revealing its timeline in stages so the agent sees only what was known at each point. Compare its drafts with the evidence available then. Look for unsupported certainty, missed corrections and the amount of editing a reviewer needs to do.
Observing the agent’s retrieval and drafting steps helps explain those mistakes. The broader AI operations workflow still needs responders who make decisions and verify recovery. A useful communication agent gives them a clearer account to review while they do that work. Where incident-response authority is defined and enforced, see the AI agent governance framework for the control model, and the AI control plane for the runtime that holds the approval gate in front of a customer-facing update.
Sources
Governing Autonomous AI Agents in Production
Moring provides the runtime control layer, identity verification, human-in-the-loop approvals, and audit records needed to deploy production-grade AI agents safely.
About the author
Arya SharanProduct Marketing & GTM, Moring AIChennai
Owns product marketing and go-to-market at Moring AI across positioning, demand and enablement. Works with regulated buyers on how governed AI agents are scoped, evaluated and bought. Writes about the operating questions that decide whether an agent reaches production.
LinkedIn profile