Letting an Agent Draft Status Updates Without Losing the Manager's Judgement

An AI agent can write a decent first draft of a weekly status update, because most of a status update is a description of what changed and the records already hold that. What it cannot do is tell you which of those changes matters. That is the manager's job, and it is the part that gets quietly lost when a drafted update goes out unedited.

The short version: let the agent write what happened, and always write the "so what" yourself. If you only make one edit before sending, make it that one.

What a drafted update gets right

Given access to the project records, an agent is genuinely good at the tedious half.

• Listing what moved, what closed and what opened since the last update
• Catching the item that has not moved for three weeks
• Noticing a due date that is now impossible because something it depends on slipped
• Spotting tasks with no owner or no date
• Keeping the same structure every week so readers know where to look
• Flagging that a task owner is on approved leave next week

That last one only works if the agent can see leave records as well as project records. An agent looking at tasks alone will happily assign next week's work to someone on a flight, so there is a short list of what an agent needs to know about leave before it reassigns anything.

This is the design idea behind SicherOne: project management, HR and AI agents run on one set of records, so a draft is written from full context rather than a fragment. A person approves the output before it ships.

What it flattens

Here is where a draft goes wrong, and it is consistent enough to check for every time.

Everything gets the same weight. A missed date on a small internal task and a missed date that puts a client delivery at risk read identically. The draft is accurate and the reader cannot tell which one to worry about.

Risk becomes a status. "Blocked, awaiting vendor response" is a fact. Whether that is routine or the start of a serious problem depends on how long the vendor usually takes, whether this vendor has done this before, and what you know from a phone call last Tuesday. None of that is in the records.

Nothing that has not happened yet appears. The most valuable line in most updates is about something that will go wrong in three weeks. An agent describes the past. Managers are paid to describe the near future.

People disappear. A drafted update does not say that one person is carrying too much, or that a new starter is struggling, or that the team is tired. Those things are visible to a manager and invisible in a task record. Some of them belong in the update and some do not, which is itself a judgement.

Tone flattens. Real updates sometimes need to say "this is going badly and here is what I am doing about it". Drafts default to neutral, which reads as everything being fine.

The five edits to make every time

Work through these before anyone else sees the update.

1. Add the "so what" line at the top. One or two sentences: what a reader should take away and whether they need to do anything. This is the line people actually read.

2. Re rank. Move the item that matters most to the top, even if the draft ordered things by project or by date. Ordering is an editorial decision and it belongs to you.

3. Turn one status into a risk. Find the item that is fine today and might not be in a month, and say so plainly, with what you are doing about it.

4. Cut half of it. Drafts are complete. Updates should be short. If an item has no decision attached and no risk, it can go.

5. Check anything about a person. Names, workload, performance and leave. Decide deliberately what is appropriate to share with this audience, rather than letting the draft decide by default.

What should not go in a drafted update at all

Anything touching pay, performance, or a person's record should not appear in a status update drafted by an agent, even if the agent has access to it. Not because the agent will get it wrong, but because the audience for a status update is wider than the audience for that information, and the fastest way to break trust in a workspace is to let HR data leak sideways into a project summary.

Decide those limits before switching anything on, along with the approval steps worth keeping. It is much harder to argue about afterwards.

Why this still saves time

None of the above means drafting is not worth it. A manager who starts from a complete, accurate list of what changed spends their thirty minutes on judgement rather than on gathering. That is the trade: the machine does the recall, the person does the ranking. It is also what you should be interviewing for once agents do the grunt work.

The failure mode to avoid is subtle. It is not a wrong update. It is a correct, complete, well formatted update that nobody learns anything from, sent every week, until people stop reading it. If your update could have been written without you, it did not need to be sent.