Approval Steps Worth Keeping When Agents Write the First Draft

When an AI agent writes the first draft, the useful question is not whether to approve its output. It is which outputs need approval. Approving everything makes the agent pointless. Approving nothing makes it dangerous. The line that works is about consequence, not about quality.

Here is the rule in one sentence: anything that leaves the team, changes a record, or concerns a person needs a human signature, and everything else can go through.

The three tests

Before deciding whether a category of output needs approval, ask three things about it.

Does it leave? If the output is read by a customer, a client, a partner, a regulator or the public, it needs a person's name on it. Internal drafts do not.

Does it change something? Reading is safe. Writing is not. An agent summarising a project is different from an agent moving a due date, closing a task or reassigning work. The first is a suggestion. The second is an action with a consequence someone has to unwind.

Is it about a person? Anything touching pay, performance, leave reasons, disciplinary matters or a person's record sits firmly on the approval side, without exception. Not because agents are bad at it. Because the cost of being wrong is measured in trust and sometimes in law, and neither recovers quickly.

Two yes answers out of three and you almost certainly want a signature.

What is safe to let through

These share a shape: the output is internal, reversible, and a mistake is visible immediately.

• A weekly summary of what changed on a project board, sent within the team
• Flagging tasks with no owner, no date, or no movement for a fortnight
• Pointing out that a due date is now impossible because a dependency slipped
• Answering an internal question about what is on the plan
• Drafting a first version of a plan breakdown for a person to correct
• Noticing that next week's tasks belong to someone on approved leave

Notice that every item is either a description or a suggestion. Nothing in that list takes an action.

What always needs a signature

• Anything sent to a customer, client, partner or vendor
• Anything published outside the company
• Any change to a person's record, including leave, role, or reporting line
• Anything about pay, a bonus, or a performance judgement
• Any commitment to a date or a scope with someone outside the team
• Any deletion, or anything that would be expensive to reverse
• Anything quoting HR data into a document that a wider group will read

That last one is the quiet risk. An agent with access to both project and people records can accurately place a sentence about someone's leave into a summary that twelve people read. Nothing was fabricated. It still should not have gone out.

Make approval mean something

An approval step that people click through is worse than none, because it creates a signature without a check. Three things keep it real.

Show the diff, not the result. A reviewer approving "here is the updated plan" cannot see what changed. A reviewer approving "these four dates moved, here is why" can.

Name the approver. Not a group. One person per category, so nobody assumes somebody else looked. The check is worth only as much as that person's judgement, which is one reason judgement is the thing to hire for once agents take the grunt work.

Keep the queue small. If a manager gets forty approvals a day, they will approve forty things a day without reading. Every item you route for approval makes the important ones less likely to be read properly. Cut the list until it is short enough to take seriously.

Where this sits in practice

The design SicherOne takes is that project management, HR and AI agents run on one set of records, and a human approves agent output before it ships. That is the default, and it is worth stating plainly because the alternative, agents writing directly into records without a check, is how a small error becomes a data problem nobody can trace.

Modules being separable matters here too. A team that wants agents near projects but nowhere near HR records can draw that line at the module level rather than trusting a policy document. And where data handling rules require it, private models can be self hosted.

Review the line, not just the outputs

The categories above are a starting point and yours will drift. Once a quarter, look at what has been approved without a single edit for three months. That is a candidate to move to automatic. Then look at what has been edited heavily every time. That is either a bad prompt, a missing piece of context, or something an agent should not be drafting at all.

A good approval process gets shorter over time as trust is earned in specific places. It should never get shorter in the categories about pay, performance, or a person's record. Those stay where they are.