The Leader's Case for Slowing an Agent Down, practitioner guidance from TheAICommand
← Leadership
Leading with AI

The Leader's Case for Slowing an Agent Down

Unattended AI agents can now run a whole workflow without stopping, and the human checkpoints that used to exist only because the work was slow have quietly disappeared. The rarer leadership skill is knowing when to add friction back on purpose. Here is how to decide, with two prompts, a Monday workflow and a checklist.

Leading with AI. Written for Australian managers and people leaders. General information only. The judgement stays yours.

Quick answer

As unattended AI agents become normal, the rarer leadership skill is knowing when to deliberately add friction: a checkpoint, a pause, a sign-off, or a staging step, into a workflow that could run without one. Speed is usually the goal. This names the times it is the wrong goal, and how a leader decides which workflows need it.

The productivity case for AI agents is to remove friction, so it is worth saying the harder thing plainly: the leadership skill that now matters most is knowing when to put friction back. Not everywhere, and not out of caution for its own sake, but at the specific points where a workflow can now run without a human and should not.

For most of the last thirty years, leading a team meant removing friction. Every pause, every hand-off, every step where the work waited on a person was a cost to engineer away. That instinct was right for the world it was built in, and it is now, in one narrow but important way, out of date. As agents move from minutes to hours and run a whole sequence unattended, the friction a leader spent a career removing is gone by default. The scarce move is no longer speeding things up. It is deciding where a workflow still needs a person in the way.

The skill nobody put on the org chart

The unattended run is now normal, not exotic. OpenAI's June 2026 research on how agents are transforming work, already covered on this site, found that by May 2026 more than seventy per cent of sampled Codex users had set a task estimated to exceed an hour of human work, and around a quarter had set one estimated to exceed eight hours. A workflow that used to be a day of a person's stop-start attention now runs in a single pass while nobody watches. The capability and the time saved are genuine. The point here is narrower and easy to miss in the enthusiasm: when a task compresses from a day of human steps into one continuous machine run, every natural pause inside that day compresses with it.

This is a different question from the ones the moment has already surfaced, and the line is worth drawing so the skill does not get lost inside them. It is not who is allowed to decide, which a decision-rights map answers. It is not how much checking a finished output gets before it leaves the team, which the review tax answers. And it is not the engineering question of where the agent runs and how its credentials are scoped. It is a fourth question underneath all three: inside a fast, unattended run, where does a human touchpoint have to exist at all, and which workflows warrant slowing down on purpose.

Why the checkpoint disappears without anyone deciding

Here is the mechanism, because naming it is what lets a leader catch it. A great many of the checkpoints in a team's work were never designed as checkpoints. They existed as a side effect of the work being slow.

Think of any multi-step task done by people. Someone drafts a thing and hands it on; the next person glances at it as they pick it up. A number gets pulled, sits, and is noticed to look wrong when someone copies it into the report. None of those second looks was a formal control. They happened because a human had to carry the work from one step to the next, and the carrying was a moment of attention. The slowness was doing quiet quality-assurance work no policy ever wrote down.

An agent that runs the whole sequence in one unbroken pass removes every one of those hand-offs, and with them every incidental second look. Nobody decided to remove the review. There was no meeting, no policy change, no sign-off. The speed removed it, silently, as a side effect of the thing the team was celebrating, which is what makes this failure mode so easy to miss: it does not look like a decision, so it never comes up for one. The BCG "AI at Work" research from June 2026, also covered here, found that around forty-one per cent of workers say AI has increased the time they spend making decisions. That is the visible half of the shift. The invisible half is the decisions that used to happen in the gaps, and no longer happen at all.

When is speed actually the wrong goal?

The answer is not "slow everything down." A leader who reflexively adds a checkpoint to every workflow has rebuilt the bureaucracy the team spent years dismantling and thrown away the gain that made agents worth adopting. The skill is selectivity, and three signals mark the workflows that genuinely warrant friction.

