The apparent problem was email volume. The real problem was that my team brought me issues before they had prepared the decision.

In a previous role as CIO, I built a declarative agent in Microsoft 365 Copilot for one specific purpose: to help my team prepare an escalation before it reached me.

The agent followed a bounded workflow. It asked clarifying questions, evaluated whether an escalation was ready, and stopped when information was missing or another channel was safer. It did not make or execute the decision.

I won't share exact figures, but the scale matters. The technology organization included hundreds of people working across hundreds of concurrent projects and an extensive application landscape. At that scale, weak escalations weren't a small writing problem. They took time and attention away from the actual decisions.

I kept receiving two kinds of messages.

The first was painfully short: “The migration is delayed. Please let us know what we should do.” There wasn't enough context to make a decision, and the sender hadn't offered a recommendation.

The second went to the opposite extreme. It included the technical history, meeting chronology, open questions, and pages of background. Everything seemed to be there—except the decision.

Different length, same problem. Both left me to reconstruct the situation, identify the real options, find out who owned the recommendation, and determine when a decision was actually needed.

The inbox wasn’t the bottleneck. Decision preparation was.

The problem wasn't email volume

Asking my team to write shorter emails didn't solve this. A short message could still be useless, and a long one could still be unprepared.

What matters is the information that changes the decision:

• What changed, and why does it matter now?
• What must the recipient decide or do?
• Which options are genuinely viable?
• What are the material trade-offs and risks?
• What does the sender recommend?
• Who owns the next step?
• When is the decision needed?

Compression is not about making an email shorter. It is about preserving what changes the decision.

Of course, leaders should teach this standard. I tried to do that. But it is hard to teach consistently across an organization of that size. Guidance is understood differently, pressure changes behavior, and every new team member has to learn the same expectations.

The agent made those questions repeatable. It supported the leadership work; it didn't replace it.

The agent helped my team think before it helped them write

The agent wasn't an email-polishing tool. Before it helped with the wording, it pushed the sender to work through the situation.

What had changed? Why did it matter? What decision was needed? Which options were real? What did the sender recommend? What risks remained, who owned the next step, and by when?

Not every escalation needed the same amount of background. I kept a small list of high-priority projects I followed closely, and another of projects I knew only at a high level.

The agent used that distinction to calibrate how much context it requested. For a project I knew well, it didn't make the sender retell the project's history; it concentrated on the latest change and the action required. For a project I knew only generally, it asked for enough background to make the consequences clear. If the project wasn't on either list, it assumed no prior familiarity and asked for more.

Those lists were not a project database, and they did not tell the agent what was true now. They told it how much context the recipient was likely to carry. That small distinction mattered: decision-ready communication is relative to the person receiving it.

It also separated facts from assumptions and challenged whether email was the right channel at all. Only after that work did it produce a concise escalation.

Many team members were surprised by the result. They expected the agent to help them write a better email. Instead, it helped them understand the problem and become clearer about what they wanted to say—and what they were actually asking someone else to decide.

The better email was only the visible result. The more important change was better thinking before communication.

The agent did not own the decision. It improved the handoff between the person holding the context and the person accountable for deciding.

Take a hypothetical example. A weak escalation says:

The migration is delayed. 
Please let us know what we should do.

A decision-ready version identifies the actual request: approve a limited launch or move the full launch. It presents the viable options—a limited launch, a full delay, or temporary manual processing—and makes the trade-offs visible: customer value, milestone impact, and operational risk. It also includes the sender's recommendation, the accountable owner, and the deadline.

The agent has not made the decision. It has made the decision legible.

The hallway test

I knew the practice was becoming useful when it moved beyond email.

Team members would sometimes stop me in the hallway to raise an issue. If it wasn't urgent, I started asking: “Did you validate this with the agent first?” If the answer was no, I asked them to work through it and come back—or send me the decision-ready message afterward.

I wasn't refusing to listen. I was returning responsibility for preparing the decision to the person who knew the context best. It also let me reinforce the habit in a real moment, which worked better than another abstract lesson about executive communication.

I still wanted my team to approach me; the agent was preparation, not permission.

But it was never black and white. If something was genuinely urgent, I stopped and listened. We dealt with the issue first. Later, I could explain how the agent might help the next time.

The goal wasn't compliance with the agent. It was better preparation before escalation.

That flexibility mattered. The team was learning a new platform and a new way of working, and I didn't expect everyone to change overnight. We introduced the practice gradually, reinforced it through everyday interactions, and adapted it when the context demanded something different.

What I learned

I noticed a real difference in the work that reached me. I spent less effort reconstructing the problem and more time considering consequences and trade-offs. Recommendations had clearer owners. Missing context surfaced earlier. And the team got better at recognizing when an email was enough and when we simply needed to talk.

The agent also gave us a shared language for preparing an escalation. We could use that language in an email, a meeting, or a hallway conversation.

I did not run a controlled study, so I won't claim quantified time savings or a causal productivity gain. Nor do I assume that the same design can be copied unchanged into another organization.

There were firm limits. The agent couldn't invent facts, manufacture options, hide disagreement, or put a recommendation in someone's name. It couldn't decide whether sensitive information was safe to process. And it couldn't replace a conversation when urgency, ambiguity, negotiation, or exposure meant writing was the wrong channel.

The sender still validated the facts and owned the recommendation. The recipient still made the decision. A human still chose the channel and approved the final communication.

If every escalation requires the executive to reconstruct the problem, the executive becomes the bottleneck by design.

What I am sharing

I've now published Decision-Ready Escalations, the first entry in my Agentic Work Patterns repository.

This is not the original internal agent. It is a clean-room, vendor-neutral reconstruction of the operating pattern that proved useful in my work as CIO. It contains agent instructions, hypothetical examples created for testing, a scoring rubric, and privacy and human-review boundaries. It also includes guidance on when another communication channel is safer and a placeholder version of the recipient-familiarity registry without real project information.

I tested the public reconstruction against six test scenarios using fictional information, including two for recipient familiarity, and it behaved as intended in those cases. These checks are useful, but they don't establish production reliability, independent validation, adoption, or business impact.

If you want to evaluate the pattern, start with a hypothetical escalation and review the result against the rubric before considering real organizational data. A complete test example shows the intended output.

Many discussions about agents begin with what decisions AI may make in the future. A more immediate opportunity is helping teams prepare decisions that remain a human responsibility.

What would change in your organization if every escalation arrived with a clear decision, viable options, real trade-offs, an owned recommendation, and a deadline?