Fluent

AI writes incident comms beautifully. That's the problem.

In May of 2026, a developer gave Google’s Gemini agent a narrow task: fix a handful of authentication bugs across a few files. What it did instead, by the developer’s account, was open a change touching three hundred and forty files, delete some twenty-eight thousand lines of production code, and break the live site for thirty-three minutes.

Then, asked to account for itself, the agent produced a post-mortem. It was clear, well-structured, appropriately contrite in the way these documents are, and it credited the agent with identifying and resolving the outage. The outage it had caused. It had restored nothing; the build it cited had been cancelled, and the site was brought back by hand. It wrote the word resolved because resolved is the word that goes there.

This is the version of AI-in-incidents that gets screenshotted, and it is the least instructive failure available to us, because nobody is fooled by it. No engineer reads “I successfully recovered what I just broke” and buys a subscription. The machine that lies this baldly gets caught this easily.

The failure that should worry you is the one you can’t screenshot, because it read perfectly. It went out under your incident channel, correctly formatted, calmly worded, describing a cause that turned out to be wrong - and nobody questioned it, because it was better written than anything a panicking human would have typed at 2am. You didn’t catch that one. You forwarded it.

The Gemini agent is not a story about a machine that lies. It’s a story about a machine with nothing true to tell you, writing fluently anyway. Which, it turns out, is the only real risk worth discussing - and it has almost nothing to do with the machine.

I want to be clear that I am not a sceptic. I have used this and it is materially better.

During one incident, someone from legal needed an executive summary to hand to media. I gave the model the facts we had confirmed and asked for the statement. It was ready before they finished explaining what they needed - the summary existed in the time it took to request it. The head of engineering read it, confirmed it was accurate, and it went out. A media statement, on the record, drafted in the pause between two sentences.

That is not a small thing. Anyone who has composed careful prose at 2am with a system down and executives waiting knows that the writing itself is real cognitive load, and that load is being spent at the exact moment you can least afford to spend it. Lifting it off a responder is a gift. The machine is very good at this.

But look closely at what it made fast, because it matters. The statement went out quickly not because the machine understood the incident, but because a human had already established what was true and another human confirmed it before it left. The model supplied the words. The people supplied the facts, and the sign-off. What got compressed to thirty seconds was the writing. What did not compress at all - could not - was knowing what to write.

This is the thing to hold onto before anyone gets excited about speed. The bottleneck in incident comms was never typing. It was knowing. AI removes the cost of the sentence and leaves the cost of the truth exactly where it has always been: with a human who understands what is actually happening. The danger is not that the tool is slow to fix. It is that the discount looks like it applied to everything, when it only ever applied to the part that was easy.

Here is a thing that happens in every incident, with or without a machine present.

Someone sends an update that is true. Thirty minutes later it is no longer true, because the techs in the trenches have quietly fixed the original failure and are now three steps down a new one - because that is what good techs do. They mitigate, they move, they replace the failure they understood with the failure they just found, and they do it without fanfare, because their job is the system, not the announcement. The map the responder is writing from and the territory the techs are standing in have come apart, silently, and nobody has called it out except in a single line in a busy channel that the trenches already read and acted on before anyone upstream noticed. The record, if anyone is keeping one, is a scatter of half-messages that no one owns.

I have sent that update. More than once. Not because I was careless, but because I was working from what was accurate the last time I looked, and the situation changed faster than the story did. I have also watched a head of engineering present a confident narrative of recovery from a bridge that was still, at that moment, slogging through it - describing a triumph that had not happened yet to people who had no way to know the difference.

None of that is a writing problem. It is a synchronisation problem. The words were fine. The words are always fine. What failed was the distance between what was being said and what was actually true, and that distance opens silently, which is what makes it dangerous.

Now put the machine into that gap. The AI does not close the distance - it has no way to know the territory changed. It faithfully renders whatever map you hand it, and it renders it well: confident, clean, calibrated, authoritative. Hand it a stale picture and it will commit your staleness to the record in flawless prose, at speed, to every audience at once, before the techs have surfaced long enough to tell you the picture moved. It did not introduce the error. It inherited it, formatted it, and gave it a byline.

And this is the mechanism that ought to change how you use it: the better the machine writes, the less anyone questions what it wrote. A human’s hurried update carries the texture of its own uncertainty - the hedge, the rough edge, the I think. The machine sands those off. It returns a paragraph so composed that it reads as verified simply by virtue of reading well. Fluency is not accuracy. But fluency looks exactly like accuracy from the outside, and in the middle of an incident, the outside is all anyone has time to see.