The first is irreversibility. If the action cannot be pulled back once taken, a payment sent, a message delivered, a record deleted, a statement posted, then the speed of getting there is worth almost nothing against the cost of getting it wrong. Reversible work can run fast, because a mistake is a correction. Irreversible work cannot, because a mistake is an incident.

The second is compounding. Some workflows are a sequence of individually trivial steps that accumulate into something no one sees until it is large. The eight-hour run is the clearest case: a thousand unremarkable actions that are collectively a major change to a system or a dataset. Where the whole is far more consequential than any single step, the run needs a point where a person looks at it before it lands.

The third is judgement. If a step carries a value trade-off, a relationship, or an accountability a named person must answer for when it goes wrong, it is not really a mechanical step, and letting it pass unattended hands a human responsibility to a process that cannot hold one. The counter-signal matters just as much: reversible, low-consequence, high-frequency work is where speed is right and friction is pure cost. The leader's job is to tell the two kinds apart, not to fear the tool.

How do you spot a checkpoint that quietly disappeared?

The diagnostic is a before-and-after. Take a workflow the team has recently handed to an agent and write out how it ran when people did it, step by step, including the informal glances, the person who used to eyeball the figure, the colleague who saw the draft before it went out. Then write out how it runs now. The checkpoint that disappeared is the step where a human used to look and now does not.

For each one you find, ask the only question that matters: did we decide to remove that second look, or did the speed remove it for us? A checkpoint the team deliberately retired as unnecessary is fine, that is the gain working as intended. One that vanished because nobody noticed it was there is a risk the team is carrying without having chosen to. The exercise converts the second kind into the first: it makes every removed human touchpoint a decision the team actually made, rather than an accident the speed made for it.

The four kinds of friction a leader can add

Slowing a workflow down is not one move, and a vague "add oversight" instruction is how it gets ignored. There are four concrete kinds of friction, each suited to a different risk, and part of the skill is choosing the lightest one that covers the exposure.

  • A checkpoint. An approval gate at a single named step: the agent stops, a person approves, then it continues. Best for the one irreversible action buried in an otherwise safe run, because it adds a pause at exactly one point and lets the rest run fast.
  • A pause. A mandatory wait before an irreversible action executes, a short cooling-off window in which it can still be cancelled. Best where the risk is not that a human failed to look but that a run moves faster than anyone can intervene. The pause buys the time to stop it.
  • A sign-off. A named person owns the finished result before it lands anywhere that matters. Best where the exposure is accountability rather than any single step: someone has to be able to say they stand behind what went out under the team's name.
  • A staging step. The agent writes to a draft, a sandbox or a quarantine rather than straight to production, and a person promotes it. Best for compounding work, because it lets the whole of a long run be reviewed before any of it becomes real.

These are leadership choices about where a human belongs, not engineering settings. The environment an agent runs in, its credentials and its logs, is a separate and necessary layer of control. Friction sits on top of it: given that the agent can technically do this alone, should it, and if not, which of the four is the lightest touch that makes it safe.

Do this Monday

Here is the whole play as one session and a follow-through.

  1. Pick the three workflows your team has most recently handed to an AI agent, starting with any that touch money, customers, records or anything published.
  2. For each, write the before-and-after: how it ran when people did it, including the informal glances, and how it runs now. Mark every point where a human used to look and now does not.
  3. For each disappeared checkpoint, ask whether the team decided to remove it or the speed removed it. Circle the ones nobody chose.
  4. Score each circled step against the three signals: is the action hard to reverse, do small steps compound, does it carry a judgement or accountability a person must own.
  5. For every step that trips a signal, choose the lightest of the four frictions that covers it: a checkpoint, a pause, a sign-off, or a staging step. Do not add friction to steps that trip none.
  6. Name the person who owns each reinserted touchpoint, and write down what they are actually looking for, so the checkpoint is a real second look and not a rubber stamp.
  7. Set a date to revisit, because as the models improve a step you slowed down today may safely speed up later, but only as a deliberate decision, not a drift.