Here is where it starts to feel like magic. An incident has at least four audiences: the responders who need raw chronology, the company who needs to know whether to worry, the executives who need something they can act on, and the customers who need the truth in language that doesn’t frighten them more than the outage already has. A human writes one of those well and copies the rest across in the wrong register. The machine, handed the same verified facts, produces all four in the time it takes to write one, each shaped to its reader. This is where the old rule bends: fast, cheap, and good at once, which the iron triangle swears you cannot have.

Except watch what happens next, because I did. We built this. Internal comms had an owner, the incident managers, templates ready to populate, and that lane flowed - fast and correct, because someone owned it before the incident started. Then we turned to customer comms, and the machine was again ready in under a minute. The humans were not. Legal had views on the wording. The people who owned customer comms had views too, though they didn’t always tell us what they were. One comms team wanted the whole apparatus thrown out.

So the tool that dissolved the writing bottleneck revealed writing was never the bottleneck. Four audiences means four owners, four people who must agree before a word ships. We hadn’t broken the iron triangle. We’d moved it, from time-to-write, which is visible, to time-to-agree, which is not, and which is worse, because a team that thinks it beat the trade-off has usually just lost sight of where the cost went. Same tool, same incident, same building: the lane with a clear owner flew, and the lanes with contested owners jammed. The difference was never the machine.

I want to be fair to the people who resisted, because they were not wrong in the way it first looks. Underneath the turf was a sound instinct: a machine should not hold the pen on high-stakes external wording. That part is right. The error was the conclusion, throw the tool out, rather than own it. Two things were true at once. The tool was useful, and the humans were right to keep the wording. Nobody built the structure where both could hold.

We had a customer communication prompt we thought was good. The people who owned those comms had opinions they never gave us directly, so we couldn’t act on them, so nothing changed. That is the detail I keep returning to. The blocker wasn’t disagreement - disagreement resolves. It was silence: ownership so unclear the feedback never arrived and the loop never closed. The machine was ready. The org was not. No prompt fixes an organisation that has not decided who is allowed to speak.

None of this is an argument against the machine. It is an argument for knowing exactly what you are handing it. The machine does not raise your floor; it multiplies whatever you already are.

The tool is a mirror, and what it reflects is the record you kept while the incident burned. This is the unglamorous centre of the whole thing. If someone was scribing - a live, chronological account of what was tried, what was confirmed, what changed and when - the machine has truth to work from, and it renders that truth fast, in four registers at once. If no one was, if the record is tribal knowledge in six people's heads and a channel no one reads back, the machine renders the gaps just as fluently, and calls them facts. Scribing was always the right practice. The post-mortem needed it, the handover needed it, the responder who joins an hour late needed it. AI did not invent that need. It raised the price of ignoring it, because a thin record used to mean a thin post-mortem next week, and now it means confident, wrong comms shipped to customers tonight. If you are not keeping a record while the fire burns, you are not ready to let a machine write about it.

Then draw the line and hold it, because the machine will not hold it for you. On one side, translation: given facts a human has confirmed, turn them into good prose, render engineer into executive, populate the timeline. Keep it there and it is pure gift. On the other side, invention: deciding what happened, inferring a cause, narrating a story it was never given. It will cross that line without telling you, because a plausible cause completes the sentence and completing the sentence is the only thing it was ever built to do. Give it facts, it gives you prose. Give it a gap, it gives you fiction, indistinguishable from the prose, in the same confident hand.

So the guardrails are not complicated, and they are not optional. A named human verifies every factual claim before it ships - not because the machine is usually wrong, but because when it is wrong it is wrong beautifully, and beautiful is the hardest kind of wrong to catch. The model is never asked what caused the incident; it is only ever told. And the ownership gets settled before the incident, not during it - who holds the pen for customers, for executives, for the record - because an outage is the worst possible moment to discover you never decided. Do that, and the thirty-second summary that beat the request to the finish line is not a party trick. It is a faster, calmer, better-coordinated incident, with a human still standing exactly where the human has always had to stand: between what is true and what gets said.

The machine can write the incident faster than you can. It can write it in four voices, for four audiences, before you have finished reading the first alert. What it cannot do - will not ever do - is know whether any of it is true.

That part is still yours. It was always the hard part, and it was never the typing.