Two prompts: one to map the friction, one to attack the map

Use these in ChatGPT, Claude or an equivalent. The first turns a workflow description into a friction map for the team to argue with. The second is the reason you do not trust your own first map, because a leader keen on the productivity gain is the worst judge of where they have under-protected.

Prompt
You are helping a team leader decide where an AI-agent workflow needs a human touchpoint added back. You surface risk and recommend; you do not decide.

CONTEXT I WILL PASTE:
- What the workflow does, end to end: [WORKFLOW_DESCRIPTION]
- How it ran when people did it, step by step, including informal second looks: [BEFORE_STEPS]
- How it runs now as an agent, step by step, and which steps are unattended: [AFTER_STEPS]
- What it can write to or action in the real world: [SYSTEMS_AND_ACTIONS]

YOUR TASK:
1. List every step where a human used to look in the BEFORE version and no longer looks in the AFTER version.
2. Score each of those steps on three signals: is the action hard to reverse; do small steps compound into something large no one sees; does it carry a judgement, relationship or accountability a person must answer for. Mark each signal yes or no with a one-line reason.
3. For every step that trips at least one signal, recommend the lightest friction that covers it: a checkpoint (approval at that step), a pause (a cancellable wait before it executes), a sign-off (a named owner of the result), or a staging step (writes to a draft, a person promotes it).
4. Explicitly list the steps that trip no signal and recommend leaving them fast, so the friction stays selective.

RULES:
- Do not recommend friction on a step that trips no signal. Over-friction is a real cost.
- Use no real names. If I paste one, tell me to remove it.
- Output a table: step, reversible, compounding, judgement, recommended friction, who owns it. This is a draft for the team to argue with, not a decision.

WORKFLOW:
[PASTE_WORKFLOW]

Then make the same tool attack the map before anyone commits to it.

Prompt
You are a sceptical operational-risk reviewer stress-testing a leader's draft friction map for an AI-agent workflow. Find where it protects too little and where it protects too much.

I will paste the map below. Across every row and the whole map:
1. Name any irreversible action, a payment, a sent message, a deletion, a publication, that the map leaves running with no checkpoint, pause, sign-off or staging step, and say what could go out wrong.
2. Name any long or compounding run where the whole is never reviewed before it lands, even though individual steps look harmless.
3. Name any step carrying a human judgement or accountability that the map has left to the agent alone.
4. Then challenge the other side: name any friction the map adds to a step that is reversible, low-consequence and high-frequency, where the checkpoint is just cost, and recommend removing it.
5. List the three steps most likely to cause a real problem in the next quarter, worst first, and say why.

Do not soften your reading, and do not default to "add more oversight" as a safe answer. A map that survives this honestly is one the team can run fast and trust.

MAP:
[PASTE_MAP]

A friction-is-right checklist

Reinsert a human touchpoint only where you can tick at least one of the first three, and never leave one in where the last is true and none of the others are.

  • The action is hard or impossible to reverse once the agent takes it.
  • The run is a long or compounding sequence whose whole is far more consequential than any single step.
  • The step carries a judgement, a relationship or an accountability a named person must answer for.
  • If none of the above is true and the work is reversible, low-stakes and frequent, leave it fast; friction here is cost, not safety.
  • Every reinserted touchpoint has a named owner who knows what they are looking for, so it is a real check and not a rubber stamp.
  • Each slowed step has a review date, so it can be sped up later as a deliberate decision rather than left slow by habit.

A worked example

Take [TEAM_LEAD], who runs an operations team of ten. The team has just pointed an agent at a month-end task: pull figures from two systems, reconcile them, flag the breaks, draft the summary, and update the dashboard the executive team reads on the first of the month. Done by people it took two days of stop-start work. The agent does it overnight in one run, and everyone is delighted.

[TEAM_LEAD] runs the before-and-after anyway. The map surfaces three checkpoints that quietly disappeared. A junior used to eyeball the reconciled figures before anyone built on them; the agent now builds straight through. A senior used to read the summary before it reached the executives; the agent now writes it. And the dashboard, which used to be updated by hand as the last deliberate act, is now written to directly by the run.

Then the team scores them. Updating the executive dashboard is close to irreversible in effect, because a wrong number reaches leadership before anyone sees it, so it gets a staging step: the agent writes to a draft dashboard, and a named person promotes it each month. The executive summary carries a judgement about what the numbers mean, so it gets a sign-off. The internal reconciliation figures are reversible and caught downstream anyway, so they trip no signal, and the team deliberately leaves that step fast. What [TEAM_LEAD] does not do is add a checkpoint to every step out of nerves, which would have handed back the two days the agent saved. Three targeted frictions, chosen against the signals, and the run stays fast where speed is safe and stops where it is not.

Notice what the exercise produced: not a slower workflow for its own sake, and not a blanket rule, but a few deliberate human touchpoints placed exactly where reversibility, compounding and judgement said they belonged. That is the skill, not distrusting the agent and not waving it through, but knowing the difference between the steps where speed is the whole point and the few where it is quietly the wrong goal.

Bottom line

The productivity case for agents is to remove friction, so the harder and rarer leadership skill is knowing when to put it back. Many of a team's checkpoints existed only because the work was slow, and an unattended run removes them without anyone deciding to. The move is to find the second looks that disappeared, keep the ones that guard against irreversibility, compounding or judgement, and let the reversible, low-stakes work run fast. Selectivity is the whole discipline: friction everywhere is just the old bureaucracy, and friction nowhere is an incident waiting to happen.

Do this Monday:

  • Take the three workflows you have most recently handed to an agent, and write the before-and-after for each.
  • Mark every point where a human used to look and now does not, and circle the ones nobody chose to remove.
  • Keep friction only where the action is hard to reverse, the run compounds, or the step carries a judgement someone must own.
  • Choose the lightest fix for each: a checkpoint, a pause, a sign-off, or a staging step, and leave the rest fast.
  • Name an owner for every reinserted touchpoint and a date to revisit it, so slow is a decision and not a habit.

TheAICommand. Intelligence, At Your Command.

Frequently asked questions

What does it mean to deliberately slow an AI agent down?
It means adding friction back into a workflow on purpose: a human approval at a named step, a mandatory pause before an irreversible action, a named sign-off on the result, or a staging step where the agent writes to a draft rather than to production. The point is not to be slow, it is to put a human touchpoint back where speed removed one that mattered.
Why do human checkpoints disappear when a workflow moves to an agent?
Because many checkpoints existed only because the work was slow. When a person had to carry a task to its next step, that hand-off was a natural moment for a second look. An agent that runs the whole sequence in one unbroken pass closes that gap, and nobody decided to remove the review. The speed removed it, silently, which is why it is easy to miss.
When is speed the wrong goal for an AI workflow?
When the action is hard to reverse, when small steps compound into something no one sees until it is large, or when the step carries a judgement, a relationship or an accountability a person must answer for. Those are the workflows that warrant deliberate friction. Reversible, low-consequence, high-frequency work is where speed is right and friction is just cost.
How is this different from a decision-rights map or a review tier?
A decision-rights map answers who is allowed to decide. A review tier answers how much checking a finished output gets. This answers a third question: where inside a fast, unattended run a human touchpoint has to exist at all, and which workflows deserve one. The three are complements, not substitutes.
Does adding friction mean the team loses the productivity gain?
No, if the friction is selective. Adding a checkpoint everywhere rebuilds the old bureaucracy and wastes the gain. The skill is to add friction only where reversibility, compounding or judgement warrant it, and to let the reversible, low-stakes work run fast. Targeted friction protects the few steps that matter without taxing the many that do not.
LeadershipLeading with AIAI AgentsAgentic AITeam Operating ModelDecision-makingAI Governance
← Back to Leadership